Jump to content

Geocaching And Traveling... Web Site Needs This


ArchHunter

Recommended Posts

It would be great to be able to find caches while traveling across country or across the county along your route. Similar to a query from specific spot but over the route. This is tough to explain but if you visit the McDonalds web site (I know... McDonalds! But it is a great illustration of what I am looking for.) and go to Restaurant Locator and then select Trip Planner, it will all make sense. Basically, you put in your starting address and ending address and then the distance off the route (width of corridor) you want to travel to find a McDonalds. This would be great for caches.

 

http://go.mappoint.net/mcdonaldsx/TripInput.aspx

 

This was done with MS MapPoint which I have used for similar applications. I am not a programmer by any stretch but it wouldn't be hard using MS MapPoint mapping database and the Geocaching.com's database of caches.

 

Anybody else think this would be a good idea?

 

Thanks for listening. :laughing:

Link to comment

Anybody else think this would be a good idea?

 

Everyone except the guy who ownes the place ;)

if the "guy who owns this place" makes this statement in the link posted above

 

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.

 

How can you imply that he doesn't like the idea?

Link to comment

Anybody else think this would be a good idea?

 

Everyone except the guy who ownes the place ;)

I bet if the guy who owns this place had more people paying to be members of the site he might have enough money that he didn't have to make statements like this one.

 

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.
Edited by webscouter.
Link to comment
I bet if the guy who owns this place had more people paying to be members of the site he might have enough money that he didn't have to make statements like this one.

 

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.

Ya mean people like this guy?

Everyone except the guy who ownes the place ;)
Link to comment

I'm sure it's probably been said a gozillion times in several threads, including Jeremy's pinned thread, but I'll say it again here to help folks such as the OP.

 

While this feature may not be a part of the web site, it's still something that can be done relatively easy on your own, with a Pocket Query from here and other software that you might already have.

 

A program called GSAK (which stands for Geocaching Swiss Army Knife) can take a PQ and filter out the caches along a path. You can use mapping software and mark waypoints along the path, and then upload these into GSAK for it to use as the filter path.

 

The result will be exactly what you're looking for. You can then output from GSAK the waypoints for the caches along your route, as well as HTML pages to load into a PDA if you have one so you can cache paperless.

Link to comment
The result will be exactly what you're looking for.

Well, no, the "end result" ISN'T EXACTLY what people are want. We want the ability to get JUST the caches along our route, NOT download 5-10 PQ's to cover a route, to get the 30-40 caches along it, that could come in ONE "along your route" PQ.

Link to comment
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.

I don't understand how an alternative mapping provider would solve the "caches along a route" problem. Essentially this problem has nothing to do with the maps.

Link to comment
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.

I don't understand how an alternative mapping provider would solve the "caches along a route" problem. Essentially this problem has nothing to do with the maps.

Sure it does. How else is the site going to find caches along my route, if I don't have a way to tell the site my route? I know my mapping software on my PC has a "find along route" feature, so if the site could afford a web based version for us to use, instead of searching for POI's like mine does, it'd search for caches.

Link to comment
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.

I don't understand how an alternative mapping provider would solve the "caches along a route" problem. Essentially this problem has nothing to do with the maps.

Sure it does. How else is the site going to find caches along my route, if I don't have a way to tell the site my route? I know my mapping software on my PC has a "find along route" feature, so if the site could afford a web based version for us to use, instead of searching for POI's like mine does, it'd search for caches.

You upload or enter waypoints along the route. No map is needed. And if you want to click on the map to mark waypoints, that must also be possible with the current maps. I don't see why a different map provider would be needed.

Link to comment

It's simple. A map is just a 2d image. The mapping *software* provider gives you more than just "maps", it gives you a way of referencing a specific piece of the map so that you can get just a piece of the map that has the coordinates you're interested in centered on the piece that it returns when you ask it for the place of interest to you.

 

Nothing in that procedure tells you *anything* about the actual image other than the left/right and top/bottom borders to stop drawing the image.

 

The mapping software provider *could* give you something more intelligent. It would know more information about the map like where the roads are and what coordinates are in close proximity to the roads. Now, you're asking it something more than just to center the image for you at the right zoom. Most mappping providers don't do all that work. Why should they when they can still charge a big price just for having good images and a simple software package. This means whoever programs this has to do more...therefore they can charge you more for their services... A lot more.

 

Ta-da.

Link to comment

If the user is willing to define his route himself by providing a set of waypoint along the route then there is absolutely no map of any kind needed to come up with a list of caches along that route. Therefore the high cost of some maps having certain features is by no means an excuse for not implementing the "caches along a route" feature.

Link to comment
If the user is willing to define his route himself by providing a set of waypoint along the route then there is absolutely no map of any kind needed to come up with a list of caches along that route. Therefore the high cost of some maps having certain features is by no means an excuse for not implementing the "caches along a route" feature.

A route is a continuum of waypoints, not a set of them. Then you get into questions of radius from the continuum or lost caches on the route due to the discretization of the continuum into a set for ease of use of the data, and roads not travelling in a straight line...

 

All of this has been hashed out before in a number of threads. The point is to try and do this within the context of the tools at hand already and spend the least amount of money on commercial products to do so.

 

I think my point is made, but I doubt you will accept it as an explanation for why this isn't just a simple problem to solve.

Link to comment

And if the site does provide such a thing, some people will complain that they were taken along an interstate rather than a scenic bypass. And other people will complain that they were directed to a back road rather than something more direct. And if the site doesn't generate the routes, then people will gripe about how hard it is to enter their routes. It sounds like a huge can of worms, and a perfect reason for people receiving a free/cheap service to complain even more than they do now.

Link to comment

The problem (while perhaps not simple) HAS been solved in GSAK/GPSBabel for a couple versions now and does not rely on any mapping provider. It will be as accurate as the set of points which you give it.

 

You can compensate for inaccuracy in the number of points by using a greater radius.

 

And a big radius with a whole lot of over-compensation is exactly what people are ALREADY doing now on gc.com - they use state (based on a user-set criteria which requires no calculation) or a large circle - that's a route with one point and a real big radius. They take all those into GSAK and let it do the work.

Link to comment
And if the site does provide such a thing, some people will complain that they were taken along an interstate rather than a scenic bypass. And other people will complain that they were directed to a back road rather than something more direct. And if the site doesn't generate the routes, then people will gripe about how hard it is to enter their routes. It sounds like a huge can of worms, and a perfect reason for people receiving a free/cheap service to complain even more than they do now.

There are a lot of solutions to the problem. Rectangular searches where you provide your own boundaries. A radiuse search on a series of waypoints (interstate exits). A map where you can select the rectnagles that correspond to your route (similar to how Garmin does it's mapsource topo) and so on. Each solves the problem but has limitations and a different approach to the solution. The solution you propose has the site generate the route much like mapquest would. You could also set it up to let you pick road segments on a map, then you specify how far on each side of the road you want to search. Or upload a route from a mapping program or GPS and use that to set the distance search...

 

No one solution is going to nail the issue perfectly. It's the nature of the beast.

Link to comment
A route is a continuum of waypoints, not a set of them.

Well, in that case the problem is unsolvable because there is no storage device that can store a continuum of waypoints :o

 

As for the rest of your post, I don't see any issues. Both mathematically and computationally, the problem is trivial. You have a set of points connected with straight segments, find the subset of caches closer than a distance R from the set of these segments (and not the points of course).

Link to comment

The current situation has geocaching.com providing the raw material (cache data) and for other software (GPS Babel, GSAK, etc) to do the processing to meet the specific needs ("along-a-route" selection, uploading into GPSr, formatting for superimposing on maps, etc).

 

I think that for the immediate future everyone needs to come to grips with the idea that this division of labor and technology is not changing anytime soon.

 

The place where the biggest problem occurs for us users is the artificial limitation of 20 PQs of which only 5 can run each day and each can only return 500 caches. Because of this limitation it is nearly impossible to create the types of datasets we need along routes through metropolitain areas, unless you spend many days accumulating such data (and then we have stale data and a tons of caches you really don't want or need). Many of us understand why Jeremy does not want to increase these numbers and we can respect that; the alternative is to allow us to generated datasets that are not defined by circles but rather by a series of connected lines with distances from the resulting "arc". Unfortunately that programming challenge appears to be too difficult for the programming staff to deal with. It is not clear why, because we know that GPS Babel has the computing power, and that software is available to Jeremy for implementation directly. (It is also the engine that GSAK uses).

 

Until we get this feature we are stuck collecting massive amounts of data for off-line databases (which Jeremy also would rather not have us use). But what are we supposed to do? Not geocache along our summer travels? ... :o I think not :D

Link to comment
I think that for the immediate future everyone needs to come to grips with the idea that  this division of labor and technology is not changing anytime soon.

You've probably read about the strain the PQ system is under. It's been mentioned there that the number of caches is a major factor.

 

We were told that extracting the list of caches is the thin side and extracting all the details and logs is the fat side of the 80/20 rule on this process. That's why the preview runs so quickly, yet a daily PQ will often not be handled on a busy Friday.

 

I've already been told in another thread that getting less caches will always be more efficient, and the solution they recommended WAS a more complex PQ definition (all individual states I'd found caches in, plus the None state). Now in SQL, I know that processing a WHERE IN clause is much slower than most other regular WHERE clauses, so I know this PQ has to be slower in theory to get the list of caches, but since it produces less caches, it is actually more efficient overall. It's like starting your car. If your car took 5 minutes to start up every time, and you only took long trips, you don't care.

 

If we're talking about division of labor, then reducing the number of caches through a better selection criteria MAY help. It all depends on whether the act of selecting the caches according to more complex criteria can be done efficiently. So the question is which process is one we want to be aiming towards: 5 (or more) PQs each returning 500 caches (to give you 2500 caches where you find 335 along a route) vs. 1 more complex PQ only returning the 335 caches.

 

I think it is a little silly to say "we won't build anything to accomodate the caches-along-a-route people until we can follow a highway route exactly and guarantee that no caches are left off and the route is always the perfect route that this cacher wants to drive" and at the same time say "we don't want people caching with stale data", "we have to limit PQs to 5/500 caches because of system strain", "people shouldn't be maintaining offline databases", when there are a few workable approaches (rectangles, lines, etc) to give people a few more PQ options which mitigate all those - they aren't perfect, but at least they are an incremental improvement (less strain on PQ system, less complaints here).

Link to comment
The result will be exactly what you're looking for.

Well, no, the "end result" ISN'T EXACTLY what people are want. We want the ability to get JUST the caches along our route, NOT download 5-10 PQ's to cover a route, to get the 30-40 caches along it, that could come in ONE "along your route" PQ.

Yes, the end result IS exactly what people want. You just want a different way to get to that result.

 

I understand that sometimes using this method uses up a lot of PQs, but it's the best way to get the result so far. I wasn't suggesting that nobody should want a different method, I was only trying to help the new people in the mean time.

 

People have helped me from time to time in the forums, so I'm just trying to give back.

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