Automate Shifting Of Waypoints

[+elmo-fried]

Does anyone have a way to shift all LAT/LON coordinates by a fixed amount? I've found that a certain mapping program (Microsoft MapPoint) is off in my county when mapping lat/lon and comparing to streets. I've found that if I shift a coordinate by .225 mi. bearing 304 degrees it appears at the proper location.

 

The reason I use MSMapPoint is so I can quickly plot a number of waypoints and then have it figure out the shortest/quickest path to each using the best order. I can draw a box around a cluster of waypoints, right-click and say "Add pushpins as stops" and then use the "Optimize Stops" and then "Get Directions." Of course it's only as good as how well the LAT/LON projections on the map correspond to the streets.

 

Right now I use gpsbabel to export all my PQs to CSV and then MSMapPoint "Data Link Wizard" option that allows my to plot them all on the map (and I can link multiple CSV files giving each their own distictive icon). I can download the PQ, kick off the script I have that unzips, convers to CSV and then "Update Linked Records" in MSMapPoint to refresh all the waypoints.

 

What I'd like to do is shift all the waypoints .225mi. bear 304 degrees. I used a program called Fizzymagic's GeoCalc.exe to manually figure this out, but I need to automate it from the command-line. Unix tools preferred, but I'll take a Windows tool if I must.

 

Just for those curious, here's an example of what the optimized routes portion of MSMapPoint looks like:

 

Edited March 17, 2004 by elmo-fried

[+SylvrStorm]

I don't know MapPoint and don't have a solution for the problem you stated, but it sounds very much like you may be using the incorrect datum. Does MapPoint support a variety of datums? If so, make sure it's set to the same datum as the coords you're using, namely WGS84 for geocaching.

 

Hope this helps. If not, hopefully somebody else knows a way to do the coord conversion.

 

SylvrStorm

[+elmo-fried]

Excellent point and no doubt that is in fact the problem. However, the version I have (Microsoft MapPoint 2002) doesn't have any way to change/specify the DATUM (nor does it let me know what it is using/expecting).

 

Say I did know the DATUM, again I'd need a way to automate changing of waypoints from the DATUM Geocaching.com uses in PQ/GPX to what MSMapPoint expects... Any suggestions (I could just test as there are only so many DATUM options)?

[+elmo-fried]

I checked the help file:

Note  MapPoint maps are based on the WGS 84 (World Geodetic System 1984) datum.

I suppose that's not it then :/ Back to the original request of how to automate shifting waypoints. What I really need is a CLI version of GeoCalc.exe. You reading this, Fizzymagic?

Edited March 17, 2004 by elmo-fried

[+SylvrStorm]

That's odd. Like I said, I don't use MapPoint, but I know others do. There's a good chance some MapPoint user will happen upon this thread and clear it up, but if not you might try contacting travisl. I know he's used MapPoint to put together routes for cache machine events.

 

Is there a chance that Microsoft did something weird like using the wrong datum just in the area where you live? Might be grasping at straws, but if that's the case they might have a patch on their website. At the very least, you could let them know and ask them about it. If there really is a problem in the MapPoint map, it's probably better to fix the problem at its source rather than come up with a manual workaround that's going to be an ongoing hassle.

 

Good Luck.

 

SylvrStorm

[+wolf452]

I just went to the MS MapPoint Site. It states that Lat/Long is either decimal degrees or dd.mm.ss............. If you are entering 42.33.75 you will either get an error message or be in the wrong place (42.33.45).

You could convert a file worth of points from geocache (dd.mm.mmm) to either

dd.ddddd or dd.mm.ss by using Corpscon a free program on the NGS website.

[+elmo-fried]

I just went to the MS MapPoint Site. It states that Lat/Long is either decimal degrees or dd.mm.ss............. If you are entering 42.33.75 you will either get an error message or be in the wrong place (42.33.45).

You could convert a file worth of points from geocache (dd.mm.mmm) to either

dd.ddddd or dd.mm.ss by using Corpscon a free program on the NGS website.

That's not the issue. GPX files already have it in decimal degrees and gpsbabel doesn't do anything to mess that up when creating the CSV files. Further, it'd be off a lot more than 0.225mi.

[+fizzymagic]

The issue with the Tiger database around Modesto is a long-running one. Everything is, as you point out, off by about a quarter mile.

 

Because the area is such a small one, you can just add the proper amount to the lat and long and it will work fine.

 

Given the numbers you quote, the amount to add would be .109 minutes to the lat and .204 minutes to the long. But those numbers are suspiciously close to even tenths of a minute; try adding .100 and .200 minutes, respectively, and see how that comes out.

[+elmo-fried]

The issue with the Tiger database around Modesto is a long-running one.  Everything is, as you point out, off by about a quarter mile. 

 

Because the area is such a small one, you can just add the proper amount to the lat and long and it will work fine.

 

Given the numbers you quote, the amount to add would be .109 minutes to the lat and .204 minutes to the long.  But those numbers are suspiciously close to even tenths of a minute; try adding .100 and .200 minutes, respectively, and see how that comes out.

Yeah, that worked as a start. I actually just went out to my street corner and marked a Waypoint, and then made an XLS that linked to the CSV but did modifications. I then linked the XLS to MapPoint (actually a lot easier than linking a CSV into MapPoint). I could then easily tweak the correction and update it in MapPoint:

 

LAT +0.001727

LONG -0.003433

=SUM(Home.csv!A1+0.001727)
=SUM(Home.csv!B1-0.003433)
=Home.csv!C1

I then applied this to all the other two files I use and checked out a few caches I knew about, and they were dead on correct on the map. Hoping MapPoint 2004 will fix this as we have a copy at the office from our MSDN subscription, but I haven't felt like driving 40 minutes round-trip yet just to check.

Edited March 19, 2004 by elmo-fried

[+elmo-fried]

MS MapPoint 2004 has no problems with the data for Stanislaus County. Also, MS MapPoint 2002 had no problems with Santa Clara County, or at least not with the caches I did around Rancho San Antonio.