Jump to content

Caches Along A Route


Jeremy

Recommended Posts

Hi,

 

What I'm looking for is the ability to run a PQ for a bookmark. What I would do is collect the caches I'm interested in along my route a bookmark and then run a PQ to get the mobipocket files and download to my PDA.

 

Any hope for this?

 

RitC

Edited by RakeInTheCache
Link to comment

Jeremy, I was considering making a bookmark list for caches along I70 through Illinois, as that seems to be a frequent question asked in the midwest forums. Should I waste the time to do so and keep it updated or is there good progress on the discussion above? Actually, I think I could make seperate bookmarks for the lower 3/4 of Illinois Interstates. Thoughts?

Link to comment

I have read all the messages in this thread, but maybe I missed it, but here goes.

 

In the original post, or near the start Jeremy was talking about two different options.... the ARC seemed like the one everyone was talking about.

 

Here is where I am lost, and I'm sure someone will tell me what I am over looking but here goes.

 

Why can't Jeremy or TPTB create a Pocket Query that works like this?

 

Instead of the "Center Point Coordinates" and "Radius" method use these four things

 

1.... Starting Point Coordinates (same as the Center Point is now)

2.... Distance to Search (similar to how the Radius is now)

3.... Bearning in Degrees

4.... Within Distance (which could be set as a maximum of 5 miles, if needed)

 

(I have since read this forum discussion again and seen this suggestion in various wordings a few times, but never a comment why it can't be done or work)

 

This would be very useful in my opinion. Instead of getting a huge list of caches that are nowhere near where I'm going, I could get all the caches within a range of 5 miles of a line that is about 50 miles. It's a bit different from creating a rectangle because this is more of a line and what is close to the line, as opposed to a big box. As a graphic example, picture the "Diver Down" flag, I am proposing the white strip instead of the whole flag with the red triangles which represents unwanted caches that aren't really 'on the route'.

 

I realize that some PQ's like this would reach the 500 cache limit, but that is the same as it is now for the circles.

 

As an example...

 

If I was leaving Detroit, heading towards Florida on I-75 (I don't live near this, I'm trying to use USA data, so I am guessing at values)

 

I would enter the coordinates of a point on I-75 near the edge of town

I would enter a distance of 100 miles

I would enter a bearing of 170 degrees (I think the highway heads just a bit east of south)

I would enter a distance of 2 miles ( I don't want to leave the highway that far)

 

This would create a rectangle that is 100 miles long and 4 miles wide (2 Miles from the line on either side)

 

All of the other PQ options could be used.

 

Since the current PQ generator must use some kind of calculation to determine what caches are inside the requested circle, it would be similar for the caches inside a rectangle.

 

:antenna: The Blue Quasar

 

P.S. I get all glazed over when you guys start talking about ARC's and such.... I am not able to learn the advanced mathematics you are referrencing, and I agree that while this is a 'technical discussion' it should still be about creating a simple method for the average user to be able to understand.

Edited by The Blue Quasar
Link to comment

Folks keep trying to explain how simple this can be, but it's really not simple in many common cases. In a world where roads run in straight lines, the distance/bearing approach would be lovely. But it falls down in the real world where trips take you around major cities or on roads that curve over a long distance. There are like but a few of the reasons the OP considered them "a poor solution".

 

A couple of folks have spent some serious time trying to find a solution that's within a reasonable budget that actually solves the problem in the general case instead of a solution that works for only some of the people some of the time.

 

Insert cliches about birds in the hand relative to birds in the bush here if you want...

Link to comment

I understand that being able to follow the route of a highway would be preferrable, which I assume is the concept of the ARC.

 

I just meant that as a temporary solution, that the 'circle PQ' could be adapted to include a 'ribbon PQ' so as to not have a box or rectangle.

 

If it was in place, we could try it and see how people like it. It might be that for the regular user it would suffice.

 

Like eveyone in here says, the power users already have made their own solutions.

 

I just think it's worth a shot, to see how it goes.

 

But if it is a lot of work for a short period of usage, or low interest, then I agree that there is no reason to create the option.

 

B) The Blue Quasar

Link to comment
I just meant that as a temporary solution, that the 'circle PQ' could be adapted to include a 'ribbon PQ' so as to not have a box or rectangle.

I agree that this small change would be very helpful, especially in reducing the number of pocket queries required to plan a trip.

 

Last September, I wrote code to implement this kind of query. As I described above in this thread, the user specified 2 endpoints and the query returned the n points closest to the line connecting them. The only change that would be required to the PQ page would be the addition of a second point to define the query. Everything else would work in exactly the same way as current PQs do. Implementation on the website would be nearly trivial.

 

I contacted Groundspeak and offered to give them the code for free. Hydee verfied that my email had been received and promised to make sure that the technical people got it.

 

I have heard nothing since. Not a single Groundspeak person has even bothered to grant me the minimal courtesy of a short "thanks but no thanks" reply.

 

As a result, I would say that the evidence I have seems to indicate that interest in solving this problem on the Groundspeak side is minimal, and that any suggestions made here are going into the bit bucket.

Link to comment

Jeremys opening post here mentions "... allowing you to do a degree range..." so this is why I've posted here, rather than create another.

 

I've read many posts after searching for multiple combinations of "pocket query queries pq". Couldn't seem to find any that also included the words latitude or longitude.

 

The Pocket Query function that many in New Zealand would find very useful is to simply be able to specify the Island (they are in the State drop down box) and a degree of longitude to specify south or north of.

 

There's been recent discussion on the New Zealand GPS Society site about the methods we use to split up the Pocket Querys. In order to create a "degree range" some of us attempt to use a radius from a southern point to capture all wanted caches south of a "cut off line" and another norther point & radius to capture all wanted caches north of that same "line". You can read the posts here http://gps.org.nz/forums/...1541 and http://gps.org.nz/forums/...12957. There are not hundreds of posts so it wont take long!

 

The conclusions are that all we're trying to do, by clumsy circle methods, is to create a longitude line to cut the Island into 2 more easily handled areas. In so doing it was found the radius is limited to 750km and the radius does not work if extending over into the western hemisphere.

 

The "degree range" or "south / north / east or west of a longitude / latitude" would be a much appreciated addition to the Pocket Query options. Many posters on the PQ subject desire simple methods and I do too. I believe this option would appeal to many. Thanks - Tony.

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

I'm planning a trip around America and am currently planning cache stops using Marwell's (great) solution using PQ->GSAK->MS St. & Trips.

 

Its working great but I end up with lots of caches that aren't near my route. I am using broad selections in my PQ's.

 

The quoted post is what I had in mind. Input a starting point and select the desired direction from the starting point.

 

I'm not sure of the table layouts or how the N/NE/E/S/SE... directions are generated. Could a direction selection work in the selections or would this require a subsequent sort of the data to work?

 

As I've set up my PQs, I've wondered if the "dedicated" machine has lots of idle time or is burdened with a neverending stream of batch requests. Could extra sorts like "by direction" be added without running the box ragged?

 

Thats my 2 cents

 

craig

Link to comment

Hey all - this is Mark, we have a family account here on GC, and my wife is the primary email address, so I'm just a forum "lurker", though I'm the technical guy in the house.

 

With Google's recent announcement of the availability of app keys to pull Google Maps data into third-party applications, along with the talk of the code that's already been developed to do "Ribbon Queries", have any of the programmer geeks here considered using Google as the source for the ribbon to plot against the database?

 

I know that programmatically possible - Maps hacks were out before the official endorsement for things like tracking sex crimes offenders in the Chicago area (I think it was Chicago), or mapping the NYC Subway stops. The question, I guess, would be can someone extract the map data to generate the ribbon to run the PQ against.

Link to comment

Jeremys opening post, almost a year ago, here included:

 

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.

 

Maybe it's not the most elegant method of determining the caches along a route but why not add it to the pocket query generator anyway? Seems like a good SIMPLE method for satisfying other query needs to me - especially compared to the very complex work arounds that other customers are developing.

 

The simple ability to search within specific longitude & latitude boundaries eludes the programmers - or maybe it's too simple to interest them.

Link to comment

A method I would like to see implemented is to be able to enter two coordinates into a PQ and then select one of two options:

 

1) The two points would be opposite corners of a rectangle and return all caches inside it (up to the limit).

 

or

 

2) The two points would form a line and return caches within a selected distance of that line.

Link to comment

I remember a few years back when I started geocache hunting, I could load up a state map online. It would have all the cache pins for caches in the state on it. I could zoom in to a area that I was in, and locate nearby caches that way. What happened to that feature? I came in real handy when we were traveling and didn't have a location to search by.

 

Bob

bornelas@charter.net

Link to comment

Why not just make the user go to USPS.com and enter cities along their route to get zip codes. The be able to do one PQ along the arc connecting the various zip codes and filtered to 1 mile or 1.5 miles or whatever from that arc? Limit the PQ to maybe 10 cities or even only 5 at at time. So I would find the zip codes of the first 5 main cities I'm passing through and enter those zip codes into my PQ and get the filtered list along that arc. Limiting it to 5 PQs per day as is currently implemented you could then get 25 cities along your route in 5 days with a filtered list.

Link to comment

I started looking through this thread to see if this solution had been mentioned but I got tired of looking. If this has been mentioned before, please excuse me.

If you create PQs to cover the entire area that you want and then create a DB in GSAK, you can then create a points filter using relevant points (in lat lon) along your route specify the distance from the line and you're done.

Link to comment
What about for major highways including a new category like  "rest stop" caches and it could be searchable by highway and direction :rolleyes: ?

I would LOVE to be able to find all the rest stop/rest area caches. Some have Rest Area in their name and others have RestArea in their name but I would bet there are many that can't be found with that sort of search. I haven't tried searching on Rest Stop or RestStop yet.

Link to comment

What I did on a recent 1 hour trip through the mountains was just followed the route by scrolling along with the maps we have already, looking for caches that were on the roads I was taking to get there, as well as not too far down side roads. Found plenty in only 5-10 minutes.

 

Of course, it rained then, so I didn't even bother... B)

Link to comment

I was just going to post a message wondering if there was any way we could support routes, or paths. My suggestion was specific for bikers (mountain, regular). Nothing quite as fun as taking your bike out, and then heading around a trail, path, route, etc and searching for geocaches at the same time. Perhaps finding all within 1000 feet of the trail.

 

I was wondering if this was a feature where people would post the trail, and list the geocaches along the trail. Just a recommendation. But the hard part would be maintaining it, and dropping the caches that are archive and adding new ones that are added.

 

However, this isn't much more work than maintaining some caches. Maybe if you have a trail owner, they take the responsibility to adding or removing caches from the list for that trail. In that case all you need is a way for geocaching.com to notify them when a cache they have in their trail list has been deactivated. For new caches along the trail, if you have the owners of the trail published, other cachers, the new cache owner, of even the trail owner could find it.

 

For instance, if I was a trail owner, I would have a weekly pocket query that pulls all geocaches within a radius large enough to get my trail. The pocket query omits waypoints already listed on my trail. I pull this weekly query into the program I use to view my track, and see if any new caches pop up along my trail. If its a larger trail, or in an area with a lot of geocaches, the pocket query may not be feasible, so I would rely more on feedback from others that take the trail. For instance, if I was taking a bike trip on a posted trail to find geocaches, and a new cache showed up on my GPS that wasn't part of the trail list, I'd let the trail owner know. Makes it more fun for everyone.

 

So with this model, you would have a new type of geocaching.com contribution - not just cache owners, but trail owners. They upload the track for their trail, a starting point and/or midpoint waypoint for finding the trail, provide name, trail distance, type (walking, biking, etc), format (out and back, or loop), and list the waypoints for that route.

 

This only leaves how to add new caches to trail, which was discussed above, and how to remove archived caches. Since I entered all the waypoints into my trail list when populating the new trail form, much the way you fill out a new cache form today, Geocaching.com has a new record for my trail, an association (list) to all the geocaches along my trail. When I added the waypoint to my trail list, geocaching.com updated a "trail (y/n)" flag for that waypoint to yes. This does 2 things: 1. when someone archives a waypoint the system sees the trail association for, it automatically removes it from that list (or leaves it there and marks it inactive), and perhaps emails the trail owner; 2. If I'm geocaching in a new area and see the indicator that this cache is part of a trail, I'd may want to pull up trail so I can get a string of finds.

 

It would be neat to see a user stat with 1872 finds, 120 hides, and 4 trails. I think that would even open up geocaching a lot more to mountain bikers and hikers.

 

While there would be administrative part in this, web updates, new sets of rules / guidelines for trails (don't cross private property, hazards, when searching for the cache get completely OFF the trail, etc), so much of geocaching is about people take pride in the contributions and take ownership so I think the trail owner / poster would take a lot of the responsibility for doing what we can't with a program today.

 

This doesn't solve the problem of "I'm driving from a to b this weekend and want to find all the waypoints along my route", but does provide a way for geocachers to share trails, or routes they really enjoy.

 

Thanks,

David

Link to comment
I was wondering if this was a feature where people would post the trail, and list the geocaches along the trail. Just a recommendation. But the hard part would be maintaining it, and dropping the caches that are archive and adding new ones that are added.

Bookmark list work great for this. I've seen several bookmark list of all caches along a trail or route.

Link to comment

That sounds like it may work, then all you need is a way to upload the track (path) and a way to search on it. How do I find shared lists? I looked but couldn't find a way to search on them. If I have a bookmark list and one of the caches is archived, is it automatically updated in my list?

 

Thanks,

David

Link to comment

Every so often, we should refresh the current status of this thread, which tends to go off-track.

 

As I see it, the purpose of this thread is to discuss possible ways that the geocaching.com site could allow for searches along routes, not a discussion of how to do those searches using circular pocket queries and external software.

 

Here's the essence of what we know so far:

  • Licensing route-planning software for the website would be prohibitively expensive and a support nightmare.
  • "Directional" searches would be helpful in reducing the number of PQs needed to plan caches along a route.
  • Automated algorithms to search for caches near a route exist.

Here are my opinions about what should be done:

  • "Linear" pocket queries returning the N points nearest to the line connecting two points can be implemented with very little change to the PQ page and logic.
  • Route queries can be performed from uploaded GPX files. Each query would return the N points closest to the first route found in the file. Alternatively, multiple routes could be specified in the file and each one would count as a separate query, returning the N points closest to it.

These queries are more expensive in terms of database CPU usage than are existing PQs; in the case of the linear query, the difference is not very large, but for a route query, the distance calculations scale like the number of segments in the route. But this problem can be ameliorated by using a route simplification algorithm like the one in GPSBabel.

 

The ability to query caches along a route is one of the most commonly-requested features I've seen. I think this capability would be an excellent premium-member feature.

 

As always, I offer TPTB my help in implementing it.

Link to comment

One other option that's been brought up, that may offer a medium between linear projection and generating off a route is running queries within a boundary set (i.e, within a box set within N, S, E, W coordinates). This would give more control than linear projection but be less disk and CPU intensives than tracking along an uploaded GPX route.

Link to comment
One other option that's been brought up, that may offer a medium between linear projection and generating off a route is running queries within a boundary set (i.e, within a box set within N, S, E, W coordinates).  This would give more control than linear projection but be less disk and CPU intensives than tracking along an uploaded GPX route.

You are right that such a "rectangular" query would be very useful; I disagree that it provides more control than a linear query, but it requires no distance calculations, so it is less CPU-intensive than even existing circular queries.

 

However, the rectangular query has one problem that makes it unattractive to TPTB: there is no easy way to limit the number of caches returned in the query. For a circular query, you just return caches in order of distance from the center until you reach the limit; for a linear or route query, you can do the same using the distance from the line or route. But for rectangular queries, there is no similar distance to use.

 

One way to deal with the issue is to make a rectangular query the same as a circular query with limits on the latitude and longitude. The query would start from the center of the rectangle and keep returning caches in order of distance from that point, but exclude caches that fall outside the rectangle. This concept is very similar to a circular query with a radius limit. The primary disadvantages of this solution are that there is no easy way for the recipient to tell if the query actually got all the way to the corners of the rectangle or not, and the query is no longer more efficient than a circular query.

 

The other alternative query type that has been proposed is a "directional" query, where you give a point, a maximum radius, and a direction. The query returns caches in a wedge-shaped region starting from the point, centered on the direction given. The width of the wedge is determined by the maximum number of caches and the maximum distance.

 

While any enhancement in control over PQs would be welcome, I am still convinced that the simplest and most useful version is the linear query, followed by a route query. But that's only my opinion!

 

P.S. Would anybody find it helpful if I drew pictures of the various query types? I can see them in my head, but I am a physicist, so I see a lot of things in my head. :lol:

Edited by fizzymagic
Link to comment
One way to deal with the issue is to make a rectangular query the same as a circular query with limits on the latitude and longitude. The query would start from the center of the rectangle and keep returning caches in order of distance from that point, but exclude caches that fall outside the rectangle. This concept is very similar to a circular query with a radius limit. The primary disadvantages of this solution are that there is no easy way for the recipient to tell if the query actually got all the way to the corners of the rectangle or not, and the query is no longer more efficient than a circular query

I would expect to use the same method to tell I got everything in a circular query. That is if the rectangular query returns 500 geocaches, I probably didn't get them all.

Link to comment

Fizzymagic, isn't the rectangular case only mathematically "easy" if the rectangle has one edge that's parallel to the equator? Even then, it's only easy if we assume the world is flat (that makes the math _sooo_ much easier :-) and allow for the straight forward four comparison and not deal with the distortion of the lats, right? (I know Fizzymagic knows this, but for the benefit of those not owning pocket-protectors, a "rectangle" described by the two corners of (N76,W-87/N75,W-87) isn't really a rectangle.) I'm considering an optimization to GPSBabel's polygon filter that could take advantage of all this...

 

I doubt the limit is much of a problem in real life. If you asked for "up to 300" in a query and got exactly 300 back in the preview, it's a pretty safe bet that there were more than 300. I don't see mandating determinism in which ones fell on the floor as much of a problem. Do you?

Link to comment
I don't see mandating determinism in which ones fell on the floor as much of a problem. Do you?

No, I don't. In fact, I see mandated determinism as a requirement.

 

And you (and Allen above you) are both right: seeing the maximum number of caches returned is a pretty clear sign that the rectangle was not filled. So that's not a big issue.

 

And yes, I was assuming that the rectangular query was done so that the rectangle was aligned N-S and E-W. That was my interpretation of the proposal. Doing a non-aligned rectangular query gets messy; a linear query is a much better solution to that problem.

 

I am presently working on the math for a linear query that follows a rhumb line instead of a great circle. In many situations, such as trying to query along an interstate that goes E-W, a rhumb line (which appears straight on a Mercator projections) is really what people want.

Link to comment
You are right that such a "rectangular" query would be very useful; I disagree that it provides more control than a linear query, but it requires no distance calculations, so it is less CPU-intensive than even existing circular queries.

Sorry, I misunderstood the linear query you were describing. I thought it was describing the wedge option. Now, what I understand you're saying is that it would be a fixed distance from a line between two endpoints. In effect, it would define a rectangle.

 

It could work better than the rectangle proposal, because then you wouldn't be limited to a rectangle fixed along the equator (which is what I had in mind - You would define two longitude and two latitude bounds, and the corners of the rectangle would be defined by the four possible combinations of these bounds). It would also make the issue with approached limits easier to deal with.

 

Bottom line, though, I would love something that gives a little more control over the regions of a PQ. I've had so many times where I've planned a trip and ended up spending days trying to define queries along the route so I could actually see all of the caches I would encounter in a minimal amount of queries. It's worst in very cache dense areas. I have to define points along the highway and such small radii to keep it below 500 caches, which means I have to run more PQs, and end up filtering 90% of them out because I really only wanted the stretch of highway within the circle, not the ones further out.

Link to comment

Beside the "caches along a route" it could be a first step to have a "caches in one direction" option. If it would be possible to say "list all caches from a certain point in the direction starting at xxx degrees and ending at yyy degrees" this would help (me). So everything north of me would be from 355 to 5 degrees (not 5 to 355 degrees :laughing: ).

Link to comment

Here is my interpretation of the various possible query types.

 

Notice that for each query type, there is one degree of freedom that allows the query to grow until the limit in number of caches is reached. I've represented this by fading the color in the direction that the query grows. I believe this property is a requirement for any new query type.

 

Linear. Query returns N points closest to a line connecting two waypoints:

16e2b59a-4dfb-4a1f-a9bc-820178e3ae50.jpg

 

Rectangular: Upper-left and lower-right corner points are defined and query fills in the rectangle from the center until N caches have been returned:

e1b4d737-808a-40c7-a6f5-67b41bf2add4.jpg

 

Wedge-Radial: A point and an angular range is specified and the query returns the nearest N caches to the point within the angular range.

717376f6-1c1d-4938-a073-4479ef24d7dc.jpg

 

Wedge-Angular: A point, central direction, and maximum radius are specified. The angle of the wedge is increased until N caches are returned.

8a777869-c1ae-46df-9378-dab4169943b7.jpg

 

Route: A full-blown route query strings together several linear queries and returns the N caches closest to the route:

da8efb8f-b451-4c6a-addd-9565a417a533.jpg

 

I hope this helps clarify the ideas we are discussing here.

Edited by fizzymagic
Link to comment

I too would like to be able to fine-tune PQ searches along a route.

 

Whatever became of the notion that TPTB could use GPSBabel on the server to do the "heavy lifting"? Then all they would need is a PQ specification page that lets us input a bunch of coordinates and a checkbox to indicate whether the list specifies an arc or a polygon.

 

I appreciate the update on the ideas that have been presented, but what we need is to hear from Jeremy what the hold-up is.

Link to comment

I still vote for an attribute, something like "While passing through this area on a major thuroughfare, and being unfamiliar with the local roads, you can easily expect to leave the highway, attain this cache, and return to the freeway and not add more than 30 minutes onto your trip."

 

That would be great for the ammo boxes just off the freeway between Las Vegas and SoCal. Hwy 95 in NV, 395 in CA - most any rural road.

 

edit: spelling

Edited by Moose Mob
Link to comment
Whatever became of the notion that TPTB could use GPSBabel on the server to do the "heavy lifting"? Then all they would need is a PQ specification page that lets us input a bunch of coordinates and a checkbox to indicate whether the list specifies an arc or a polygon.

The problem is that GPSBabel's arc and polygon filters don't meet the requirement for a query that can be gracefully limited to a specified number of caches. The arc filter returns all caches within a specified distance of the arc, and the polygon filter returns all caches inside the polygon.

 

We are trying to work with TPTB to come up with query types that won't break their model of returning a maximum number of caches. I'm sure Robert could fix GPSBabel to work this way, but right now it doesn't do it.

 

OTOH, we haven't heard anything on this topic from TPTB for a very long time, so there is no way to know if the suggestions are being received, or even if they are useful at all.

Link to comment

I haven't read the entire thread, so forgive me if I'm off base...

 

If we are trying to get waypoints along a trail... TrailRegistry can be made do this type of thing pretty easily, it currently will find all waypoints within 0.2 miles of a trail, and includes them in the trail guide.

 

tweaking the algorithm so the user can specify distance from trail/road, etc is pretty easy.

 

http://www.trailregistry.com/trailregistry...ineraryId=79795

 

Unfortunately for long highways, the algorithm is brute-force, so it might take a while. But it probably wouldn't be that bad.

 

If geocaching wanted to do some sort of data sharing, I could provide this feature for them. I do think our two websites could seriously benifit from each other...

 

-Geoff

Link to comment
We are trying to work with TPTB to come up with query types that won't break their model of returning a maximum number of caches. I'm sure Robert could fix GPSBabel to work this way, but right now it doesn't do it.

 

GPSBabel doesn't do this because nobody involved in making it happen stated it as a 'requirement' . I'm not sure that shoudl be GPSBabel's problem, but I'm not opposed to the idea. Sorting by distance from the route adds to the computational cost, (and it's more than the sort itself becuase of our internal data organization...) but it's certainly not rocket science. Limiting the returned points is trivial.

 

TBTB know my email address if they want changes.

Link to comment

.....And I thought that a corridor query was a novel idea...little did I know that the debate had been under way for well over a year. I have only one remaining request for those who have the savvy to make this dream a reality.... "K.I.S.S" please! And for my two cents....I think that this would be a great premium member feature as well.

Link to comment

I just find it disappointing that at least outwardly, NOTHING has been done in the 415 days, 9 hours and 1 minute since the first post of THIS thread...

 

If something HAS been done to make this easier (other than allowing pocket queries from bookmark lists), could we at least get an idea?

Link to comment

My two cents (if anyone's listening):

 

Let's get this linear search working. It's easy and useful.

 

If the world doesn't end, add the uploaded gpx route search.

This is clean and powerful if not simple to do.

 

From there if people use it a lot you could think about ways

to share routes.

Link to comment
I just find it disappointing that at least outwardly, NOTHING has been done in the 415 days, 9 hours and 1 minute since the first post of THIS thread...

 

If something HAS been done to make this easier (other than allowing pocket queries from bookmark lists), could we at least get an idea?

I'm disappointed also, has anyone suggested this idea?

Instead of a circle with a radius, define a rectangle with 4 coordinates

marking the four corners?

 

e.g. 38.20.000 & 38.50.000 mark the latitude range and

121.05.000 & 121.40.000 mark the longitude range.

 

All caches in that range would be included subject to the other

filters in the make a pocket query.

 

Instead of having circles that overlap, and extend to who knows where on

a map that is rather vague unless a person uses a compass to scribe

a circle, the box would be easy to see on maps.

 

A series of long skinny boxes could, more or less pick up the caches along a

moderately straight road. :mmraspberry:

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