Jump to content

Two power user requests


fizzymagic

Recommended Posts

I'm reluctant to post these requests, since I know many of the so-called "power users" have been critical of recent site changes that make it easier on everyone else. But what the heck.

 

There are two minor changes to the site that would make an enormous difference to power users (i.e. those who use Pocket Queries, Watcher, etc.). They are:

  • Make single-cache downloads GPX, not .loc
  • Make "rectangular" (min/max lat/long) Pocket Queries an option

 

Both of these changes would be extremely simple to implement, yet be enormously useful to power users. The GPX single-cache downloads would reduce the need for large pocket queries run every day, and the rectangular pocket queries would enable people who presently must perform several overlapping pocket queries to get caches more efficiently.

 

What are the chances of either (or both) of these requests being implemented?

Link to comment

quote:
Originally posted by BeachBuddies:

I think an "on-demand" GPX download would be too risky, even if it were for members-only. Although it would be a nice feature, it would allow people to write web-scraping software to get GPX files for any number of caches. And that could overwhelm the servers.

 

-BB


There are already web-scrapers that do this for standard cache pages. Downloading a .gpx file should be less server intensive that a scrape of the regular page.

 

--Marky

"All of us get lost in the darkness, dreamers learn to steer with a backlit GPSr"

Link to comment

quote:
Originally posted by BeachBuddies:

I think an "on-demand" GPX download would be too risky, even if it were for members-only. Although it would be a nice feature, it would allow people to write web-scraping software to get GPX files for any number of caches.


 

That's no different from the present situation; screen-scrapers can get all the info from the existing cache pages. Why do you think GPX is a greater risk? It's exactly the same data, just in a different format.

Link to comment

Of course, I can't actually HELP with your requests, but I'd like to understand them better.

 

Are you looking for "single cache" downloads to be

 

a) "pure" GPX (thus containing essentially only what's in the .loc)

:( a minimalistic GPX with Groundspeak extensions (what's in the loc, diff, terr, cache container and type, and a few other things that still keep it small) or

c) the Whole Enchalada to include description, hint, logs, and all that other stuff that's in our PQ's?

 

What do you really gain by defining rectangles in the PQ's? A circle is easier to describe to humans. Mapping Magellan users know that being able to define things as only rectangles is no magic bullet. So you plan your trips with a few circles that overlap, use tools like GPSBabel to merge them, tossing the duplicates, feed them to tools like yours (maybe it does duplicate suppression and merging itself; I don't recall) and you're good to go. What problem do you really solve with the rectangle thing?

Link to comment

quote:
Originally posted by robertlipe:

Are you looking for "single cache" downloads to be

 

a) "pure" GPX (thus containing essentially only what's in the .loc)

:( a minimalistic GPX with Groundspeak extensions (what's in the loc, diff, terr, cache container and type, and a few other things that still keep it small) or

c) the Whole Enchalada to include description, hint, logs, and all that other stuff that's in our PQ's?


Any of the above would be an improvement, but of course we'd prefer the last of the three. As you may know, they are already cached on the servers from PQs, so there is no new database hit that needs to be done.

quote:

What problem do you really solve with the rectangle thing?


There are now so many caches in my immediate area that I need to do 3 PQs to get them all. Even so, as the cache density goes up, I start losing caches because of the 500-cache limit. Many of the caches are duplicated between PQs; if I could do rectangles, I could obtain a larger fraction of the caches and be able to detect better when I start missing them.

Link to comment

quote:
Originally posted by Renegade Knight:

You can also do freeway corridores with rectangles.


Exactly what I was thinking, with the added advantage of the server only having to run a query like

 

SELECT * FROM caches WHERE lat>44 AND lat<46 AND long>117 AND long<120

 

as opposed to all the great circle calculations that have to be done using the current radius method.

 

--

Pehmva!

 

Random quote:

sigimage.php

Link to comment

quote:
Originally posted by fizzymagic:
As you may know, they are already cached on the servers from PQs, so there is no new database hit that needs to be done.

 

Depending on the desired freshness of the logs, that may well be true. I agree this would be an improvement. (I'm unamused that my thursday PQ isn't here yet. If I could snag just the 15-ish that were placed since my last PQ, I could merge them in and be happy.)

 

quote:
There are now so many caches in my immediate area that I need to do 3 PQs to get them all. Even so, as the cache density goes up, I start losing caches because of the 500-cache limit.

 

I've cached in your area. Yep, you do indeed have a lotta caches there. But I'm not exactly the greenest cacher in the world and even I can't imagine needing 1500 findable caches in my pocket when planning an outing.

 

As another option to square regions for you, instead of touching circles, think "coaxial" circles. Use the same starting point and radius, but let one be the "1.5/1.5 and under" that likely constitutes the bulk and the other be the "2/2 and ups". You may have to futz with the numbers a little, but you get the idea. That way you don't have to worry about the overlap or missing things where the circles didn't touch.

 

And that interstates that run "north and south" run north and south 'enough' to make this fun to describe mathematically is fallacious. If you're trying to solve the "caches along a route", that's already a solved problem - and one that can't readily be done thinking that all interesting roads are rectangles along polar coordinates.

 

The great circle math does indeed consume clock cycles. Without actually profiling the code running on the server, it's hard to say with authority, but I'd bet it's totally dwarfed by the I/O (even if everything is totally in and not on a spindle) to actually get the coords to compare anyway. The page faults on the indexes and the actual records are likely to make the floating point accesses inconsequential.

 

I'm not trying to talk anyone *out* of this stuff, mind you. I just have a different wish list.

Link to comment

quote:
Originally posted by fizzymagic:

Well, out with it, man! What's on your wishlist? Maybe it's stuff I want and didn't even know I wanted! icon_smile.gif


 

Oh, OK. Since it's your thread and you asked, I won't feel badly about hijacking it...It's not meant to be critical, but it's a partial list of minor peeves that I've been saving up.

 

The top of my list would be for the site to work as well as it did even a few months ago. The current reliability stinks. Pages won't load and the login problems continue to come and go on a daily basis.

 

Many of the recent "improvements" actually hinder power users. For example, now that the site is using forms (!) to submit javascript viewstates (!!) you can no longer middle click on the "next" page so it can be loading (or these days, starting the "server deadlocked/timedout->reload until it works" loop" in another browser tab. There's WAY more data moving over the wire, so it's noticably slower on, say, a cellular modem. Forward and backward no longer work sensibly since it has to repost the form data. You can no longer access these pages on a humble reader, such as a cell fone or on a browser that has Javascript disabled since it's most often used for blinky, squiggling porn ads anyway. You can no longer bookmark searches becuase of this viewstate goop. But the icons are prettier.

 

The inconsistencies of things like the "my pocket queries" being a link in the text, benchmarks being essentially hidden, several overlapping, but different search pages, each found in different ways, and so on make me even wonder why there is a navbar on the left any more.

 

The logging interface does not scale well. What you really want is one page that retains the last date logged, has a message box to mail the cache owner ("dude, your box leaks" or virtual verifications) a place to enter MULTIPLE filenames for picture uploads. To do all these things now, you have to bounce between pages, generating extra server and cereberal load. Go ahead, count how many page loads it takes to log a weekends worth of hunting. Oh, and include links to the nearest dozen or so unfound caches on that page - "power cachers" cache in clusters and we move from cache to cache, so the next one we want to log is probably one that's nearby. And in the "my preference" page, let me set the default log to "found it" - yes, I know some people were screwing that up, but most of us find more than we either don't find or note.

 

Why does the entire page have to be regenerated and reloaded just to decode the hint that may be as little as a word or two?

 

Do users really find the stuff like the "add &f=1" solution very satisfying? Why isn't that a sticky preference on "my preferences", with an override on every search page that honors it?

 

I'd really like an option for > 5 logs in a PQ. I've tied into caches where cacher 1 says "dude, your coords stink, I found it at X" and the following five logs say "found it". The data rolls off too quickly with five logs.

 

Even acknowledged problems aren't getting fixed. GPX still contains bad XML - and I'm pretty sure that your GPX2HTML users are dogging you as hard as GPSBabel users are dogging me about this. Yo u can only get locationless pocket queries in a highly non-intuitive way.

 

When entering a cache page, why do I have to tell it the coords, the state, and the country? Given the former, the latter is self-evident.

 

Why does the "new messages" option in the forums show us old messages? It knows the last time we read them, and it knows what's new since then. Why do I have to remember that I've read the first two pages of this four page thread and manually advance to it?

 

Since the source for the site isn't exactly open, I can't help fix them. (And if it was written in open tools, I'd put my money where my mouth is and help fix some of these things.) But I will testify that an ambitious programmer CAN take the pocket queries and essentially optimize awy most interaction with the site. Logging finds still incurs the POST but the occaisional double log/missed log can be fixed up after the fact.

 

I've coped with most of these things by avoiding interacting with the site when I can. I recently manually reviewed about 400 cache pages for a trip, planned my days, and logged my finds all with pocket queries and local software. Never once did I get a page timeout or did I have to log in a zillion times. :-)

Link to comment

Hey robert, great summary of the problems with the site.

 

Let me add this: I would reckon that most pocket query users are getting updates multiple times per week. It should be no surprise that the diffs between two updates are very small. Not only that, but we have our client side tools to filter the queries. I'd like to be able to download the GPX file for an *entire state* on a monthly basis, and then download the weekly diff against it, followed by the daily diff to bring it completely current. Some states might have to be broken up into 2 or more parts, but I think you can get the drift of my idea.

 

This would significantly reduce the load on the servers and allow people to filter queries client side as they see fit. This also avoids the need for "on-demand" scrapes when you find you are going to be making an unscheduled trip, or when you find that there are a bunch of new FTF opportunities.

 

Basically, its recognizing that power users want a replicated database for their region or state(s).

 

-Rick

Link to comment

I'd like to see the capability to deselect multiple caches at one time from the watch list.

 

I'm also curious if people actually prefer the 'how many months ago' a cache was found, as opposed to the actual date we used to see before the improvements.

 

It seems that having the 'date' is such a no-brainer. Maybe I'm missing something, is there an advantage to 'months ago'?

 

Oh yeah, having totals when you click on a users profile would be nice, and having all of the user info on one page rather than have to click tabs to jump between two seperate pages.

 

It really would be nice if the users could create their own pages of whatever information they need, a page that could interact with the site giving the information that the particular geocacher needs in the formats they like. I'm wondering if anyone has created such a personalized front end, and what successes they are having with it.

Link to comment

I just remembered that due to a recent contribution from Warm Fuzzies, GPSBabel can actually filter by proximity to an arc or bounded by a polygon these days. So if you really wanted only caches along five miles of I-24 (and you were willing to define where I-24 is - hint: it's diagnoal) or caches within your county, or whatever, you can do that sort of thing.

 

While GPSBabel's moniker is as a converter, it can actually do interesting things with its filtering phases even when the input and the output are the same type - so you can take a pocket query and slice and dice it in an number of sick and twisted ways.

Link to comment

Almost daily, we see new threads started about things we'd like to see added, changed, or removed from the site. Most of these threads restate the same issues over and over again. In some cases there is overwhelming support for a change.

 

Does anything get done? Rarely. Even though the majority of members are asking for a change, nothing happens. (A simple example of this would be the Total Finds on the profile page.)

 

Many of these changes would be simple to implement, but they remain unfulfilled. Why? Because it's not OUR site. The site belongs to an individual, and that individual has the final word on what is included.

 

There could be any number of reasons that our collective requests remain vapour... Maybe the coder(s) are too busy... Maybe we've got a case of *It's my site and I'll do what I want*... Who knows. I guess all we can do is continue to ask, and maybe, someday, our wishes will be realized.

 

TT

 

TrimblesTrek

Link to comment

quote:
Originally posted by robertlipe:

 

Since the source for the site isn't exactly open, I can't help fix them. (And if it was written in open tools, I'd put my money where my mouth is and help fix some of these things.)


 

Same here. If the site was done in open tools instead of the .NET stuff, Jeremy would have so many volunteers lined up to help that stuff would get done in HOURS instead of months.

 

http://www.tampabaygeocaching.com

 

[This message was edited by infosponge on August 09, 2003 at 08:11 AM.]

Link to comment

I've also thought about volunteering some code, but it'd have to be VB, and I'm not willing to learn it just to be able to contribute to this site. If it were in PHP or perl, I'd be bugging them daily about contributing.

 

In Jeremy's defense, he's kind of locked into .NET as long as he wants to use the MapPoint server for the maps. MapPoint has some nifty features and are the most aesthetically pleasing maps I've seen. It's API leaves a LOT to be desired, but it mostly works. Any other mapping system would be ugly and expensive, or he'd have to rely on third party servers being up and available (aka tiger).

 

--

Pehmva!

 

Random quote:

sigimage.php

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...