Jump to content

Caches Along A Route


Jeremy

Recommended Posts

All right. One of the most popular requests ever has been to have a list of caches along a route. I've been in discussion with a mapping provider as a possible alternative, but maps can be verrry expensive. Cost prohibitive, in fact, so I've pretty much tossed that one out as an idea.

 

So I'm creating this topic in the hopes that we can have a technical discussion about how to ultimately create a feature everyone (including me) wants.

 

My first thought was using the arc filter capability available in GPSBabel and folks could submit their own arc files of possible trips. I could update the PQ Generator to run against those filters and return a list of caches based on your additional filters, like type and terrain.

 

The shotgun approach I'm working on is allowing you to do a degree range, and ultimately a region (upper left and lower right coordinates) but that is still a poor solution.

 

Thoughts welcome.

Link to comment

Being able to upload arc files of a route would be awesome for power users, but I'm afraid most of the people willing and able to do that are already doing it locally. It would require users to use at least 1-2 other pieces of software to create the arc file.

 

Defining a rectangle is far less optimal, but probably easier and less complicated for most users, and would still help them limit PQs to the areas they want.

 

Possibly a combination of both would make everyone the happiest.

Add a retangular region option to the other PQ options, AND allow users to upload an arc file and filter the PQ against that for the more technically inclined.

Link to comment

When I first got involved with this discussion a while back, I remember looking up a number of ways that graphic programs draw paths. For example, in Photoshop you can lay a series of points and a definition of the arc between each of them and the kicker is to then apply any size pt brush to the path to draw the final line. In our application, this would allow you to define how far from the road you are willing to travel (straight line, not from the exits).

 

If I can find any of the old pages that I found useful on the web on this topic, I'll let you know.

 

I also remember someone saying that a list of exit waypoints for the federal highways is available. Given a specific distance from the exit that people would be willing to travel, you could treat each exit as a separate radial search and just return the combined results. If I were going down I-95 through MD then I could ask for 5 miles from every exit along I-95 in MD as a result. Not as useful as a specific "route" finder, and not as general for the routes people might want to take, but maybe a start.

 

EDIT: Something else I thought of (along the idea of saved arc filters) is that AAA has a series of different possible connections on the highways. If you order a "Trip-tik" they look up the route as a series of pieces and put the pages of those pieces into a single book that reads like the output of Mapquest Directions. The first and last pages are customized to your start and end points by a salesperson and a highlighter. I wonder how many different pieces they have to cover the US and if that information (start-route-end for each piece) would be available from them.

Edited by ju66l3r
Link to comment

I've given this some thought. Since you're open to site changes, this does become a more practical problem to solve.

 

If the user can upload their own arc, I'm pretty sure we can make this simple enough for users. Provide a front end "upload your route here" with options for mapsend, mapsource, delorme .anr, GPX, "raw" .arc, and a sequenced list of geocaches (probably by GC#) a distance to search, and I think this is about as close to a solved problem as we're likely to get. I have to imagine that the travelling cachers have ready access to some kind of mapping program and know how to build a route with them.

 

If the output of the arc selection could then be fed as input into the current PQ filtering logic (I have to imagine that "find by zip", nearest GC #, etc. build a list which you're then doing a select on since you're surely not getting the great circle math in SQL) I think that's a viable technical solution that solves the problems for the users.

 

Regional clubs could provide arcs of the interstates in their area.

 

If you're willing to work together, I'm willing to make reasonable enhancements to GPSBabel if you need them. I could provide versions with trimmed down memory footprint, preselection on the bounding box of the route, or whatever we need if we find problems.

 

Tip: use GPSBabel's "simplify" filter on the incoming route to limit the number of point in the arc. Otherwise, the first person that upload a 25,000 point arc (i.e. converted from a Delorme ANR which contains every pebble in the road) and bounces that against 100,000 waypoints is going to be the source of much entertainment.

 

[ edit more thoughts and comments on those that came in while I was typing ]

 

No, Mopar, power users can't do this in a _practical_ manner locally. There are examples of requiring two days worth of PQs and a non-trivial amount of futzing to get the circles right.

 

Jeremy, I'd find being able to define a bounding box very useful. I'd find directional search not so useful. I could use BB to define corridors while "everything between 15 and 35 degrees" falls victim to the same kind of overspray over a large distance that the circles have

Edited by robertlipe
Link to comment

Since right now the code exists to spit out caches within a radius of a point, wouldn't it be easier to simply do that along a series of points?

 

IE, if I'm going from NY to Boston via Interstates, I could specify coords from NY to New Haven, CT to Hartford, CT to Worcester, MA to Boston.

 

For each of the four legs of the journey, simply spit out caches within overlapping radiuses from points along the line.

 

That would be easier for users who'd simply provide points at the turns of their journey rather than having to figure out degrees from a map. (True north or magnetic?)

 

Sort the results by lat or long based upon whichever had the greater difference (IE, which cardinal direction the travel is in) and eliminate duplicates.

 

I think that would beat a region (UL/LR coordinates) as so much travel wouldn't provide a lean/efficient rectangle but a huge square. (It would lead me as a user to generate multiple small squares in my aforementioned example as a rectangle with corners at NYC and New Haven, CT would include parts of Long Island on the other side of Long Island Sound! Hartford, CT to Worcester, MA is only a half-hour drive NE but a rectangle would include a quarter of Connecticut and about a sixth of Massachusetts!)

 

hth,

 

Randy

 

PS: A quick visual test on a map in a paint program leads me to believe points no closer than 150% of the radius of the circles would suffice as the distance from center to the interior of the scallops is about 73% of the full radius. (IE, circles with radii of 20 miles centered on points 30 miles apart come no tighter than 15 miles.)

Link to comment

How difficult this is to program I don't know, but:

 

I understand that you cannot let users just select a road, or start, stop points as you would need mapping software that was aware of what a road was, and potentially have some routing capacity.

 

Instead, given that a user will have worked out their route, could a system be implemented where they click on the gc.com maps to place route waypoints. These would form a list and an area could be defined from these (I'm thinking a sort of corridor, maybe 5-10 miles wide, following the path of the waypoints. Users would have to understand that they need to place markers wherever the road turns sharply, and at regular enough intervals.

 

This could then be translated into a PQ of the caches within the corridoor. Not easy, I would imagine, but it does remove the need for more mapping software. Maybe an agreement with the maker of GPSBabel could be worked out to take the algorithms used in that program.

 

Ideas anyway, AJK

 

EDIT: my answer is somewhat close to the one above, though I do like the idea of corridoors, as the shape of the area would likely match the needs of the cacher, IMHO.

Edited by AJK
Link to comment

Ultimately, it should be easy to use for the REGULAR geocacher to be meaningful. Those that are the hard-core users have already found work-arounds, even if they are difficult to implement.

 

I would suggest the idea would be for people to define a route through a set of coordinates. Users would enter the lat/lon AND SORT ORDER into a mini-spreadsheet. Then there would be an option to "check your route" - a command button that would then overlay that line onto a map so that people can double check that their route makes sense.

 

Once you have the route in, if I understand correctly, all the system needs is the distance from the route. So, it would be a matter of doing the arc view magic behind the scenes based on that list of waypoints, and (as Jeremy suggested) adjusting the results to match the PQ (type, size, terrain, etc.).

 

The point of this post is that those who are technologically savvy enough to create an arc file, are probably techno-savvy enough to get PQs and put it into Streets and Trips, or to use GPSBabel's features to do the same.

 

When this gets developed, it needs to be developed with the first-time route planner in mind.

Link to comment

On further reading, I can see my concept could be considered too gross.

 

Has anyone checked out this company? http://www.marcosoft.com

 

I use their QuoVadis mapping software on my Palm, based on Tiger vector line data, but scaled down enough to fit within a Palm's RAM!

 

Not only that, but when zoomed out, it filters out streets to only display Interstates. Although it doesn't numerically label exits, they are represented.

 

On Robert's other thread, these seem to be some of the main issues raised...

 

hth,

 

Randy

Link to comment

Markwell, are you suggesting that the technically impaired are MORE likely to be able to enter a bunch of coords and manually sequence them than they are to create a route in mapsend, mapsource, whatever, and upload that?

 

Remember GPSBabel can convert all of those formats (and more) to arcs behind the scenes - it would do that be decomposing that route to (taaa daaa) a sequenced list of waypoints.

Link to comment

This is probably something for the GPSBabel mailing list, but we also produce shapefiles of all the caches for our maps. Using those shapefiles against the arc filter would probably be the most efficient way of generating lists of waypoints.

 

My preference would be to run a query along an arc using shapefiles, and insert the results into a table that could be used to filter caches for a user. From that arc you could then indicate what caches you want by any other filter options.

 

Not exactly sure how arc filters would be shared, but you could upload an arc filter and others could choose it as part of their PQ by location options.

 

Finally, we are creating bookmarks, or lists, for users to create, so at a bare minimum somone could theoretically create their own waypoint lists along a route and others could create pocket queries out of them. Like for me I could create a list of Glacial Lake caches along I90 in Washington.

Link to comment
No, Mopar, power users can't do this in a _practical_ manner locally. There are examples of requiring two days worth of PQs and a non-trivial amount of futzing to get the circles right.

Sorry, I oversimplified things for the sake of this thread. No, it's not trivial, and the biggest problem is the "overspray" which is a huge waste of resources both for the user and for GC.com.

An example of mine is a recent trip from CT to DC. During the trip I was really only interested in caching along 75-100 mile or so stretch of highway. To filter that down to caches within a mile of my route, (about 100 caches) required 3 full PQs (1500 caches).

Judging by many of the other common problems posted here, many cachers are not technically inclined; quite a few have trouble getting waypoints uploaded to their GPS. So yea, I suspect having to create a route in one program, convert it to an arc file in another, then upload it to gc.com would be too complicated for the people most asking for the site to figure out caches along a route for them.

Link to comment
This is probably something for the GPSBabel mailing list, but we also produce shapefiles of all the caches for our maps. Using those shapefiles against the arc filter would probably be the most efficient way of generating lists of waypoints.

Yes, it probably is. At one time, I have a version of GPSBabel that would read shapefiles. I mentioned it on the beta list and nobody seemed to care so I never finished it. I still have the code in my scratch area. I wasn't really comfortable with the parlance of the tools used and remember finding it weird that you couldn't associate a name with a shape point, so I figured I was missing something pretty fundamental. Contact me with sample files and I'll dust that off.

 

My preference would be to run a query along an arc using shapefiles, and insert the results into a table that could be used to filter caches for a user. From that arc you could then indicate what caches you want by any other filter options.

While I've thought about (and even prototyped) a selection filter that would approximately model the PQ filtering options, I agree your approach is the right one for this case.

 

Not exactly sure how arc filters would be shared, but you could upload an arc filter and others could choose it as part of their PQ by location options.

That could be left for round II.

 

As I mentioned in the other thread, I really think that a collection of the really major roads would solve this for most folks. Folks wanting to share caches along their favorite bike ride or canoe run or whatever are a much smaller set from the roar I see in the forums.

Link to comment

Judging by many of the other common problems posted here, many cachers are not technically inclined; quite a few have trouble getting waypoints uploaded to their GPS.

While I agree a solution should be within reach for that crowd, the folks just now finding how to upload really aren't the ones trying to figure out how to cache along a 1500 mile drive.

So yea, I suspect having to create a route in one program, convert it to an arc file in another, then upload it to gc.com would be too complicated for the people most asking for the site to figure out caches along a route for them.

With my proposal, the middle step would be done by the web site. The upload dialogue would ask what kind of file it was. The site would then convert from mapsend/mapsource/delorme/whatever to an internally useful format behind their back.

 

And if it really is too much for a person to make a route (I just checked, it took me under 15

seconds in either mapsend or mapsource), express key points as caches or coordinates, the tiger data could be used to "prepopulate" picklists, as I suggested in my first response.

Link to comment

I think markwell's solution would be the easiest for most peple to do. Jus provide a place to enter coordinates. You can then add an option for power users to upload a route in various formats, that gpsbabel will then convert to an arc filter.

 

To share filters between users, you would have to create a special place, where people can upload and search for route filters. Might get kind of messy. There are website out there, where people can share gps data. like this one: http://www.trailregistry.com/trailregistry/index.jsp

 

it would be easy to save the route people entered as a GPX file (non-gc.com) and then people can share those.

Link to comment

I have to agree with robertlipe. Forcing people to enter in one waypoint at a time is pretty tedious, and GPX is pretty gross. XML in general is wonderfully readable but there's a ton of fluff in there. Arc files are much more compact and ultimately better.

 

If we can get the major highways in arc format for people to use, that will get the majority of requests. I also like this as an international solution. My bet is that people will come out of the woodwork with new arc filters once this feature becomes available.

Link to comment
If we can get the major highways in arc format for people to use, that will get the majority of requests. I also like this as an international solution. My bet is that people will come out of the woodwork with new arc filters once this feature becomes available.

I agree. I think that if you make some effort to cover most of the "major" highways you will cover a majority of the requests. If users are given an oppurtunity to upload arc filters they've created (there would need to be some minimum guidelines probably - to check for accuracy) I'd bet you'd have a lot of submissions.

 

The more technically challenged users could use the default (major highways) and submitted arc filters other users created.

 

There's no realistic way for people at Groundspeak to know what people in all 50 states as well as other countries consider major roads - but the locals will and eventually those routes will be supported. And you can bet that if somebody comes up with a vague request, somebody out there would create the arc filter just to say they did it :laughing:

 

------

 

Am I correct in assuming that this would be an added feature to PQ's?

 

There could be a drop down menu of Arc filters. There are quite a few options for searches as well.

 

southdeltan

Link to comment
A drop-down may not work in this case, especially when we have thousands of them in the database! I don't know the best way yet, but if each one had a code you could enter the arc filter code on the page.

Didn't think of that.

 

Maybe users should include the states that the route covers in their submission and you could search by state? Perhaps by the origin or destination? I know that many of the major routes will cover several states, so there are lots of things to consider.

 

sd

Link to comment
My bet is that people will come out of the woodwork with new arc filters once this feature becomes available.

I think that's a safe bet. GSAK already has the ability to import coordinates for arc filters from various sources and I could see Clyde adding the abiltiy to export these filters in what ever format goecaching.com settles on.

Link to comment

Take a look at the left column of http://www.zenrin.com/exitInformation/fields.asp and see if you really think picklists are out of the question. I'd bet a couple of days munching on the tiger database could get us that for the US.

 

The reason I'm focusing on major roads (being defined as interstates in the US) is that if you're travelling far enough that you're bumping into the limits of the current PQ scheme, you're *probably* doing it on an interstate or one of the state highways that runs rag-tag with them. Once you're close enough to be off the major roads, the existing circle based PQ isn't so bad. If you can provide a 'canned" solution fo the folks and the ability to do custom routes for the others,you'd be a hero.

 

Look again at JamieZ's map linked to above. If he could have picked

I-20 in LA+

I-20 in TX+

TX 287 +

I-40 in TX+

I-40 in NM+

I-40 in AZ+

I-40 in CA+

I-15 in CA

 

in one PQ, I'm guessing he'd have been a happy man. (Knowing JamieZ's a big boy, he'd have uploaded a route, but work with me on this example.)

 

I'm guessing he could have gotten over the fact that I15 in CA goes places he wasn't travelling to (as does I20 in Louisana) and that he'd have had to pull traditional circle caches to get past the blur of Los Angeles and the major-roadlessness of Greenville down to Monroe. The amount of overspray is still much smaller.

 

Speaking of my own travels, there's usually 2-4 interstates over 2-5 states. It usually takes me 3-5 PQ just to get the bulk of the driving in plus one for the area I'm staying in. (I'm way more likely to tackle a 4/4 when staying at the sister-in-laws for a week than I am on the 600 mile drive to get there.)

 

I think it could be staged very nicely.

Step one: users upload their own routes.

Step two: major roads harvested from Tiger.

Step three: local "maintainers" allowed to add routes to the picklists.

 

If we had step one today, I'd add routes for all the interstates in the TN area to http://www.mtgc.org tomorrow. (Resists urge to fuss much about the club not being linked to from gc.com any more...)

Link to comment
Maybe an agreement with the maker of GPSBabel could be worked out to take the algorithms used in that program.
GSAK already has the ability to import coordinates for arc filters from various sources and I could see Clyde adding the abiltiy to export these filters in what ever format

 

Note to self: time for a new PR manager.

Link to comment
GSAK already has the ability to import coordinates for arc filters from various sources and I could see Clyde adding the abiltiy to export these filters in what ever format

 

Note to self: time for a new PR manager.

Full credit to GPSBabel for it's part in driving GSAK but Clyde was able to extract route points from a ST2GPX gpx output file something I was never able to get Babel to do. The fault is probably mine :laughing:

Link to comment

If each arc filter is annotated with its starting and ending point, then asking for the 10 smallest paths that goes from point A to point X in the network is solvable.

 

Therefore, a text match to the nodes of the network would be all that you'd have to get as input. The answer will be as good as the network of arc filters available.

 

Example: Boston to Baltimore...returns:

 

Boston to Sturbridge to Hartford to Danbury to NYC to Cherry Hill, NJ, to Elkton, MD to Baltimore

 

OR

 

Boston to Providence to New London to New Haven to NYC to Cherry Hill to Elkton to Baltimore

 

And after it returns a few potential routes that the person is most likely to take (or be included within the range as Robert pointed out) then you could even option the replacement of any one specific point with 1-3 nearby points that can replace it...like replacing Sturbridge with Springfield (if the person wanted to use 91 instead of 84) since both Springfield and Sturbridge connect to Boston and Hartford....

Link to comment
The reason I'm focusing on major roads (being defined as interstates in the US)  is that if you're travelling far enough that you're bumping into the limits of the current PQ scheme, you're *probably* doing it on an interstate or one of the state highways that runs rag-tag with them.

But if you only make it available for interstates, then all you really need is "caches within X miles of the exits" so you'd just need lat/lon for the exits.....I mean who cares if there's a cache .3 off the interstate, if it's 15 miles either way to an exit?

Link to comment

Hi,

 

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?

 

Example: you are travelling west on route 90, and pick out 4 points that will describe a rectangle enclosing a stretch of 90 you will be driving on (be it 20 miles wide by 200 miles long, or 5 miles by 40). If your route across the country moved around, you could do PQs for a number of rectangles, both tall and wide.

 

Just an idea...

 

nfa

Link to comment

I know this is a technical discussion, but all this talk of uploading arc files is scary, from a user perspective.

 

Try to keep the user interface simple. Mapquest is a great model here, I've embellished a screenshot from their site as an example of how this should look to the end user:

 

67fb650d-bfd4-4ba5-9927-19cde04c5b84.jpg

 

Just input where you're starting from, where you're going to (and optionally any intermediate destinations), how many miles off-route you're willing to go for a cache (and probably should allow it to filter for cache type, diff/terrain, other criteria), and hit enter. Return a GPX and let's travel.

 

Use arc files if you wish but that's an implementation detail and should be invisible to the end user.

 

I'll leave the details of how to implement this to you, and yes I know it's not trivial. You might want to check with the guy who wrote MacGPSPro. (www.macgpspro.com) He has coded an algorithm to turn a www.mapsonus.com turn-by-turn driving route into a route that can be downloaded right into a GPS.

Link to comment
i would be willing to provide arc files for my reigon if that became a need, im sure there are enough people that wold do it to make things work.

Ditto that here.

 

I would also suggest if you choose the "exit" strategy to include "intersections" and include major US highways in the mix. A fair portion of my travels are over US highways since there are few interstates to choose from around here.

 

-E

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.

Link to comment
Try to keep the user interface simple.  Mapquest is a great model here, I've embellished a screenshot from their site as an example of how this should look to the end user:

 

....

 

I'll leave the details of how to implement this to you, and yes I know it's not trivial.

This is pretty much impossible to implement using free data. In my first post I indicated that this is too expensive to implement. MapQuest has deep pockets. We do not. Mapping pricing strategies, in general, are either pay-per-use or an infinite license, both of which are way too much for how we use these services.

 

You might want to check with the guy who wrote MacGPSPro. (www.macgpspro.com) He has coded an algorithm to turn a www.mapsonus.com turn-by-turn driving route into a route that can be downloaded right into a GPS.

 

Robert has done some amazing things with GPSBabel, and I wouldn't be surprised if he or some other developer could implement a mapsonus -> arcfile conversion if they so chose, since it is just essentially scraping the lat/lon on the results page on that site. However, it does seem to violate the terms of use of the mapsonus.com web site, and relying on unsupported functionality on any site is a poor way to go about doing things.

 

However, you may not, without express written permission from Switchboard, reproduce, reformat, modify, translate, or transmit results from any Maps On Us search.

 

I believe, like Robert, that if we had an arcfilter for the major highways, and you could choose the highway as part of your search, the result set would work for the majority of users. After we perfect this technique we could add additional arc filters for specialized requests. And if GPSBabel could build arc files, GSAK would do it, and so forth.

Edited by Jeremy
Link to comment

I have done this the hard way, by selecting a number of points along the route, allowing some overlap of the circles, and then let gpx2html eliminate the duplicates. It works, but is tedious. It would seem that there are a couple of good ways, or more, to do this. First of all, for major interstate highways, a data base of coords could be set up so that the user simply specified the highway, a start and ending point, and a lateral distance that would apply on both sides of the highway, and the software did the rest. For less well traveled routes, the user could specify a number of points and a lateral distance, and the software would create rectangles between the points and list all the caches in all the rectangles. It would be great if the input would work graphically from maps, but that's asking a lot.

 

FWIW,

CharlieP

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.

Hi,

 

Thanks, and sorry for double-posting...didn't understand the 2 point system until I drew it out :laughing:

 

nfa

Link to comment

I'm with Markwell, Lowracer, and Lazyboy. Please remember that not all geocachers are techies (or 'big boys' in RL's snob-speak :blink: ). This should be a feature that is useable by the average soccer mom and grandfather.

 

My apologies to those soccer moms and pop-pops that are technically advanced. :huh:

Link to comment
We really should have some place to hold discussions like this. Apparently, pointing out in the subject or first sentence that it's to be a technical one isn't enough.

Isn't designing a user interface (that is usable by the average geocacher) part of the technical aspects?

Geocaching started as a geek hobby, but it's evolved way past that. The recent addition of the cache size "eye-candy" to me shows that the average site user these days is not technically inclined. No offense to NFA, but I think he is the typical geocacher, and he had problems visualizing a 2 waypoint bounding box.

Whatever way you do it needs to be usable by the grandfather that needs a post-it note to remind him of the steps needed to get to his email. It needs to be usable by the soccer mom who enters the waypoints manually for each cache, because easygps and loc files are too complicated. Those are typical geocachers. The people like Robert who can can create arc files of routes and filter caches, already are (even if not by the most efficient way). It's guys like NFA and LB&MM that are asking for simpler ways to get caches along a route. Whatever you do, don't make it too complicated for them to use it.

Link to comment

I am trying desperately to avoid the forums, but I think I ought to add my two cents' worth here. I think that this is a difficult problem, and worth our discussion.

 

First: The math for calculating the distance from a point to a route is done. GPSBabel does a fine job. I wrote my own algorithm to do it, which also works fine.

 

Second: I don't like the idea of having people upload GPSBabel arcs. For one thing, I don't like that name for it: arcs make me think of differentiable functions (yeah, I know they don't have to be, it's just me). They probably make most people think of portions of a circle. For reasons of standards, I think that if people can upload paths, they should be done as a GPX route.

 

I much prefer the idea of having fixed pre-defined segments for most people to use. In fact, the data required for this is all publicly available; the Tiger database has all major highways in it. Making this data into a graph is doable, but presenting a useful user interface is a little trickier.

 

One possible solution is this: somebody writes an application using MapPoint data and its routing algorithms that allows the user to interactively generate a route. The app saves the route as a GPX file, which it then sends to goecaching.com (via a Web service, perhaps?) and makes into a PQ. Because of the licensing issues, the author would have to charge for the program. However, for those who don't use Windows, or those who know how to do routes themselves, the route-to-PQ facility would still be available.

 

Clearly, this facility needs to enforce limits: maximum number of nodes in the route, maximum number of waypoints returned (although I would allow > 500 caches for these queries, and maybe "charge" more than 1 PQ for each).

 

In addition, on the site I would allow for simple straight-line PQs that consist of caches within a given distance between a straight line between 2 points. That would probably be a good solution for about 80% of what people want to do with route-based queries anyway; planning a trip would require a series of straight-line queries instead of a (much larger) series of circular queries.

 

Those are my semi-random thoughts for discussion. Go at it.

Link to comment
Second:  I don't like the idea of having people upload GPSBabel arcs.  For one thing, I don't like that name for it:  arcs make me think of differentiable functions (yeah, I know they don't have to be, it's just me).  They probably make most people think of portions of a circle.  For reasons of standards, I think that if people can upload paths, they should be done as a GPX route.

Fortunately,that's a pretty easy thing to flip at the last minute. As I mentioned, if user-uploadable thingies were to be supported at all, there's no reason for the user to know what's going on behind the scenes. Upload it whatever format you like (gpx, mapsend, mapsource, delorme, etc.) and have the site convert it behind the scenes before handing it to the program doing the trig.

 

I much prefer the idea of having fixed pre-defined segments for most people to use.

Though in my head, I know I know the user-uploadable thing could be made to work, I, too, am leaning toward making it mutiple choice from options provided by known good sources. (The first person to upload "I-40" with coordinates in Elbonia will have no friends left...)

 

In fact, the data required for this is all publicly available; the Tiger database has all major highways in it.  Making this data into a graph is doable, but presenting a useful user interface is a little trickier.

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.

 

Tiger, of course, doesn't help the folks outside the US.

 

Your points about PQ limits are good ones. Thanx for a thoughtful response.

Link to comment

Robert has done some amazing things with GPSBabel, and I wouldn't be surprised if he or some other developer could implement a mapsonus -> arcfile conversion if they so chose

It's totally the wrong way to design a service around, but an interesting trick for infrequent personal use that just happens to involve GPSBabel.

 

Wayhoo has instructions for taking the mapsonus directions and feeding them to an (old) GPSBabel. You can then get that file in a variety of formats and converted it for use it for feeding to the filters we've been discussing elsewhere. It's kind of klunky but for all those people planning cross-coutnry geocaching trips that down own mapping programs, it's probably not too terrible.

Link to comment

First off, I must be honest. I didn't read all the posts to see if this was suggested.

 

However, I was actually thinking about this in the last week. I was considering writing a patch for GPSbabel which would take a route or a track (which it can already parse) or a list of waypoints and then from that "line" do a polygon expansion around it to get the filter Iwanted automatically. Saying "2 mi" along the route would mean taking each line segment and making a polygon perpendicular to it (and extending it both directions by 2mi as well) and then overlaying all the polygons (or running each seperately and combining the results, removing duplicates). The line to polygon math is not hard (can you say "cos" and "sin"; I knew you could).

 

Thus, you could do the same thing on gc.com... Simply have users submit either a route extracted from mapsource (or something) or something more generic like a list of waypoints (which is really all a route is anyway). The calculation on your end I don't think would be too CPU intensive (though I'm sure it would be a PQ only feature).

Link to comment
First off, I must be honest. I didn't read all the posts to see if this was suggested.

 

However, I was actually thinking about this in the last week. I was considering writing a patch for GPSbabel which would take a route or a track (which it can already parse) or a list of waypoints and then from that "line" do a polygon expansion around it to get the filter Iwanted automatically. Saying "2 mi" along the route would mean taking each line segment and making a polygon perpendicular to it (and extending it both directions by 2mi as well) and then overlaying all the polygons (or running each seperately and combining the results, removing duplicates). The line to polygon math is not hard (can you say "cos" and "sin"; I knew you could).

Check out the arc filter. It basically does that already.

 

--RuffRidr

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.

Hi,

 

Thanks, and sorry for double-posting...didn't understand the 2 point system until I drew it out :anibad:

 

nfa

:) I don't believe that using two points(LL, UR) will always define the same box. If the road runs exactly north/south or east west then the two points would work. But if the road runs NE-SW or SE - NW (diagonally, the box is not centered around the road. A technique used by some army systems is what is called a thrust search. You give a start and end point, and a width from the center line. This provides the ability to define a box on any orientation. Using only two points would require an Attitude (orientation) to skew the box to the correct orientation. How to program is for folks a lot smarter than me.

Link to comment
The reason I'm focusing on major roads (being defined as interstates in the US)  is that if you're travelling far enough that you're bumping into the limits of the current PQ scheme, you're *probably* doing it on an interstate or one of the state highways that runs rag-tag with them.

But if you only make it available for interstates, then all you really need is "caches within X miles of the exits" so you'd just need lat/lon for the exits.....I mean who cares if there's a cache .3 off the interstate, if it's 15 miles either way to an exit?

The webmaster of Floridacaching.com purchased some sort of software with the coords of all of the reststops in Fla (and I believe it has coords for all Interstate exits too). From that he was able to setup some pages that let you do a search for close caches. Maybe the same thing could work here. Maybe you choose which interstae you will travel, then check, checkboxes for the exits you will pass and those coords are fed into GPSBabel as the arc filter.

 

As a side note, I drove from Jax, Fl to Chicago, Il this summer and logged my entire trip to my Palm IIIxe in Cetus GPS (via my SporTrac & a null modem adapter). I had it save track data every 2 seconds for the entire trip (less than 700K if I remember correctly). When I got home I converted that track file into an arc file for use with GPSBabel so that next time I make the drive I can filter caches along the entire 1000+ mile route. I've tested it out (it took 2 days worth of PQs) and it works great. The only way I can see it really being a benefit to others is if I broke it into resonable sections (ie.. I-10 from Jax to I-75, I-75 from I-10 to I-24, I-24 from I-75 to Penneyrile PKWY, etc..)

 

Edited because my 2 fingers that can type can't spell

Edited by clan_Barron
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.

 

We'll just have a downloadable .loc file that people can put in their gps units.

 

We'll have a trailguide in PDF which coveres the entire trail with maps. We won't give the exact cache locations on the map, but will indicate which section of the trail they are on and in what order.

 

The new trail is all GPS driven. We did the old one, three years ago with a compass. The accuracy of the GPS mapping, directions and distances has made working on the trail much easier.

 

The old Trail, which has 3 caches on or near it can be found at www.ioncommunity.com look at the village walk pages.

 

I've been using expert GPS for this.

 

The challenge is keeping the entire trail under the 50 waypont limit on an etrex, the most common GPS unit. :)

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