Search Along A Route

December 14, 2003

:lol:

I would like to be able to search for caches along a route. The Marriott family of hotels allows you to find their hotels along your route. Could we add a feature to the web site that allows us to search for all caches within 5 miles of a major route from one zip code to another?

I am planning a drive to visit the folks and want to geo-cache along the way. It would be simpler than having to look up then punch in zip codes along the way. What a great way to get Travel bugs moving too.

Pandy

2k · December 14, 2003

It's been asked for before...

and others will may give you some ways to acheive this with a bit of work and other software...

but I agree it would be nice to such a search, probably for PQs.

I'd be happy with something as "simple" as "all caches meeting [normal selection criteria available] with x miles of a straight line from point y to point z."

5.3k · December 14, 2003

This question is frequently asked: http://members.aol.com/_ht_a/marklent60544...gcfaq.htm#route

But there is another approach that isn't well covered in the FAQ. See: http://forums.Groundspeak.com/GC/index.php...345&hl=gpsbabel

4.7k · December 16, 2003

yes, i want this too. can we get this option in the PQs? please? pleasepleaseplease?

December 18, 2003

I don't know about you but I would pay extra for this option.

1.6k · December 18, 2003

Here Here!

Been brought up before, but its worth doing if its not some ridiculous tech problem.

Would be cool to give two caches by their way points and get 20-50 caches 20 miles on either side of a line that connects them. (Ok, so my post sounds like a tornado warning, sorry :mad: )

5.3k · December 19, 2003

Would be cool to give two caches by their way points and get 20-50 caches 20 miles on either side of a line that connects them.

I don't know why this keeps coming up with there are multiple ways to do this already.

Step 1: Build a pocket query (one or more) containing the area to cover.

Step 2: Get the coords for the two caches. Either pick them out by hand or get a simple "download to .loc" to spin them to a file.

Step 3: Convert those endpoints to a format the arc filter can use.

gpsbabel -i geo -f geocaching.loc -o arc -F points

(Note that steps 2 and 3 can be replaced by creating a street route in your favorite s/w and doing a similar conversion.)

Step 4: Get the caches within 20 miles of that line:

gpsbabel -i gpx -f MiddleTN -x arc,file=points,distance=20 -o gpx -F betwitx

File 'betwixt' now contains only caches within 20 miles of the line (it can be a curve) represented by the points in 'points'. You can then feed that file to your favorite GPX reader or replace 'gpx' with "mapsend' or ''mapsource" or any of the zillion other formats.

I've even added additional help in the aforementioned thread for Streets & Trips users about a new tool to help them do this with .est files.

December 19, 2003

I don't know why this keeps coming up with there are multiple ways to do this already.

Because for the general case it is not so simple.

Step 1: Build a pocket query (one or more) containing the area to cover.

This is the hard part. Let us say I am travelling from Chicago to Atlanta. I plan to take a couple of days to drive this and so have time for en-route geocaching. Just building the pocket queries of the regions is difficult. There would many required especially since it is often hard to figure out where the overlaps between the queries occur. It would be much nicer to outline a path and just ask for caches within 'X' miles of the straightline distance between the points along the path. Example, my path is from Chicago to Indianapolis to Louisville to Nashville to Chattanooga to Atlanta. Everything within 15 miles of this route would be nice.

I am not sure how hard it would be to program the above query however it should be feasible.

December 20, 2003

I agree. This is not an EASY fix. Looks like I need to be a programer to do this.

20.7k · December 22, 2003

I wish there was a simple way to get thiws info from the site.

Until there is, I use this procedure:

Obtain PQs covering the entire trip. This can be a pain and take days of tweaking.
Use GPSBabel to convert the gpx files points to a format that MS S&T can use.
Open the files in MS S&T and choose the points (manually) to be included in your route. Optimize the route.
Print out a copy of the route.
Upload the gpx files to your palm using GPX Spinner and Plucker.

You now have a printout of your route including each cache you wish to visit. You also have all of the caches (and more) in your palm for viewing in the field.

The only thing left to do is load the points to your gps. Depending on the length of your journey (or more precisely the number of caches you wish to visit, this may be easy or cumbersome.

I typically use Easy GPS to pare down the files by lat/long limits and upload the individual files to my GPSr.

Alternatively, you could identify the individual caches on your list and upload these.

Laptop users could certainly take their laptop on the trip (most do anyway) and upload the different gpx files on the fly. This is the best option as it allows you to load detailed maps for your entire trip also.

My way certainly isn't simple, but it gets the job done.

3.8k · December 22, 2003

This can't be too difficult to do. Several online mapping programs can give all the hotels along a route.

Off course I am not a programmer so I am just talking out of my donkey.

Edited December 22, 2003 by webscouter495

2.1k · December 23, 2003

This and many other features requested are not technically difficult; as has been rightly pointed out, many other websites have highly similar features. The problem is that Jeremy has only two hands (and a few other people with 2 hands each) and refuses outside volunteer work on developing functions for this website.

Because of that, there are functions (such as the recent TB codebase update) that get accomplished first while the users are left to wait for functions that they are really in the search for (virt section, directional filtering, route caching).

Unfortunately without better access to the data than the PQ files, it is an uphill struggle to program anything by a third-party that would accomplish what is being asked.

9.4k · December 23, 2003

This and many other features requested are not technically difficult; as has been rightly pointed out (etc)

When you write this stuff does it make it true?

Technically it is either difficult or expensive to do. Yes, you could do one or two but when we write new features on the web site we want to make sure they are built to last - and built to scale.

It's a great idea and we've been researching ways to accomplish this in a realistic amount of time.

December 23, 2003

When you write this stuff does it make it true?

Technically it is either difficult or expensive to do. Yes, you could do one or two but when we write new features on the web site we want to make sure they are built to last - and built to scale.

It's a great idea and we've been researching ways to accomplish this in a realistic amount of time.

OMG!

No but the facts make it true. It is a matter of adding it to the where clause of the query. The person has to only define the upper left and lower right of the rectangle they are interested in.

Let's say they want to drive up I83 north of the Baltimore beltway to the PA line. In rough terms the upper left area is N39.7 and W76.68 the lower right is N39.42 and W76.6. That is rough and you may need to change the format of the coords. But for this example it is close enough.

Then the where clause looks something like:

where ((CacheLat <= 39.7) and (CacheLat >= 39.42)) and ((CacheLong <= 76.68) and (CacheLong >= 76.6)) add in a check for north, south, east and west. I did not feel like typing all of that out. Is this what most people are looking for?

Add the input boxes to enter the coords and it is just like any other part of the selections that can be made to filter a PQ. It scales like any other of those options. Again just index the fields and it is like any other part of the where clause that is already part of the query.

I know this is rough but I spent about three minutes working on it and I am about 3 Jack and Cokes into my evening. I have run this type of query against the database of caches I keep and it works fine. It would seem that a rectangle is much more useful for some people than a circle.

How hard is that?

December 23, 2003

Because of that, there are functions (such as the recent TB codebase update) that get accomplished first while the users are left to wait for functions that they are really in the search for (virt section, directional filtering, route caching).

Or adding frog smilies.

2k · December 23, 2003

When you write this stuff does it make it true?

Technically it is either difficult or expensive to do. Yes, you could do one or two but when we write new features on the web site we want to make sure they are built to last - and built to scale.

It's a great idea and we've been researching ways to accomplish this in a realistic amount of time.

OMG!

No but the facts make it true. It is a matter of adding it to the where clause of the query. The person has to only define the upper left and lower right of the rectangle they are interested in.

How hard is that?

Clearly returning a rectangle of points rather than a circle isn't difficult.

However, the requests people have for this function tend to be more complicated than that. Normally, it's something like "caches x miles from a route from point y to point z".

Now sometimes that would be a rectangle, but more likely it's a bit more complicated.

So I'm willing to bide my time while Jeremy gives this some more thought.

(And if he wants to spend a little time with his frogs, I think he's more than earned that "privilege". )

December 23, 2003

Clearly returning a rectangle of points rather than a circle isn't difficult.

However, the requests people have for this function tend to be more complicated than that. Normally, it's something like "caches x miles from a route from point y to point z".

That is all true.

But this has been talked about for months, maybe over a year. When it first came up people where asking for a simple rectangle. That did not happen.

So if you are going to ask for something you are not going to get anyway you might as well ask for the sky.

I may be wrong on this but I think your example is on the extreme side. How many people would be happy with having the chance to get a rectangle and how many people would not be happy until they can do the type of example you give?

2.1k · December 23, 2003

No, Grizzly, you're more than right, but even something more sophisticated than a rectangular search could be accomplished.

It may be that Jeremy et al. is unable to come up with a solution, but that does not mean a technically simple and feasible solution is not available.

Someone gave an example of the Marriott website and it is very capable at what it does (seems to be a city on route lookup). It would seem that you could do something similar to the AAA inlay maps on their regional maps where the biggest highways are turned into a direct-path network of cities and distances. If two cities on a route were 100 miles apart, then three dots (one at each city and the midpoint) could be used to cover the route with the same circular search that happens now (each circle being big enough to cover a third of the difference (i.e. three contiguous circles of radius 33 miles). If you limit the maximum size of the circle, and add a new circle when need be to maintain that radius, you could cover most distances between any two major cities with a few circles. Too many queries for a long route? Tell the person to check their mail the next morning and run it overnight when nobody's hitting the DB....most people would just be happy enough to have the search in the first place.

This is all off of the top of my head in about 10 minutes. I'm sure hammering out the details of usage would take longer (and I do not doubt that you are working, J) but this is one reason why open source is better in the long run. Tons of free labor working on a billion tree branches at once instead of linear production.

Obviously other companies have developed quick and large-scale solutions to this problem already (with datasets bigger than 78,000 data points). Simply because you can not come up with the answer does not mean that I am wrong in stating that a simple, inexpensive solution is managable.

1.7k · December 23, 2003

No, Grizzly, you're more than right, but even something more sophisticated than a rectangular search could be accomplished.

It may be that Jeremy et al. is unable to come up with a solution, but that does not mean a technically simple and feasible solution is not available.

Y'know, speaking as the guy who wrote the route-search code in GPSBabel, it is that hard and it is that computationally intensive.

But that's not why I'm following up. I'm following up because I want to know in what bizarro world you think comments like yours above will have a positive influence on the guy who writes the code.

2.1k · December 23, 2003

I will take a closer look at your code in Babel, but I think you made it harder than you needed to.

I realize that this website has a real "put up or shut up" mentality from most of the people here, so educated opinions are usually ignored or belittled but just looking at the way you did it, I'd suggest there's probably an SVG method for calculating the area of a path and there are methods for getting a series of overlapping rectangles that cover a flattened path. These sorts of problems (quickly specifying a fill area for a path variable) have been solved for ages in computer graphics applications. My guess is something like Gimp (open source graphics program) has a function....quick web search brings up the Gimp PDB function gimp-path-get-point-at-dist....that could be used for our purpose. Again, hotel chains, mapquest, and a dozen other websites can give closest to path answers in realtime web pages.

Now, as to why my approach will give a positive effect...maybe it won't. I tried positive effect once. My initial point was not to motivate Jeremy; it was simply to have the initial poster give up on asking for this new function. In previous posts I have tried cajoling and enticing Jeremy with valid reasons why these would be good functions to add the the website. Consistently, the answer has been 'stuff it' in one form or another. I only hope to point out to others that they will be told 'stuff it' (if not simply ignored and left to people like to alert them to the lack of current planning on these things) and if I can point out the folly in putting it on the back burner or not allowing others to engage in creating these tools that the people would like to use, then I will and do occassionally do so.

I gave up on trying to motivate Jeremy et al. in a postive manner, because postive/negative it goes mainly ignored as they have made it very clear that they have a "to do" list secreted away and they will reveal end results of the work on that in a linear and not-so-obvious manner (aka the need for a What's New/In Progress page that's *also* been asked for time and again). Any deviation from the "to do" list (with the exception of things breaking ala the forums or trivial changes) will not occur no matter how many people request a specific feature.

1.7k · December 23, 2003

These sorts of problems (quickly specifying a fill area for a path variable) have been solved for ages in computer graphics applications. My guess is something like Gimp (open source graphics program) has a function....quick web search brings up the Gimp PDB function gimp-path-get-point-at-dist....that could be used for our purpose.

You seem to have forgotten the tiny little fact that we don't live on a computer screen; we live on an oblate spheroid (suitably approximated as a sphere.) All the Computer Graphics solutions in the world won't help you when the Pythagorean Theorem, the constant sum of the angles in a triangle, and the concept of "similarity" all go out the window.

Besides, how do you think all your CG people do it? Do you think that just calling a function that someone else has written for you magically removes the computation time for that function from the equation? All those other sites you're talking about have massive computers doing those calculations, and they can afford it because some huge percentage of those calculations are subsidized by people staying in that hotel, or going to that Six Flags, or whatever. When doing that kind of calculations gives geocaching.com some nonzero chance of making hundreds of dollars in exchange, maybe we'll see them buy the kind of hardware it'd take to run thousands of such queries a day.

2.1k · December 23, 2003

This is quickly getting off-topic, but I will point out that when you are considering just a few dozen miles of road at a time, the difference between 20 miles from the highway on a flatmap and 20 miles from the highway on a great circle is so small as to be meaningless to the average geocacher. They just want to know if there's a travel bug within a few miles of a highway off-ramp, not if your being anal about exactly 20 miles from the route. If you asked for 20 miles and got 19.667 miles because you didn't take the curvature of the planet into account, nobody would care or you could just bump up the distance (ask for 20...use 20.5 to be safe for great circle estimation).

This would probably reduce your calculations a bit and still provide nearly the same amount of service as exactly calculating great circle distances.

The CG formulae that could be used are all optimized over time (which was my point) so that rather than redesigning the wheel (or its flat representation) we could use a system already well established and optimized for minimal calculations. Photoshop doesn't bring my computer to a screeching halt if I ask it to fill in a path with my selected paintbrush.

Finally, I'm well aware of how to slam a DB server with queries and currently have a DB server going fully online with over 200,000 datapoints that we're expecting some fairly regular use in the scientific community. As I said earlier, there are many things, including caching of major route lists (nobody asks to get off of I-95 between DC and Richmond regularly for example) to reduce queries to only the beginning and the end of the route and the rest is a fixed network of known rectangles updated nightly. It doesn't take much computing time to run something like this if you send the request out to a number of processors or even a single processor on a number of threads.

I don't feel the need to argue this further. It's clear that as with any programming there are potential problems with determining distance from a route. My point was only that the answer exists that is computationally feasible even for GC.com (which is not running on a Tandy in Jeremy's basement dial-up) but since it does not seem to be the main focus of GS, even though its number has come up many times, they will never figure out how to do it, technically simple or not. They clearly get things done when they sit down and work on them. The fact that this is not done suggests they have not seriously worked on it.

1.7k · December 23, 2003

Photoshop doesn't bring my computer to a screeching halt if I ask it to fill in a path with my selected paintbrush.

Get back to me when you're doing that thousands of times a day on multi-megapixel images.

I don't feel the need to argue this further.

The last refuge of a scoundrel.

The fact that this is not done suggests they have not seriously worked on it.

Or that, as Jeremy himself told me, they have looked at it and consider that kind of thing most suited to third-party software running on someone else's computer.

That's not to say that I wouldn't like to see a more efficient way to get the raw data. But crap like you're spewing doesn't help that day get here any faster.

Edited December 23, 2003 by parkrrrr

December 23, 2003

Or that, as Jeremy himself told me, they have looked at it and consider that kind of thing most suited to third-party software running on someone else's computer.

That's not to say that I wouldn't like to see a more efficient way to get the raw data. But crap like you're spewing doesn't help that day get here any faster.

Typical.

It is not something they want or can do, think it is best for someone else to do. But then they provide no efficient way for people to get the data to do it.

Sounds like double speak for, "NO, SCREW YOU!" to me.

Spewing crap or not is not going to make the day get here any faster or slower. It is not going to happen.

1.7k · December 23, 2003

Thanks for your support, GrizzlyJohn. Those of us who are working diligently to make it happen really appreciate the fact that the community is so behind us on this.

2.1k · December 23, 2003

I don't feel the need to argue this further.

The last refuge of a scoundrel.

The fact that this is not done suggests they have not seriously worked on it.

Or that, as Jeremy himself told me, they have looked at it and consider that kind of thing most suited to third-party software running on someone else's computer.

That's not to say that I wouldn't like to see a more efficient way to get the raw data. But crap like you're spewing doesn't help that day get here any faster.

Let me clarify...I do not feel the need to argue it further *here*. If you would like to continue off of the forums, feel free to e-mail me through my GC.com account. This discussion is barely about route searching and more about "oh yeah, says you".

In the very least, I have provided a number of ideas for how to accomplish the task while you have simply pointed out a few trivialities to be hammered out and no actual evidence that anything I've said would not work.

The answer before from GC.com has never been "do it yourself, third-party style". If that is the answer he's told you specifically, it's nice that he's never been candid with any of us at all on this. If this were to be the case, then there's no reason the computation *needs* to be done server-side. A java applet could be created and the bounding box method for the path could send all of the geocaches to the persons computer to determine their proximity to the path cutting diagonally (very similar to GrizzlyJohn's suggestion) and only those within the filter distance would be output. Now, all GC.com would have to do is setup the appropriate query to send all caches in the bounding box to the applet on the person's computer and the applet would take care of the calculations locally.

There isn't more than an ounce of crap in my posts here on this subject. Just because you don't like to hear that it's possible and that you went overboard in your calculations with great circles and everything instead of finding a more efficient solution doesn't make what I say wrong, garbage, or anything else. I applaud you for having developed one answer for people to use, albeit fairly bodgy, but that doesn't mean someone else can't come up with a different or better answer, nor that my brainstormed ideas are necessarily crap. Please in the future, refer to specifically what is junk and realize that things like doing flat-map estimation instead of great circles was not refuted by you....only comments like "i don't feel the need to argue this further".

If you still feel that something I've said is garbage, feel free to point it out in an e-mail. If you have meaningful ways of developing some of these ideas into an efficient route-searcher, feel free to post it here.

1.7k · December 23, 2003

There isn't more than an ounce of crap in my posts here on this subject.

Your posts on the subject perhaps not. But your speculation as to the motivations and skills of the site admins - which is the crap I'm referring to - is not helping us in our quest for new pocket query features.

The pocket query page is, by the way, either the next or the second-next thing on Jeremy's plate. How do I know this? Because he said so, in these forums, scant days ago. Look it up.

I'll never feel bad about doing it right as opposed to doing it the quick-and-dirty way. Feel free to lie to yourself and think my disgust with this thread is about my inability to throw out minor terms in the computations; I'm done with this crap.

2.1k · December 23, 2003

I'm done with this crap.

The last refuge of a scoundrel.

Happy Holidays, one and all!

December 23, 2003

Thanks for your support, GrizzlyJohn. Those of us who are working diligently to make it happen really appreciate the fact that the community is so behind us on this.

You are more than welcome.

20.7k · December 23, 2003

ju66l3r and parkrrr bring up two important points which show how difficult this search can be.

First, a simple rectangle search would not work for any trips of any real distance. Unfortunately, the interstates tend not to go from point A to point B in a straight line. Therefore, either the rectangle would have to be so wide to be of little use or multiple searches would need to be made. This is the exact problem we now have.

Second, no one really wants all the caches within x miles of the interstate. Cachers crave all of the caches within x miles of interstate exits. I'm no programmer, but this sounds like it would get very complicated to program.

The bottom line to all this, in my opinion, is this:

Many cachers wish there was an easy way to search for this info.
Jeremy is aware of this desire.

The rest of the thread is pointless argument.

9.4k · December 23, 2003

Cachers crave all of the caches within x miles of interstate exits.

Ooh. Good point and much easier to do. Now how to find a list of all the interstate exits?

9.4k · December 23, 2003

Found one company that sells this kind of data. I sent them an email to find out the licensing fees.

9.1k · December 23, 2003

Ability to search around specified interstate exits seems useful!

Out of curiousity, I looked through my caches and determined that 15 of them are within three miles of an interstate exit. They have an average rating of 3/2, including three caches at difficulty 4 or 4.5, and four caches at terrain 3 or higher. If this will be the search logic, I will have great fun trying to place challenging caches as close as possible to interstate exits.

For the time being, I'm quite happy with using the rectangle and circle filters in Watcher. Last night I loaded my GPS and PDA with caches for my Christmas travels. It took three PQ's, merged together, then filtering to three rectangles plus a circle, but I have exactly the caches I need for my trip out of state.

1.7k · December 23, 2003

Found one company that sells this kind of data. I sent them an email to find out the licensing fees.

There's a Federal agency, the Bureau of Transportation Statistics, who makes available what they call the NTAD, or National Transportation Atlas Database. It contains all of the Interstates and US highways and many major state roads. In fact, if I compare it to INDOT's official highway map, it's pretty much identical. The NTAD is freely usable, in a usable format (ArcView Shapefiles), and updated regularly. I have a copy here somewhere.

I've never quite figured out how to extract exit information from it, but in case someone else wants to have a go at it, I thought I'd point out its existence. The exits are all in there as nodes, it's just figuring out which nodes are exits that has thus far eluded me.

However, no list of Interstate exits will help me figure out which caches are within 10 miles of US 30 between Fort Wayne and Chicago. I think both things are necessary.

[Edit: I previously said "public domain" but that's not the case.]

Edited December 23, 2003 by parkrrrr

1.2k · December 23, 2003

Found one company that sells this kind of data. I sent them an email to find out the licensing fees.

There's a Federal agency, the Bureau of Transportation Statistics, who makes available what they call the NTAD, or National Transportation Atlas Database. It contains all of the Interstates and US highways and many major state roads. In fact, if I compare it to INDOT's official highway map, it's pretty much identical. The NTAD is freely usable, in a usable format (ArcView Shapefiles), and updated regularly. I have a copy here somewhere.

I've never quite figured out how to extract exit information from it, but in case someone else wants to have a go at it, I thought I'd point out its existence. The exits are all in there as nodes, it's just figuring out which nodes are exits that has thus far eluded me.

However, no list of Interstate exits will help me figure out which caches are within 10 miles of US 30 between Fort Wayne and Chicago. I think both things are necessary.

[Edit: I previously said "public domain" but that's not the case.]

What would be the datum of an exit, for these purposes?

Another problem: Many exits cover an area of several acres, and some of them do not have exit or reentry possibilities in one of the two directions.

For interstates and other 'dual carriage ways' with exits, searching by exit is an excellent idea, because it would *eliminate* the caches you can't get to otherwise, along the route from your query. I think this is a feature that should be added separately from a feature to searching along routes.

2.1k · December 23, 2003

In terms of usability, searching interstate exits doesn't matter if I want to head to SW New Hampshire up MA RT-2. If this were a path search instead, it would be up to me to determine if a reasonable exit was in range of a cache that looked enticing and the search would still be usable on *any* route as opposed to only federal highways. Maybe exit searching would be just one aspect of the route search filtering (in other words, filter on proximity to path...and then only show me those in range of an interstate exit). That way if someone is not looking to hit the superhighways, someone can still find the tool extremely useful.

EDIT: Nods to Shunra for having the same comment...Oops, that's what I get for walking away for a while and coming back before hitting Add Reply.

Edited December 23, 2003 by ju66l3r

December 23, 2003

In terms of usability, searching interstate exits doesn't matter if I want to head to SW New Hampshire up MA RT-2.

Ummm...Rte. 2 doesn't go to New Hampshire.

1.8k · December 23, 2003

I'd like to thank Markwell for hosting (and robertlipe for posting) the MapPoint "near the route" info in his FAQ. With a bit of map eyeballing, four pocket queries, and three good guesses, I was able to come up with a good example of a route from Reno to Olympia, showing all caches within 0.7 miles of the route.

The instructions needed to be tweaked a bit for MapPoint 2001. Right clicking shows a "find nearby places" option, which only shows near where I right-clicked. But choosing "entire route" in the "Around" dropdown in the Nearby Places pane worked great.

I did have to go in and add each nearby cache to the route stop by stop, but that was easy since those were the only ones listed in the nearby places pane.

Sweet.

(Each box represents a cache; box colors indicate which pocket query they came from; I deleted some yellow boxes that I plan on hitting before my May Reno trip; black circles represented my guesses as to the range of the pocket queries before I ran them, except the Reno ring, which I ran the query for first.)

For what it's worth, I think Microsoft licenses their MapPoint technology, but I don't know how usable it is for this kind of web interface, nor how many billions of dollars they'd charge for it.

(Edit: adding explanation of black circles)

Edited December 23, 2003 by travisl

December 23, 2003

For what it's worth, I think Microsoft licenses their MapPoint technology, but I don't know how usable it is for this kind of web interface, nor how many billions of dollars they'd charge for it.

It works great.

You don't want to know how much it costs. They have set a new limit on outrageous.

20.7k · December 23, 2003

Let's see, I think I saw MapPoint for sale yesterday for around four or five hundred bucks. How much could it possibly cost to license for all of our use? In the same vein, what's the GNP of Canada?

Edited December 23, 2003 by sbell111

2.1k · December 23, 2003

In terms of usability, searching interstate exits doesn't matter if I want to head to SW New Hampshire up MA RT-2.

Ummm...Rte. 2 doesn't go to New Hampshire.

For the technical among us, my route was 2 to 140 to 12 to 9 through Keene towards Brattleboro.

9.4k · December 23, 2003

I'd like to thank Markwell for ...

Excellent map, Travis. I just might have to start looking at the different software that's out there.

December 24, 2003

Let's see, I think I saw MapPoint for sale yesterday for around four or five hundred bucks. How much could it possibly cost to license for all of our use?

I could not find some of the pricing info I had before on this but I did find a place in the UK and this seems close to what I recall.

Microsoft MapPoint.NET is a web service and is available per user license or per transaction.

Per User - Approx £10,000 plus a fee per user based on the number of users

Per Transaction - 2 million transactions approx £10,000

3.5 million transactions approx £17,000

7.5 million transactions approx £34,000

The per user fee is a yearly charge. I think 10,000 pounds is about $17,000.

9.4k · December 24, 2003

Navtech licensing starts at around $20k/year, last time I priced it. Mappoint isn't even an option.

The Geocaching.com maps use an enhanced version of the Tiger Line database, which isn't quite good enough for routing from point a to point b. If we could afford the $20k for the navtech licensing we could do turn-by-turn directions, but you'd have to do a query along the route to get the geocaches. It's a complicated bit of coding to make it reasonably fast.

January 21, 2004

Here's an idea that might be computationally tractable. Note that an ellipse can be defined as the locus of points such that the sum of their distances from two points is constant. As a trivial example, a line is an ellipse but the only points within the ellipse must be on the line.

If the endpoints of a straightline (or route) are given, and the distances to each endpoint from a set of caches is computed and then added, one can then sort the caches by the sum. Those with the smallest sums will be nearest the straightline.

$ellipse-abd.gif$

This technique might be useful for a number of geocaching software tools. It isn't quite the same as a bounding rectangle, but it seems that it will end up with a shape that is probably quite useful.

Comments?

Team Geo-Jedi

January 21, 2004

Comments?

dadgum!

Now I know the answer to that question I had all those years ago. Sitting there in math class thinking when in the hell am I ever going to use this.

You know if I had actually paid attention maybe I would be able to give some kind of real comment. But as it is I think I was pretty well lost after the first sentence.

But hey you are using a graphic and it is on the internet so I am going to guess that you are right about what you are saying.

1.9k · January 21, 2004

hmmm, i think a PQ along a route would be problematic... server load being one. I laso think it would be quite a trick to code. It would require a heavy amount of geometric calculations.

good idea, just i think it would be problematic

January 22, 2004

Currently, one can get caches closest to a single point. Does this impose an undue load on the server?

The ellipse around a route that I am proposing doesn't seem that is should be only about a factor of two (or so) more work. It requires the following:

Two points need to be specified (instead of just one for the radial query)...

Two distance calculations for each cache (instead of one distance calc)

An addition for each cache - to sum the two distances

A sort on the sum of the two distances (same work as before)

Any cache that was exactly on the line between the two points would have a value equal to the distance between the two points. Other caches close to that straight line would have values not much larger.

This does not solve the "route" distance problem or closest to the freeway exit, or even address the fact that roads aren't straight lines... but I think that it may be useful in that it forms an ellipse around any two points.

I'm still not sure of the heavy computational load that this might impose. It doesn't seem that it is too much worse than the other distance type calculations. What am I missing?

Team Geo-Jedi

Search Along A Route

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment