AutoRoute GPX Import Errors
I have had an interesting experience attempting to import a set of about 150 pushpins in a GPX file that I created myself into AutoRoute 2010. Two (that I noticed immediately, there may be more) were placed at the wrong co-ordinates of lattitude and longitude. I noticed these quite easily as they were in the Atlantic Ocean rather than being on terra firma where they should be. Might there be more? The few others that I spot-checked were in the right locations.

I did this twice and got the same erroneous results. However, if I import the GPX file into Streets and Trips, I do not get the same error with respect to these two pushpins although I cannot be sure without going through the entire download.

I would appreciate it if other users on the Forum tried this themselves to see if they get the same results. I am attaching the file below along with the AXE file from which the GPX was extracted. Even if you do not have AutoRoute, you might try an import into S&T to see if there are any obvious errors.

Thanks in advance and I welcome all thoughts on this phenomenon.
Attached Files
File Type: gpx Le-Plus-Beaux-Villages-de-France.gpx (55.5 KB)
File Type: axe Beaux Villages.axe (215.5 KB)
Hey SpadesFlush,

I spot-checked the questionable locations and they are being placed in Atlantic Ocean because that is where the lat/long coordinates in the GPX file have them. The problem lies not in AutoRoute but in the GPX file.

Example from the GPX file:
<wpt lat="48.3812761555701" lon="-8.96032173388808E-02"> (this lat/long is in the ocean)
<type>Le Plus Beaux Villages de France</type>
<link href="http://www.les-plus-beaux-villages-de-france.org/en/saint-ceneri-le-gerei">

Note: the Longitudes ending in "...E-02" don't look right to me either.
I found two more wrongly placed pushpins for a total of four errors out of 153 pushpins. These were much harder to spot inasmuch as they were within the borders of France, not in the middle of the ocean.

My approach to coming to this conclusion was to open two maps in side-by-side windows, one with the orignal AXE file and the other with the new file with just the GPX downloaded pushpins. I then added the pushpins of each as stops [Legend and overview, Add pushpins as stops from drop-down menu for the set]. After manually ordering the stops so they were in the same order on both maps (having eliminated the two already-known bad ones), I calculated routes for both maps. Then I campared the Driving directions for the stops from map to map. Where there was a discrepancy, there was a problem location. Eliminating the two 'new' bad ones, the Driving directions for both agreed, leading me to conclude that I had found all the bad ones.

The one thing that seems to pop out from looking at the 'bads' is that the longitudes are wrong, by a little or a lot.

This is somewhat unnerving as it calls into question the wisdom of counting on AutoRoute to accurately position downloaded pushpins. Until this is clarified, I cannot trust AutoRoute GPX imports.
Thanks, for your reply, Larry.

The GPX file was created by AutoRoute, however. So what went wrong? And why is the GPX file read correctly in Streets & Trips??
If I copy the pushpin set from AutoRoute to S&T and then do a GPX export from S&T and then import that GPX file into a new virgin S&T map, the pushpins locate as they should.

This says to me that something is wrong in my AutoRoute rather than the GPX file itself.
I also easily found the 4 erroneous pushpins just by doing a search for 'E-02' in the GPX file.

This appears to be a bug yes but not in the GPX import. You can continue to trust the GPX import functionality. The bug is in the creation of the GPX file from AutoRoute. From what I can tell the bug only shows up while exporting pushpins to GPX that lie along the longitude line where W changes to E. In these cases the software is failing to output or create a proper longitude for the coordinate. Any pp located outside this area continue to work as expected.

The screenshot below shows the same 38,000 pushpins. Green icons = imported from source data (XLS file). Red icons = result of GPX export then GPX import. You can clearly see a pattern where the problem lies.
Attached Images
Ken in Regina
Nice catch Larry. I'm surprised the problem exists in Autoroute and not Streets. I always assumed there would be mostly common code, especially in something generic like GPX file import/export. Shoulda just been an "include" from the appropriate library. Not?

Nice catch SpadesFlush! I just zero'd in on the issue.
Ken there is common code so the bug is technically in both S&T and AR but since it only happens for Lat/longs outside of North America it isn't an concern for S&T users.
Thanks for chasing this down, Larry!

Although I initially mis-diagnosed the problem, I am relieved that I was on to something. I could see that the issue revolved around +/- zero longitude positions but your image really makes that clear. I wonder if the same issues might apply to lattitude positions, although there aren't many POIs that close to the Equator and no Microsoft mapping applications come even close to mapping those regions.

The only thing I am unclear on now is why, in view of your last post, I did not have the same problem when I exported the POIs to a GPX file from S&T.
On further examination, I can see what is going 'wrong' with the GPX export function.

Where the longitude number is small, either plus or minus from zero, something converts the number format from "decimal" to "scientific". Therefore, "-0.05323456" becomes "-5.323456E-02" and is read as "-5.323456", ignoring the trailing "E-02", in the import.
The problem range seems to be less than +0.1 and greater than -0.1. In other words, any number beginning with 0.0 followed by any other digits, regardless of sign.
FWIW, I have edited the GPX file for the French villages to correct these longitude problems and it is attached hereto.
Attached Files
File Type: gpx Le-Plus-Beaux-Villages-de-France.gpx (55.5 KB)
© laptopgpsworld.com About