Is anyone an expert on .gpx files?

[jdc]

A program of mine outputs gpx routes, and I've just tried one of them which goes west from 177° 30'W to 177° 20'E, as follows:

<rte>
  <name>route from gt circle planner</name>
  <rtept lat="50.000" lon="-177.500"/>
  <rtept lat="50.010" lon="-178.000"/>
  <rtept lat="50.023" lon="-179.000"/>
  <rtept lat="50.028" lon="-180.000"/>
  <rtept lat="50.025" lon="179.000"/>
  <rtept lat="50.012" lon="178.000"/>
  <rtept lat="50.000" lon="177.333"/>
</rte>

However when I try to view it on google maps it plots a line from 177° 30'W to 180°, but then a line going back E all the way round the earth to 179°E. Maybe, indeed probably is, my fault as I can't believe google maps would get something this basic wrong, but it begs the question how one's supposed to represent tracks across 180°?

 

[DinghyMan]

Is there an option in google maps to autoclose routes?

When I load it into My Maps it gives an error

Add full minimum tags and it works, with no extra line

<?xml version="1.0"?>
<gpx
version="1.0"
creator="Test Data"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="GPX: the GPS Exchange Format"
xsi:schemaLocation="GPX: the GPS Exchange Format http://www.topografix.com/GPX/1/0/gpx.xsd">
<rte>
<name>route from gt circle planner</name>
<rtept lat="50.000" lon="-177.500"/>
<rtept lat="50.010" lon="-178.000"/>
<rtept lat="50.023" lon="-179.000"/>
<rtept lat="50.028" lon="-180.000"/>
<rtept lat="50.025" lon="179.000"/>
<rtept lat="50.012" lon="178.000"/>
<rtept lat="50.000" lon="177.333"/>
</rte>
</gpx>

 

[jdc]

The original file has the extra lines, I just pasted the <rte> part of the file. But thanks for the suggestion to look for options in google maps.

 

[wonkywinch]

Try using gpx.studio — the online GPX file editor

 

[AntarcticPilot]

A program of mine outputs gpx routes, and I've just tried one of them which goes west from 177° 30'W to 177° 20'E, as follows:

<rte>
  <name>route from gt circle planner</name>
  <rtept lat="50.000" lon="-177.500"/>
  <rtept lat="50.010" lon="-178.000"/>
  <rtept lat="50.023" lon="-179.000"/>
  <rtept lat="50.028" lon="-180.000"/>
  <rtept lat="50.025" lon="179.000"/>
  <rtept lat="50.012" lon="178.000"/>
  <rtept lat="50.000" lon="177.333"/>
</rte>

However when I try to view it on google maps it plots a line from 177° 30'W to 180°, but then a line going back E all the way round the earth to 179°E. Maybe, indeed probably is, my fault as I can't believe google maps would get something this basic wrong, but it begs the question how one's supposed to represent tracks across 180°?

I am afraid that the discontinuity at 180° E/W is badly handled in many systems. The system here is assuming that the line always goes from higher to lower longitude, and the system doesn't "know" that 50°N 179.999°W is right next to 50°N 179.999°E! And I'm afraid Google Earth is by no means the only system to get it wrong; a major Geographic Information Systems protocol almost had that error baked into it; if I hadn't pointed out the issue! There was an issue reported here where a Raymarine system failed to correctly select objects near the 180° line for exactly that reason; it assumed that the bounding box used to select features always went from top left (lower latitude and longitude ) to bottom right (Higher latitude and longitude) so when the bounding box straddled the 180° line , the box went all round the world and EXCLUDED the required detail! That was actually the exact issue that I pointed out to a committee working on the GML standard.

I worked on Antarctica where both the discontinuities in geographic coordinate systems come into play!

 

[jdc]

I am afraid that the discontinuity at 180° E/W is badly handled in many systems. The system here is assuming that the line always goes from higher to lower longitude, and the system doesn't "know" that 50°N 179.999°W is right next to 50°N 179.999°E! And I'm afraid Google Earth is by no means the only system to get it wrong; a major Geographic Information Systems protocol almost had that error baked into it; if I hadn't pointed out the issue! There was an issue reported here where a Raymarine system failed to correctly select objects near the 180° line for exactly that reason; it assumed that the bounding box used to select features always went from top left (lower latitude and longitude ) to bottom right (Higher latitude and longitude) so when the bounding box straddled the 180° line , the box went all round the world and EXCLUDED the required detail! That was actually the exact issue that I pointed out to a committee working on the GML standard.

I worked on Antarctica where both the discontinuities in geographic coordinate systems come into play!

That's very helpful, thank you. I've found that it does work on some programs, but fails on others. However the real reason for asking was to asses whether my generator was at fault, or Google's reader; it seems the latter, so I will release my (rather trivial; it's just a great circle calculator) App despite this possible bug. The App does cope with voyages across the 180° as far as I can tell on testing.

 

[Refueler]

GPX files are not universal as you've found .... I've been into mapping and creation of charts for various plotters ... it can drive you nuts.

I helped guy who writes GPS Utility to sort for ONWA .... successful .... GPX files were just not working ... but he sorted ...

 

[AntarcticPilot]

GPX files are not universal as you've found .... I've been into mapping and creation of charts for various plotters ... it can drive you nuts.

I helped guy who writes GPS Utility to sort for ONWA .... successful .... GPX files were just not working ... but he sorted ...

Tell me about it! I spent a couple of weeks preparing charts for a Garmin chartplotter for use in Antarctica, and then discovered that the system couldn't display charts outside the area of the preloaded global map - which only went to 60°S. Garmin were not very helpful beyond saying "You can't do that!"

 

[jdc]

And in Svalbard I found that Navionics (and so Raymarine as well) couldn't display N of 75°, which is about Bear Island, 300 miles or so S of where we were going.

Back to my original question: I have found that some can cope if I edit the gpx file to avoid the wrap, by doing 179,180,181, 182 ...

See here: gpx studio gets it completely wrong if it has the wrap at 180, it can't even render the latitude correctly!
But with the manual edit it does:


MemoryMap gets it wrong, but at least the Latitudes are correct:



But a random app on my smartphone (Spain Topo Maps) gets it correct from the get go!

 

[AntarcticPilot]

And in Svalbard I found that Navionics (and so Raymarine as well) couldn't display N of 75°, which is about Bear Island, 300 miles or so S of where we were going.

Back to my original question: I have found that some can cope if I edit the gpx file to avoid the wrap, by doing 179,180,181, 182 ...

See here: gpx studio gets it completely wrong if it has the wrap at 180, it can't even render the latitude correctly!View attachment 171821
But with the manual edit it does:
View attachment 171822

MemoryMap gets it wrong, but at least the Latitudes are correct:

View attachment 171823

But a random app on my smartphone (Spain Topo Maps) gets it correct from the get go!

View attachment 171825

Yes; when researching my problem in Antarctica, I became aware of the same problem in the north; I forget the exact latitude at which it cut off!

But with the Garmin kit it was a slightly different problem. I could create map files in Garmin format for our area of interest, but the plotter wouldn't pan beyond the area of the inbuilt coarse base map.

 

[jdc]

In view of the plotting programs having fewer issues when there is no wrap, I've modified my great circle calculator so that when a route goes through 180, it doesn't wrap, just carries on going (+ or -) 179, 180, 181, 182, 183 etc. The map display programs also seem to be happy to plot courses going through longitude 360!

But I'm not at all sure this is what the gpx 'standard' says to do...

 

[AntarcticPilot]

In view of the plotting programs having fewer issues when there is no wrap, I've modified my great circle calculator so that when a route goes through 180, it doesn't wrap, just carries on going (+ or -) 179, 180, 181, 182, 183 etc. The map display programs also seem to be happy to plot courses going through longitude 360!

But I'm not at all sure this is what the gpx 'standard' says to do...

GPX is merely a data format; it doesn't specify the direction of a line. That's up to the program that uses the data. Personally, I'd implement it so it always chose the shortest distance, as points stored in GPX format will usually be of routes, but testing that would be an extra computational overhead, so people avoid that. I've had to deal with it in the Antarctic - even well-known, highly-regarded professional software suites get it wrong sometimes!