Jump to content

Caches Along A Route


Jeremy

Recommended Posts

After reading some of this, I went to Mapsend created a route, opened a filter in GSAK and imported my route and presto I had a list of caches along my route.

 

When I first read about "arcfilters" I was a little intimidated, but it wasn't bad at all.

 

Thanks for the info

Link to comment
I know that there is probably a good reason for this not to work, but how about a PQ generator that used 4 coords to make a rectangle for cache queries?

Actually it is only two coordinates, the upper left and lower right. But like Robert indicated, it is in the plan for new PQ features.

Wouldn't a four-point query work better? With a two-point query, all you could define would be a rectangle. If I want to follow a stretch of road that is mostly diagonal, I would need a huge rectangle to cover it all and would get back a lot of caches that are out of my desired range.

 

By entering four coordinates, I could define a quadrilateral of any orientation to better fit the direction of a road.

Link to comment

Lots of good ideas on this topic... in all the reading, I may have missed something somebody else has already said. If so, I apologize. That said, I will toss out my ideas here....

If the goal is to get the caches near the road along the route.... then perhaps a database of "highway access points" could be designed. Here's a very basic setup...

Highway type: I=interstate, L=Limited access highway, H=Open highway (no exits per se, just pull over/off the road)

Highway Number: ###

Highway State: NV, HI, MT, DC, etc

Point type: R=rest area, E=exit, , B=state border, T=turn (this is for open access highways, we have a lot of long open straight highways here in Nevada)

Lat: ##.####

Long: ##.####

 

Extend the schema of the the existing cache page to include "distance to nearest highway access point". This would be caclulated when the page is either created, or refreshed.

 

The distance would be based on the nearest highway access point. If the point is of type "H" (open access highway), then find the second nearest point of type "H" with the same highway number, draw the line, then the distance would be from cache to that line.

 

So... when performing a PQ, you ask for caches within ## miles of it's highway point, and use an line/arc to define the general route. Note: this distance is only cacluated on occasion, so it won't use nearly as much processor time during a PQ.

 

Next issue: populating the database. I volunteer to do Southern Nevada. Heck, given enough time, I would do all of Nevada with the use of ExpertGPS. California, you're on your own.

Edited by Moose Mob
Link to comment

Another benifit to the "Highway access point" concept. It would show you caches other alternate routes in the general vicinity. For example, from LA to Las Vegas, the old Las Vegas Highway runs pretty much parallel to the Interstate. These caches would not show up on an "Interstate highway exit" type query, but you would get them as showing up along Highway 604, and the exits to and from this highway will stand out like a sore thumb when projecting the query onto a topo/street map.

Edited by Moose Mob
Link to comment

What I've always wished for were boundary latitude/longitude choices on pocket query. Similar to what we have for terrain and difficulty.

 

For example,

 

All caches:

N/S of 46º 05.111

E/W of 122º 04.232

N/S of 48º 04.333

E/W of 121º 00.000

 

(you wouldn't have to select all of them or any of them)

 

Often I am caching in an area and want to download caches on the way there but I know I'm not going any further north than a certain area. But to make sure I get all the caches in that area I have to have the center of the circle near the northern boundary.

 

It's not a great along a route solution but it seems like it would be easy to implement and understand. And would at least partially fix this problem. You'd get 4 boundaries, basically making it a box but not needing coordinates for the corners.

Link to comment
Wouldn't a four-point query work better? With a two-point query, all you could define would be a rectangle. If I want to follow a stretch of road that is mostly diagonal, I would need a huge rectangle to cover it all and would get back a lot of caches that are out of my desired range.

 

By entering four coordinates, I could define a quadrilateral of any orientation to better fit the direction of a road.

It might, be better for the end user, but wouldn't the mathematics be a whole lot more difficult. Consider:

 

The math for two points is pretty easy:

Two Points:

010691b0-dad2-413c-8fc3-e4d85fd8da7e.jpg

This establishes four lines and a < and > formula

 

If we make it four points:

efcaaa05-c437-4b2a-9a70-cc1b599c76e2.jpg

It's more flexible, but harder to determine if the points are in the range.

 

And if you're going to allow four randomly chosen coordinates, why not more and just create a shape file?

b7af8a52-dce0-448e-bff5-c2db21a69b53.jpg

Link to comment

I should start by saying all this is good stuff (and I would have uses for this). These remedies are for finding caches in an area, or even along a line.

 

My basic interest in this thread is... caches along a route, and if I can I define it a little more... caches near a highway access point. I would love to have a query that will help me to find caches while on a road trip. The goal being... near (and accesible from) the highway.

 

If I am driving from Las Vegas to Portland, then my route could be defined in run 20 or more pq's (it would take 4 for sacramento alone), gross detail, and filter them through GSAK, resulting in a very rough results (perhaps 1500 caches). By having a way for the PQ to know if these caches are close to the highway, I could cover nearly a 1000 miles with a single query. I believe that geomtry is the major part, but only a part of this solution.

 

** steps off soap box **

Link to comment

I've been working through email with Robert Lipe on this. He has code within GPSBabel that can run an arcfile against a shapefile and return a list of caches within x miles of the arc line. It's currently the most efficient way to get a list of caches along a route.

 

But for the test, the arc file was of I-5 and I ran it against a GPX file containing Traditional caches for the entire state of California (which happened to be 29 megs in size unzipped). In only a few seconds it returned a file containing caches within 1 mile of the entire I-5 route.

 

I just happened to be driving from Los Angeles to San Jose that week, so I uploaded the caches (around 260) into my GPS and drove the entire route. Sadly I was only able to find 1 cache on the trip, but I did watch the number of caches as I passed them along the route.

 

My basic findings revealed that it is preferable to offer some alternatives in distance along a route, starting at 1 mile and ending around 5 miles away. For shorter distances it makes more sense to download a wider distance, while long distances would deter you from driving too far off-course for a cache.

 

Also it seemed to hit a large area for most folks who drive long distances. It seems (to me) that you could, with some practice, hit some larger areas where the interstates are, and specifically target regions where you may spend more time.

 

The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

 

We have some other ideas, but that's where we are right now. Ultimately we will have to create tools that build a large filter set for people to use in their searches. We are making some progress.

 

(edit: corrected source of I-5 data)

Edited by Jeremy
Link to comment
Robert did a great job grabbing I-5 out of the Tiger Line map data,
Thanx. Actually, the one I sent you came from Street Atlas. Extracting it from Tiger would have required custom programming.

but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

Yesterday I placed an order for some data sets to evaluate. Pictures at eleven.
Link to comment

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.

Edited by Alan2
Link to comment

So, we have had discussions on areas, lines, squares, polygons, databases, exits, etc, etc.

 

If I may be so bold, the basic issue is that PQ's currently come in circles. Our routes are jagged lines. I believe our common goal is to filter out caches that are 50 miles off course, so we can put our efforts on caches that are closer.

Although I envision a mapquest type route and the ability to get the caches that are really really close to that interstate/freeway/highway, this may need to be taken one step at a time.

 

How difficult would it be to setup PQ to be able to query in a linear fashion? Say... starting simple with Point A and Point B, then caches outward of that line? Just this alone will reduce the number of PQs it takes to get full coverage to the destination.

 

I did a sample run over the past couple days. It would take 8 circlular PQ's to get from Portland to Las Vegas. If done in a linear style, it could be done in 3.

 

(It may also help to be able to have the query return more than 500 caches.)

Link to comment

I really like Moose Mob's idea: have a "linear" PQ type for which you specify endpoints (which could even be zip codes or cache waypoints). The query would behave like current queries, except that it would return the 500 (or whatever number specified) caches closest to the line connecting the two points. That way, the query has all the properties of the current queries and would be easy for existing users to learn.

 

It will also be useful for purposes other than caches along a route; it can be used to sort of simulate the rectangular queries that people have been wanting, as well as to generate a set of queries for an area with less overlap than existing circular queries.

 

I think that adding the required logic and generating a modified PQ page would be quite easy.

Edited by fizzymagic
Link to comment

 

The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

 

A quick search turned up the

Bureau of Transportation Statistics which has links to ESRI type shapefiles. It's from the Government, so we've already paid for it!

Link to comment

I spent a good (bad?) number of hours studying the BTS NTAD CD's (that's the dataset I referred to above, though I didn't do it by name), modifying my shapefile importer, writing a new GPSBabel module to reassemble road segments (that I needed for another shapefile I was studying for this project) and it appears to be a bust.

 

Slogging through tiger (as perspective, there's a 350-ish page spec describing the 750MB of data for the state I live in) is my next step.

Link to comment

 

The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

 

A quick search turned up the

Bureau of Transportation Statistics which has links to ESRI type shapefiles. It's from the Government, so we've already paid for it!

Whatever you decide to do, can you make it universal please? Keep it with WGS84 format without starting to depend on other factors.

Link to comment

The goal is great, and I can't wait for it to happen. In the interim, can we get Linear PQ's? Point to point would be good for a start. Multi point arcs would be better.

 

My trigenometry is pretty rusty, so I do not know the details of what this type of project would entail.

Link to comment
My trigenometry is pretty rusty, so I do not know the details of what this type of project would entail.

The math is all done, and it is pretty simple. However, for linear PQs there is one minor issue: since east-west roads on maps often follow Mercator projections, would it be better for a linear PQ to use a Mercator line instead of a great circle or other geodesic?

 

Aside from that, I think that the issues involved in implementing a linear PQ are quite simple. I'd be glad to help, as I know robertlipe would, too.

 

Let's get this interim solution running and see how it goes! I think we will find that it will make a lot of people very happy.

Link to comment

Extracting it from Tiger is a chore and one that I've mentioned a few times.  Do you know of any really groovy tools to help pull that out?  I've seen the raw (and really large) data sets available for d/l and purchase but I haven't found a lot of tools to decompose them.  The multi-hundred page spec was tractable, but painful.

 

Fortunately, there is a relatively easy way to use the TIGER data... ESRI has made the data freely available in shapefile format here:

Census 2000 TIGER/Line Data

 

You can then use the really groovy tool ogr2ogr to extract just the features you want into a new shapefile, using SQL-like commands.

 

As proof of its grooviness, ogr2ogr can also read from TIGER files and output shapefiles. For example, I just ran this command:

ogr2ogr -f "ESRI Shapefile" -where "FENAME='I-80'" output TGR06095.RT1

 

That read the TIGER data files for Solano county and created a directory named "output". Among the files it created there is CompleteChain.shp, which is a shapefile containing just Interstate 80.

 

I knew I wanted the field FENAME and the string "I-80" by using ogr2ogr's groovy friend, ogrinfo, which lets you browse the contents of shapefiles, TIGER files, and more.

 

My two cents on another point of discussion:

The ability to search for caches "near" interstates is better than we have now, and would certainly be useful. However, I find that I tend to be more interested in cache stops when travelling on state highways and county roads than when on interstates. And a good number of places I go are on routes away from interstates. So the ability to query for caches near non-interstate roads would be much appreciated. Being able to upload a route from, say, Garmin MapSource to define the query is an appealing solution, but I'm not sure how well it would work. Their route data seems to only contain important intersections, with an implied straight line between intersections. So if I'm on a road that goes halfway around a mountain between turns, the query would show me caches on the mountaintop, not caches near the road.

 

Dave

Link to comment
The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

 

As I just described in my reply to robertlipe, the combination of TIGER data (whether in TIGER format or shapefile format) and OGR tools is a free and relatively straightforward way to create shapefiles for whatever interstates (and state highways?) you want to use. It's not prebuilt, but the cost and licensing is hard to beat.

 

Dave

Link to comment
We're integrating geocaching into a planned community trail here in I'On. We have six caches along a planned five mile route. We're waiting on some additional trail sections to put it online.

This is one that can be handled with the idea of bookmark lists, kind of how Amazon does it when people create their own product lists. You'll be able to query just the list and download it as a LOC or GPX. It could be handled with managing routes but something themed like this would work better as a bookmark list.

Link to comment
The goal is great, and I can't wait for it to happen.  In the interim, can we get Linear PQ's?  Point to point would be good for a start.  Multi point arcs would be better.

I've read through this thread with great interest, especially since we just completed a trip from Detroit to Northern Alabama and I spent quite a bit of time getting the GPX files of caches along the route.

 

In contrast, however, I was able to extract a list of Ham Radio VHF/UHF repeaters along the same route easily using a package called TravelPlus for Repeaters. This application displays a map with limited zoom capability and major Interstate and state roads. I simply placed my cursor over points along the route, clicked and drew a "corridor" along the route X miles wide (specified as a default, but changeable for each point). The software even imports StreetAtlas routes so route definition is a breeze.

 

After drawing out the route (about 12 points) the app generated a list of repeaters with the characteristics I desired that fell within the "corridor" (frequency band of operation, access codes, etc.)

 

I struck me that TravelPlus for Repeaters embodies much of the functionality in the UI that folks have mentioned for the PQ/Cache Route package.

 

I am not familiar with the technical details of how it does this, but the similarities are striking- something like it for caches that generates a GPX file as output would meet many of the requirements I've read here.

Link to comment
The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

I found such data on-line earlier this year in the GIS world (in the public domain). I think it is called a "Road" layer. I also had to find a (free) viewer to view the GIS data, but I found all the major roads in California (but not labled) in an ASCII file (1288k). But I had to stop pursuing this for creating arcs because it is raw data and I don't have the time to sort through the very large dataset to find what I need. So if you go the route of working with GIS data, then it will still be a project for someone to convert the vectors into something user-friendly.

Link to comment

I just had another thought. It was mentioned in this thread that two lat/lon coordinates dertmine a rectangle. And I have said so myself many times, and it is "close enough" if the points are not too far apart. But GPS coordinates are assumed to be on the surface of a sphere where two points determine three areas that are not really rectangles at all (but I am happy to call them rectangles for this discussion). To see the relevance of this issue in the context of this thread, imagine the foolowing: I give you the two coordinates of a "rectangle" that includes the cities of San Francisco and Tokyo, then in addition to this "rectangle", these two coordinates also define a rectangle that wraps around the other side of the globe parallel to the equator and yet another one parallel to the date-line across the poles of the globe (the latter would be hour-glass shaped). Since the date-line (the line where W179.999 switches to E179.999 is in the (smaller) rectangle that I actually do want, I might get the wrong data if the software does not "correctly" select the "correct" one.

Link to comment

Bump

 

Long long long term thoughts... it would be great to have the ability to quickly and easily determine a route, locate the caches "customer satisfaction" rating of 4.0 or higher along that route. As long as I am off the freeway, all the other caches within 2 miles of those highly rated caches.

 

<_<

Link to comment
The biggest challenge now is getting the arcfiles we need to do these prebuilt queries. Robert did a great job grabbing I-5 out of Street Atlas data, but the other interstates will be tedius to build, at best. If anyone knows of a place to get prebuilt interstate data, let me know.

I found such data on-line earlier this year in the GIS world (in the public domain). I think it is called a "Road" layer. I also had to find a (free) viewer to view the GIS data, but I found all the major roads in California (but not labled) in an ASCII file (1288k). But I had to stop pursuing this for creating arcs because it is raw data and I don't have the time to sort through the very large dataset to find what I need. So if you go the route of working with GIS data, then it will still be a project for someone to convert the vectors into something user-friendly.

I use mapsource software and microsoft streets an maps to create my own.

Link to comment

I was thinking of something along a simpler idea when I found this list. I know it would not be as good. But maybe much easier to setup. What about just tacking the N, NE, E, SE etc from the left side of search page and narrow it down to just one of the general headings.

Even if nothing ever comes from this list it is a GREAT site and THANKS for all of the work.

 

XT :)

Link to comment

After exploring the capabilities of Microsoft MapPoint and GSAK which uses GPSBabel behind the scenes, etc I have to wonder if we really need this functionality on GC.COM.

 

The way I do it now is to use MapPoint to get the Lat/Long for multiple points along the route and paste those into GSAK. Apply the filter and I have my cache list. What benefit would I get from doing this on the GC.com web site instead of offline using GSAK? I realize not everyone uses GSAK, etc so that is one drawback to the method I'm using now.

 

Zack

Link to comment

One advantage to doing it on GC.com instead of GSAK is that you don't have to download a slew of extra caches to get the subset you want.

 

Imagine you want to drive from California to Florida. Using the GSAK method, you'd have to spend a week running a few dozen PQs in big circles, getting over 17,000 caches delivered to your mailbox. Then you run it through GSAK and the ARC filter to filter it down to the 1,000 or so caches along the route.

 

Now lets look at the GC.com method. You specify the route, maybe splitting it in 2 or 3 segments to keep each under 500 caches. Set up those PQs to run right away and within a few minutes have those same 1,000 or so caches delivered with no waste.

 

Disclaimer: All the numbers above are estimates. Your mileage may vary. But since I may very well be doing that drive next May, I hope GC.com gets this implemented by then :)

Link to comment

AllenLacy, Hemlock and those who replied by email - good points about not having to download overlapping circular queries. There's also the issue of how current the data is. By performing the query on the GC.com server you'll be querying against the most current data.

 

So, Jeremy, any progress to report?

 

Zack

Link to comment

I'm knid of curious how this is going to work from an enduser point of view.

 

How am I going to specify my route?

 

I mean, for someone who doesn't know exactly the coords of their route, how would they do it? Say, if I'm traveling from Charleston, SC to Atlanta, GA; I know I'd be taking I-26 to Columbia and then I-20 to Atlanta. Will we be able to specify our routes like this?

 

Thanks.

Link to comment

Once again, let me shill for my simple idea to get this started. We can easily and quickly implement a PQ along a single line that requires only minimal changes to the current database logic and user interface.

 

In my idea, the PQ returns (up to) the 500 points nearest to a line connecting two coordinates, GC waypoints, or zip codes. Everything else works exactly the same as it does now.

 

It's not a full caches-along-a-route solution, but it meets many of the needs halfway.

 

For later on, when a more complex route can be specified, I recommend asking Dan to change EasyGPS to export a route to a simplified GPX format. That way, cachers can make a route in their GPS unit, send it to EasyGPS, and write it to a file that the site will understand. And it is standards-based.

Link to comment
That way, cachers can make a route in their GPS unit, send it to EasyGPS, and write it to a file that the site will understand.

Cachers could also make a route with waypoints from intersections that way as well - just not on the GPS. Strictly entering waypoints into EasyGPS.

Link to comment

I just used my current suggestion of PQs and Streets and Trips for a route from Chicago, IL to my in-laws in Chattanooga (a 660 mile trip). Using S&T, I easily broke the travel into five PQs. But the trick was also to limit my type of caching in the PQs. Since I'm traveling with my wife and kids, and am on a tight time frame, these were the criteria I placed based on the PQs:

  • Difficulty <3.0, Terrain <3.5
  • No multi-stage caches
  • No micros
  • No virtuals

With that criteria, I was able to get the entire trip into five PQ and have them saved and on hold ready to send before I leave on my trip. I pumped the PQs into Streets and Trips and came up with a list of caches within 1 mile of my route. The only thing that would have made this better would have been a favorites list to know which of the 86 caches matching my criteria are the good ones.

99e5ecc3-e71e-4b6b-82db-7e280e99152a.jpg

 

I threw on the Geodashing Points for the month, in purple and recalculated out to 2.5 miles from my route - and I've now got a potential of 154 points to find along the way.

 

So - until Jeremy and his magnificent crew get a more workable solution, I'm happy with a positive result, and I have also prooved that it can be done.

 

Now, the true question: how many will SWMBO let me find?

Link to comment
can you take all the Geocaches and put them into one csv file?  Only Lat, Lon, Name, & Waypoint.    How large is the file?  Can a member download it?

 

If file too large maybe just by state.    Then maybe a member could request a PQ by submitting a list of Waypoint names.

I think I see where you're going but there's a couple of problems.

 

If Jeremy is reluctant to share the simple, name, waypoint, lat, lon data with an outside source mapping website, I doubt that he would just download the entire list of 131,593 active caches.

 

Even if he did, simple Excel files can only handle 65K records. It would have to be subdivided by regional boundary. You'd have to pump that database into something much more robust to try and limit the results.

 

Of course, the biggest problem is that if you get the list of CSV caches it might take you quite a while to figure out which ones you want. By the time you get everything figured out, you would have stale data. Some caches might be archived or unavailable, and definitely, there'd be ones that you wouldn't get in a list of requested waypoints.

 

I think it's better to come up with a holistic solution that grabs the LIVE data and gives you the best results.

 

For example: in my test of the route above, I'm not delving too far into the caches that are along the route except a quick perusal. As the trip approaches, I'll request the PQs to run, and then I'll make a cleaner decision of what caches I'm going to try and hit based off more current data.

Link to comment

As far as handling the data, I use MS access which should handle that many entries. If there's only 131,593 active caches, that shouldn't be a very big file, so downloading weekly could be a posibility. As far a providing a list of 500 waypoints to be downloaded into a GPX file, I would think that this would use less processor time to compile.

 

I posted these as ideas to Jeremy to think about. When I was doing Y2K programming on Main Frame computers I had to move a lot of data in different ways, and across multiple platforms. As I work on creating solutions I will offer them to Jeremy for use on his servers.

Link to comment

I really can't wait for this feature. Before I bought MS Streets and Trips (a wonderful program), I used QuakeMap to first find the towns/major turns along my route, and then searched Geocaching by coordinates and downloaded the first two pages (to keep the distance from the point minimal). Then, I imported all the cache LOCfiles into QuakeMap and looked over my route, removing caches that I didn't want to do. Tedious, but effective.

 

I hope to see this feature soon, but I do have a few issues. Out here in the midwest/mountain area, not everyone uses the Interstates. For the trip I described above, it actually increased travel time by almost three hours - woohoo for small state highways! The problem with using a mapping feature like MapQuest is that it doesn't always suggest the route you want to take. If Jeremy were to impliment a feature like that, we would all be stuck using the "fastest" or interstate routes for caching.

 

What I would like to see, and I know it's been suggested before, is the click on a map to define your route. QuakeMap uses a similar feature to create routes that can be downloaded to a GPS. You start the route, click at a point, and it sets a point of the route there. Using a feature like this would allow users to follow their route, placing "points" at major turns, towns, etc. The interface would be able to read these user-selected points, and create what I understand to be either an arc or shape file (The technical details are a little over my head, but I've got the gist). From there, the interface could use a MS Streets and Trips-like code, looking x miles along the route, and even dividing the results between the user-defined points, depending on the length of the route. This means, as far as I can think, there is no need for users to either create a file or upload anything to the server for processing... All you would need is the interface and a map that knew what the coordinates were for the spots you were clicking. If this idea would ever be implimented, I would also make the points moveable... i.e., you could zoom in and "scoot" the point over if you missed the road a little bit.

 

Whew. There's my $0.02 :o

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