Jump to content

Making "caches Along A Route" More Solvable.


robertlipe

Recommended Posts

[ At the risk of sounding snobbish, I'd like to direct this discussion to the programmers and technically inclined interested in helping make this more reachable to the masses and not the masses themselves. Also note that while the parlance in this is U.S.-centric, the ideas would apply to other countries.]

 

A recent thread got my mental wheels turning on the "caches along a route" problem. Armed with decent mapping software, a few obscure skills, and GPSBabel's arc filters (now also used by GSAK) I've long considered this a solved problem. But the number of requests that keep coming up on the forums shows that most people don't.

 

There are a few problems that keep this out of the hands of those that have never owned a pocket protector.

  • Getting the data from geocaching.com is hard.
  • Getting the routes is hard.
  • Getting the exits is hard.
  • Reducing that bulk of data is hard and can be computationally expensive.

The first point has been well discussed. Unfortunately, we as users can't do much about it. As long as we get PQs in circles, we'll have to do the sort of thingdescribed very well by Jamie Z . Since solving that well requires host site changes, let's defer that for now.

 

While the ability to work with arbitrary roads and routes is interesting - and definitely a feature that's handy - most folks asking about "caches along a route" are really asking about interstates. Even big states have relatively few interstates in them and they're fairly easy to recognize by name. I have looked around and around on the net to find a free source showing the locations of the interstates and have so far come up empty handed. I've flirted with the idea of programmatically extracting them from maps (our copies of S&T, Mapsend, Mapsource, etc. have all the data) but haven't really gotten past the legalities of that and into the technical side. I'm sure that the USGS or the highway department or someone has that data out there for free, but I can't find it. Mentioned solutions have included http://www.zenrin.com/exitInformation/fields.asp but pricing and redistribution/usage isn't clear from their site. Does anyone know of a source of this information?

 

Only recently had I even started thinking about the exits problem. It occurred to me that if you have a sequenced list of exits, you probably have an approximation of the route that's "good enough". (Yes, there will some exceptions, but I don't know if that problem is worth solving well.) The USGS does make interchange information available at http://geonames.usgs.gov/stategaz/index.html but it's quite dated and has the unfortunate characteristic that while it gives lat/lons and exit numbers, it doesn't include *which* interstate it is. An ambitious programmer could probably figure out how to rechain those and manually label them. (Some kind of combination of nearest point + nearest number, but offhand, I'm not sure how to do it reliabily.) It does provide a reasonable shape of the interstates. The data looks shaky enough that we'd probably want a way to inject additional points. Are there better sources out there that are available without redistribution/usage restrictions?

 

A recent contribution to GPSBabel's arc filter from parkrrr has made the distinction between "caches near an exit" and "caches near a road" trivial; literally the addition of one suboption the invocation. If we leave the filtering/processing on the client side - or had the ability to "precook" PQs without running afoul of the TOS - the computational costs aren't too bad. My tests so far have shown that reading the XML dwarfs the trig of computing this when we have as few comparison points to work with as we would for exits. This is definitely NOT true if you take something like a Delorme ANR and save all bazillion points for the interstate and use that for filtering. If there was a reason to address the scalability issue in GPSBabel I could be convinced to do so, but since my tests were turning in times under a half second for filtering a 600 cache state against 31 exit road, I'd want to SEE a scalability problem before we solved it.)

 

 

I can imagine of a couple of programming projects here if any of you web/database jocks would like to tackle it.

 

Start a web exit database. First, of course, you have to get the raw data and we'll assume it's free for reuse. Provide a web-downloadable version of them with a UI not terribly unlike the one at http://www.zenrin.com/exitInformation/fields.asp that lets you pick which state and which interstate. The resulting data could be delivered as a GPSBabel arc file suitable for feeding to tools like GSAK for client side filtering. For extra credit, add the ability for user created interchanges and maybe even rest areas. Perhaps it makes sense to partner with someone like Wayhoo who seems to have most of the logic in place.

 

A lower-cost version of the same would be for various regional/local geocaching clubs to provide this data on their sites. The problem with that is that regional/local club sites are being delisted from geocaching.com and it puts the onus on the traveller to seek these out. I'm not really sure how satisfying that would be for a long-distance traveller. A master index of locally maintained lists might be a workable compromise.

 

A variation of the above would be to allow people to upload a PQ (or have it directed here via the "send this PQ to..." option) , do the filtering, then send the PQ back. Careful attention to the TOS governing PQ's would be needed. Provide dialogues for "how far from the road do you want" and "do you want everything along the route or just near the exits" and the option to merge incoming PQs. You'd also have to allow multiple interstates to be specified. (i.e. "I65-TN, I65-KY, I65-IN,I69-IN")

 

I guess one key question is 'Is providing picklists of interstates "good enough' for most users?'

 

I don't really know where to go with it, but it sure seems like there's an opportunity to make this work easier. What ideas are out there in programmerland for someone to leave a mark in geocaching history? (Here's a chance for some of you Linux/MySQL jocks to show your stuff... :-)

Link to comment

Sounds like an ideal task for GIS. I use ESRI ArcView/ArcMap and the kinds of data access and queries you're describing are pretty common with those software packages. The problem is they're too expensive to use for other than business apps. You might still look into ArcReader (free version) or similar technologies though just in case. ESRI GIS

 

I think the ESRI shapefile or coverage format might be the answer to your data needs. There's tons of that data out there. Here's a good exampleGeo Community.

 

Hope it helps..

Edited by Erman_C
Link to comment

To take this in a different direction, what if Geocaching or some of the web sites included closest highway number and exit numbers as part of the info when you post a new cache? You could search for the interstate you're on, and then just look at the exit numbers near where you'll be traveling. It would at least tell you where to get off the highway, but would require changes to GeoCaching.com and probably other sites as well. Just a thought.

Link to comment

I've fished in the ponds of Tiger,Geo Community, ESRI shapefiles, and such, and really haven't found what's needed.

 

icon_sad.gif September 3 by robertlipe (lots found)

Spent a lot of time looking for it, but couldnt find it. That doesn't mean it isn't there. Perhaps a more experienced or focused seeker will locate it.

 

Increasingly, I think the exits are required for this to work well, but perhaps extracting "just" the interstates from the tiger data is enough. Tiger seems to have exit info in the A63 records, but that's still several gig of data to rip through.

Link to comment

Bump ~

 

Ideally, an end user would want a product that would give them the nearest caches within a defined buffer zone along a route from Point A to Point B - Interstate highways or not.

As others have mentioned, GIS is the way to go here. If someone can get a copy of ESRI's RouteMap IMS and a server with some juice this can probably be done. Several man-hour-weeks of labour would be required too. :blink:

 

1) User defines their A, B, C, etc points and buffer zone

2) The end user uploads their PQs

3) SQL DTS processes the data and formats it for IMS

4) IMS returns the user data in the form of a map and a list - much like this web site does when you select "Identify" on the "Map Nearest Caches" page.

5) Two desirable options here -

* print the list and map

* download a GPX file

 

IMS is easy to work with (M$ programmer or not) and doesn't require extensive GIS experience to get working.

 

Someone we all know and love may, or may not, have built this using IMS and it works kinda like what I've decsribed. Note that the buffering worked into the form could easily be changed to read "find nearest caches within x miles of route".

(I built this app over a year ago and while its still working it seems to have some bugs that I did NOT include when I was working for "El Seis").

Link to comment

I posted this on the other thread. Does any of it make sense as "do-able"?

 

Could you have a zoomable map where the user would click the spots along the way. Your program would caclculate the coordinate for each click. Then your program would create the arc between each pair of clicks and provide the caches within the selected mile range for each arc.

 

As an option, rather then creating an arc, the user would click spots he might be stopping in. Then your program would provide a list of all caches within the selected mile range for eack click.

Link to comment

I'm totally ignorant, but wouldn't some kind of lite interface over a picture map work out? Here's what I'm thinking.

 

Either an HTML window w/ some javascript or some frames or a java app.

 

So you have a map that you can zoom around on. How exact are we trying to be here? If you knew top left on the map was a lat/lon and the bottom right was a lat/lon, and the image of the map was X by Y pixels... couldn't you make a fair approximation of where the user is clicking on the map and derive some points from it.

 

This requires no fancy mapping software really. You could do it pretty easily on a state level by presenting a JPG map of the state and registering the clicks, calculating the points and storing them.

 

Then use a "connect the dots" method to populat in-between lat/lon points at intervals of .25 or 1 mile or something and find the caches within Z miles from each point.

 

Am I over-simplifying? Does it need to be so high-tech? I know at a high zoom-out, curvature becomes an issue, but would it be reasonable to restrict this to the state level? Going through 9 states? Do 9 pocket queries.

Link to comment
Caltrans publishes the lat/long of every rest stop along all the Interstates in California. Not sure if other states do this, but it would give you a route skeleton at least...

Interesting. Given that web page, 10 minutes of pretty easy programming, a PQ covering the area, and the new option in GPSBabel's arc filter for points, it would be really easy to hock up something like http://www.mtgc.org/rest/

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...