Jump to content

Search for caches along a route


parkrrrr

Recommended Posts

quote:
Originally posted by Elias in the General forum

The problem is the interface we'd have to create so you could tell us what your route is. Serious thought has to be put into how to order and store that data, whether the data is just waypoints, highway vectors from a shape file, geocoding of addresses, etc... This would really be its own feature and there's a lot more to this to do it correctly. I'm not saying its not doable, but its certainly way out of scope for the purposes of this search feature.


Geocoding of addresses seems a bit extreme, to my way of thinking. As to whether it's waypoints or vectors: well, it's probably both. If I want any cache that's within a mile of Interstate 69 between Fort Wayne and Lansing, I should really only see caches that are within a mile of an interchange. If I want any cache that's within a mile of US 30 between Fort Wayne and Chicago, though, I should probably get any qualifying cache since that's (mostly) not a limited-access highway.

 

The data for the US highways and Interstates isn't really that huge, and you don't need ridiculous precision; I suspect most people wouldn't gripe if their "within 10 miles" search gave them something 11 miles away. You could probably get by with this database.

 

I'm not sure how the interface would work, though. For example, let's say I want caches between Jackson, MS and Lake Charles, LA on Interstates 55, 12, and 10. Oops... which way were you planning on going on I-12 to get to I-10? The short way, obviously, but computing "the short way" might be a lot harder than seeing it on a map.

 

Maybe the best way is to create some sort of custom query that can take a list of waypoints and a list of vectors and return the caches that are close to any of them, then offload the actual creation of those lists onto a fancy GUI application running on the user's computer. Groundspeak could even make some extra money by distributing such a "route search" application on CD with the supporting NTAD database; I'm pretty sure I'd pay reasonable money for a copy.

 

warm.gif

Link to comment

I'm replying here since it doesn't apply to the other topic.

 

quote:
Originally posted by Warm Fuzzies - Fuzzy:

I've been thinking about the "caches along a route" question, and trying to find a way to offload the actual computation of the route and the finding of the caches onto the user's computer, as mentioned in my mostly-ignored post over in the Geocaching Discussion forum, and it occurs to me that for that application, it would be nice if there were a search that could return the ID, lat, and long of any caches within a given rectangular area. This seems like an easy query to write, depending on your database structure, and it seems like it would take less time than even the standard "caches near " search, since it's just a pair of ranges rather than a complex distance calculation. Given that it's already possible to do virtually-unlimited queries for caches within a circle, and given that those queries are more expensive to geocaching.com than the simpler rectangle-based query (which, in addition to being easier to search, wouldn't have to send as much filler text) wouldn't it make sense to add the rectangular query for those who would like to layer more functionality on top of the geocaching.com database without adding undue server load in the process?

The zip code and radius searches we do now basically do a search within a square. We use the radius and a little math to determine the "corners" of the square and get all caches within that square. We do a distance from center check on only the result set, and throw out everything not within the circle. The stored procedure that we use to do this looks really ugly, but the overhead added by the little math we do is negligible.

 

You're correct that adding a rectangle search would be trivial. But to my knowledge, no one has ever asked for it as its not a very user-friendly method of searching. Most people want to know what caches are nearby, and needing to know the coordinates of the corners of a rectangle isn't very convenient for most. However, I can see how this might be useful to someone who wants to see the caches within a long and narrow rectangle centered around an interstate (for example). Expanding on this idea you can quickly see that one possible method of determining caches along a route is to chain a series of rectangles together from route point to route point and run a rectangle query for each rectangle.

 

But again, for me, its not the backend I'm concerned about. Since there's very real development time involved in this feature, I need to make sure that its set up in such a way that its easy and useful for the majority of geocachers. I threw out some examples like geocoding which may ultimately be silly, but since the spec hasn't been written, the sky's the limit (at least for now). icon_wink.gif

 

What I'd like to know from the community is how they want to interact with this feature. How does one convey their route? How do we return the results in a meaningful way (discrete coordinates of caches, or are they ordered in some way based on your direction)? These are the kinds of questions that I think will really help define what this feature will need to do.

 

-Elias

Link to comment

I'm replying here since it doesn't apply to the other topic.

 

quote:
Originally posted by Warm Fuzzies - Fuzzy:

I've been thinking about the "caches along a route" question, and trying to find a way to offload the actual computation of the route and the finding of the caches onto the user's computer, as mentioned in my mostly-ignored post over in the Geocaching Discussion forum, and it occurs to me that for that application, it would be nice if there were a search that could return the ID, lat, and long of any caches within a given rectangular area. This seems like an easy query to write, depending on your database structure, and it seems like it would take less time than even the standard "caches near " search, since it's just a pair of ranges rather than a complex distance calculation. Given that it's already possible to do virtually-unlimited queries for caches within a circle, and given that those queries are more expensive to geocaching.com than the simpler rectangle-based query (which, in addition to being easier to search, wouldn't have to send as much filler text) wouldn't it make sense to add the rectangular query for those who would like to layer more functionality on top of the geocaching.com database without adding undue server load in the process?

The zip code and radius searches we do now basically do a search within a square. We use the radius and a little math to determine the "corners" of the square and get all caches within that square. We do a distance from center check on only the result set, and throw out everything not within the circle. The stored procedure that we use to do this looks really ugly, but the overhead added by the little math we do is negligible.

 

You're correct that adding a rectangle search would be trivial. But to my knowledge, no one has ever asked for it as its not a very user-friendly method of searching. Most people want to know what caches are nearby, and needing to know the coordinates of the corners of a rectangle isn't very convenient for most. However, I can see how this might be useful to someone who wants to see the caches within a long and narrow rectangle centered around an interstate (for example). Expanding on this idea you can quickly see that one possible method of determining caches along a route is to chain a series of rectangles together from route point to route point and run a rectangle query for each rectangle.

 

But again, for me, its not the backend I'm concerned about. Since there's very real development time involved in this feature, I need to make sure that its set up in such a way that its easy and useful for the majority of geocachers. I threw out some examples like geocoding which may ultimately be silly, but since the spec hasn't been written, the sky's the limit (at least for now). icon_wink.gif

 

What I'd like to know from the community is how they want to interact with this feature. How does one convey their route? How do we return the results in a meaningful way (discrete coordinates of caches, or are they ordered in some way based on your direction)? These are the kinds of questions that I think will really help define what this feature will need to do.

 

-Elias

Link to comment

If you'll read my two posts again, you'll see that I'm suggesting that this sort of feature is better implemented as a standalone program or applet that runs on the user's machine and performs queries to get the results. The backend still runs on the geocaching.com server, but the frontend does not. That way, the interface is faster, can contain lots more detailed data, and can give instant feedback as you scroll and zoom around the map and so on. Also, the load that such a user-interface feature would put on the server is, except for the queries, put on the user's machine where it belongs.

 

How to interact with it? Just scroll around and click on roads to select them, building your route as you go. Something like ESRI's MapObjects LT or MapInfo's MapX, while expensive for the developer, would make this a snap for the user. Presentation of results? Let the user decide; once the results are found, showing them to the user in a different order is simple.

 

The point is that with just the simple addition of a rectangle search, you could push all these decisions off onto other developers and let the market decide.

 

warm.gif

Link to comment

This almost sounds like a money-making opportunity for Groundspeak. icon_smile.gif

 

Develop a standalone app that gives the user advanced cache searching and reporting features that you can't get on the site.

 

It could even interact with your GPSr similar to EasyGPS. Create your route on your GPSr, the route gets uploaded to the app, it automagically draws the rectangles around each segment of your route, queries the DB for caches, then downloads them all back to your GPSr, ready to go.

 

For something like that, you wouldn't even need a real user interface. Just an option to pick a premade route off your GPSr, and a way to specify the distance off the route to search.

 

You could also add features such as downloading maps or satellite pictures, taking all the caches you've found or the found set from above and putting them on the map.

 

Maybe an option for printing a simple one-page, graphics-free cache report for any cache.

 

Make it available to members. That'll get a lot of people to sign up! icon_biggrin.gif

 

(It's gotta work for Windows and OS X, though, or you'd annoy a lot of people... icon_mad.gif )

 

icon_wigogeocaching.gif

Link to comment

This almost sounds like a money-making opportunity for Groundspeak. icon_smile.gif

 

Develop a standalone app that gives the user advanced cache searching and reporting features that you can't get on the site.

 

It could even interact with your GPSr similar to EasyGPS. Create your route on your GPSr, the route gets uploaded to the app, it automagically draws the rectangles around each segment of your route, queries the DB for caches, then downloads them all back to your GPSr, ready to go.

 

For something like that, you wouldn't even need a real user interface. Just an option to pick a premade route off your GPSr, and a way to specify the distance off the route to search.

 

You could also add features such as downloading maps or satellite pictures, taking all the caches you've found or the found set from above and putting them on the map.

 

Maybe an option for printing a simple one-page, graphics-free cache report for any cache.

 

Make it available to members. That'll get a lot of people to sign up! icon_biggrin.gif

 

(It's gotta work for Windows and OS X, though, or you'd annoy a lot of people... icon_mad.gif )

 

icon_wigogeocaching.gif

Link to comment

quote:
Originally posted by Cheesehead Dave:

Make it available to members. That'll get a lot of people to sign up! icon_biggrin.gif


Or sell the application, with the data it needs, on a CD. Who cares if they subscribe, so long as they send money.

quote:

(It's gotta work for Windows _and_ OS X, though, or you'd annoy a lot of people... icon_mad.gif )


 

That would be the difficult part, wouldn't it...

 

Especially for us Linux users. icon_biggrin.gif

 

warm.gif

Link to comment

quote:
Originally posted by Cheesehead Dave:

Make it available to members. That'll get a lot of people to sign up! icon_biggrin.gif


Or sell the application, with the data it needs, on a CD. Who cares if they subscribe, so long as they send money.

quote:

(It's gotta work for Windows _and_ OS X, though, or you'd annoy a lot of people... icon_mad.gif )


 

That would be the difficult part, wouldn't it...

 

Especially for us Linux users. icon_biggrin.gif

 

warm.gif

Link to comment

quote:
Originally posted by Cheesehead Dave:

<>

(It's gotta work for Windows _and_ OS X, though, or you'd annoy a lot of people... icon_mad.gif )


 

OS X??? isn't that like Windoze light?

 

J/K

 

icon_wink.gif

 

====================================

As always, the above statements are just MHO.

====================================

Link to comment

quote:
Originally posted by Cheesehead Dave:

<>

(It's gotta work for Windows _and_ OS X, though, or you'd annoy a lot of people... icon_mad.gif )


 

OS X??? isn't that like Windoze light?

 

J/K

 

icon_wink.gif

 

====================================

As always, the above statements are just MHO.

====================================

Link to comment

quote:
Originally posted by Harrald:

 

OS X??? isn't that like Windoze light?

 


 

It's more like an enhanced version of NetBSD. In fact, it IS an enhanced version of NetBSD! Comes with Apache, and PHP installed. Just add MySQL and you are ready to rock. icon_razz.gif

 

mac_logo.gif

 

... Two roads diverged in a wood, and I--

I took the one less traveled by, ...

 

unclerojelio

Link to comment

quote:
Originally posted by Harrald:

 

OS X??? isn't that like Windoze light?

 


 

It's more like an enhanced version of NetBSD. In fact, it IS an enhanced version of NetBSD! Comes with Apache, and PHP installed. Just add MySQL and you are ready to rock. icon_razz.gif

 

mac_logo.gif

 

... Two roads diverged in a wood, and I--

I took the one less traveled by, ...

 

unclerojelio

Link to comment

quote:
Originally posted by Warm Fuzzies - Fuzzy:

If you'll read my two posts again, you'll see that I'm suggesting that this sort of feature is better implemented as a standalone program or applet that runs on the user's machine and performs queries to get the results. The backend still runs on the geocaching.com server, but the frontend does not. That way, the interface is faster, can contain lots more detailed data, and can give instant feedback as you scroll and zoom around the map and so on. Also, the load that such a user-interface feature would put on the server is, except for the queries, put on the user's machine where it belongs.


I can almost guarantee you that we won't be building such an application. We're not application developers - its just not our core competency. And building a non-web application seems a little backwards to me anyway. I don't want to tell Mac and Linux users that I've only developed a Windows version; nor would I want to support the same app on three different platforms.

 

quote:
...you could push all these decisions off onto other developers and let the market decide.
Ah, you're getting closer here. Remember my hint in the other topic about the .NET web service... Hmmm.... Remember, no promises. icon_wink.gif

 

-Elias

Link to comment

quote:
Originally posted by Warm Fuzzies - Fuzzy:

If you'll read my two posts again, you'll see that I'm suggesting that this sort of feature is better implemented as a standalone program or applet that runs on the user's machine and performs queries to get the results. The backend still runs on the geocaching.com server, but the frontend does not. That way, the interface is faster, can contain lots more detailed data, and can give instant feedback as you scroll and zoom around the map and so on. Also, the load that such a user-interface feature would put on the server is, except for the queries, put on the user's machine where it belongs.


I can almost guarantee you that we won't be building such an application. We're not application developers - its just not our core competency. And building a non-web application seems a little backwards to me anyway. I don't want to tell Mac and Linux users that I've only developed a Windows version; nor would I want to support the same app on three different platforms.

 

quote:
...you could push all these decisions off onto other developers and let the market decide.
Ah, you're getting closer here. Remember my hint in the other topic about the .NET web service... Hmmm.... Remember, no promises. icon_wink.gif

 

-Elias

Link to comment

quote:
Originally posted by Elias:

...What I'd like to know from the community is how they want to interact with this feature. How does one convey their route? How do we return the results in a meaningful way (discrete coordinates of caches, or are they ordered in some way based on your direction)?...


What would be the simplest, cheapest, fastest way to offer this function? Punching in the four coords of a rectangle wouldn't be my preferred way of defining a route segment, but I'd rather do that SOON than wait a year for something more "user friendly". Selecting the order in which the results are reported/displayed would be a nice, but not needed, touch. Once the waypoints are loaded into the GPSr, it will continously sort them in order of distance from present location as I proceed along the route.

 

Worldtraveler

Link to comment

quote:
Originally posted by Elias:

What I'd like to know from the community is how they want to interact with this feature. How does one convey their route? How do we return the results in a meaningful way (discrete coordinates of caches, or are they ordered in some way based on your direction)? These are the kinds of questions that I think will really help define what this feature will need to do.

 

-Elias


 

A route search would be very nice but it needs to be a graphic interface, perhaps just an enhanced rendition of the present cache map. I rarely need to automatically capture every cache along a route. Rather, I want to easily pick and choose desirable caches as I pan along a route. Perhaps clicking on a cache icon would cause a pop-up box to display key parameters, a link to the cache page, and a checkbox to download coordinates. An improved cache map would also make an area search easier.

Link to comment

... a user could simply click and drag a long narrow rectangle (or series of rectangles) on a map? (as in along an interstate route)

 

I don't know anything about how one might go about setting something like that up, or how much work would be involved, but that would seem to me to be a super easy way to get what you were looking for... from the users point of view anyway.

 

Happy caching,

Tedoca

Link to comment

Maybe this could be implemented without too much trouble? Perhaps the Search Engine can be modified to search around multiple coordinates in a single search.

 

I suspect that most GPS users have some sort of application like Garmins MapSource. It would be easy enough to create a series of waypoints along the route you plan to take (put them as frequently as you like). These waypoints can be exported as a text file and copied and pasted into a "multi-waypoint" field in the advanced search screen.

 

Behinds the scenes, caches are found for each point the same way they are now, then combined and sorted into one big list.

 

The format of the input would have to be standardized somehow. (Ideally uploading an EasyGPS .loc file...but that may require more complexity.)

 

It seems that the text export of Mapsource is in a fixed format and could be parsed out easily enough. OR perhaps you could require the user to format the text themselves and use that...something like:

 

N42 39.212 W87 57.228

N42 46.681 W87 57.228

N42 14.381 W87 51.790

N42 27.894 W87 56.733

 

You could then import the found caches into your MapSource (or whatever) and view them along your route and develope your plan of action from there.

 

Without knowing the details it seems that the pieces of this already exsit (search by coordinate and sort)so hopefully things can be tweaked a little to provide this functionality.

 

Just an idea.

Link to comment

OK, after a little thought I realized that my last idea was not optimum, the values returned would not be too accurate. So after some more analysis (and some outside math help) I came up with this:

 

Similar to my last idea you would submit a series of waypoints to search on. Each set of points would define a relatively straight section of your route. Given each segment of the route you would need to :

 

1) determine the distance between the two points (d)

2) find all caches within (d) miles of each point (or if the users specified distance is greater than d then find caches with the user specified distance)

3) for each found cache apply the following formula

 

Let a = distance from the cache to the first point

Let b = distance from the cache to the second point

 

h = sqrt[(d + a + ;)(d + a - :)(d - a + :D(-d + a + B)] / 2d

 

h will equal the distance from the cache to the closest point on the route .

 

I admit that it is a little complex, but might be fun to implement

 

The true traveler is he who goes on foot, and even then, he sits down a lot of the time.

- Colette

Link to comment

quote:
Originally posted by blahginger:

2) find all caches within (d) miles of each point (or if the users specified distance is greater than d then find caches with the user specified distance)


 

This might leave out some caches when the user's specified distance is less than d but more than d*sqrt(3)/2. You want to use sqrt(u^2+d^2/4), where u is the user's specified distance.

 

warm.gif

Link to comment

Obviously if every road in the USA went due north or south this would be a moot point, but since they don't we are led to issues.

 

and if that isnt bad enough, most roads don't even follow straignt paths from start to end... thus, the optimum solution would be to use a very rough algorithm and download an excessive number of caches, but in a stripped down format such as XML, with only basic details of the cache.

 

so my suggestion would be to do the follwoing for a multipoint path. Asking for a search radius would be somewhat ridiculous so why not get every cache in a box between the starting and ending point, with say 30 miles padding on either side. (use a few rectangles when going really long distances, creating a staircased approximation of a diagonal)

 

If all we are downloading is the x/y location of the cache (don't even list caches that arent available) and the type of cache and its capsule descriptiont his should suffice.

 

That solution isnt pretty, but it is the easiest solution for now. many of us with newer GPS's can hold hundreds, maybe thousands of points, so I see no reason not to :-)

 

the bigger issue to me once i have every cache programmed into my gps is that, ok fine, I am in nebraska and i know there is a cahe three miles away, but how do I get the details of the cache? I could call a friend with an internet connection but that seems impractical. I could mirror the geocaching site in full before i leave on my trip, but that may cause Jeremy to murder me in cold blood. What options exist for carrying hundereds of cache candidates on the road?

 

I'm beginning to feel this would be a killer premium service. as a premium user, one might be able to download a zipfile with all the caches along the way as well as XML formatted cache details that can be accessed on the road from a PDA or if space is an issue, thru a laptop. I can't imagine the entire text portion of the geocaching website is over a gigabyte, so certainly the basic info (no logs, or possibly only the latest 2 for each cache) for a thousand caches would fit in a few megs right?

 

I might be off my rocker but we ought to be able to make a solution here.

Link to comment

Warm Fuzzy,

 

you are correct. there would be some points lost. good catch.

 

Also, I am not sure what will happen when you try to compute the distance from the cache to the line segment when the cache does not have a perpendicular back to the line segment. In other words, what happens when the cache is found behind one of the segment endpoints rather than between the endpoints. (I may not be explaining this correctly.)

 

The algorithm above would only work for caches that lie "between" the two endpoints, for caches outside the endpoints we would have to use a straight point to point calculation from the cache to the closest endpoint of the line segment.

 

The true traveler is he who goes on foot, and even then, he sits down a lot of the time.

- Colette

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