KML 2.3 support?

[dmillman]

Are there any plans to add support for KML 2.3?
Currently GpsPrune doesn't check the KML version, and gives the error "No coordinate information found in the file" when opening KML 2.3 files.

[activityworkshop]

Thanks for your question.
That document you link makes it clear that 2.3 is just a minor revision over 2.2, so most things are identical and most 2.3 documents should be loadable without problems if the unrecognized bits are "gracefully ignored".

For example, if I take the example in section 10.7.4 and load it into GpsPrune, it works fine. Also other fragments with waypoints are recognised properly. It could be that your particular kml file can't be loaded properly, because it uses some other data structure. GpsPrune doesn't attempt to implement every single feature that exists in KML (that specification document is HUGE!).

You probably don't want to share your kml, but if you can paste a fragment (with the coordinates obscured, if you like), then I can see which kinds of elements we're talking about. I imagine that it's not the version number causing the problem, but if it's a useful feature which GpsPrune should support, then we can look at adding it.

[mojo-hakase]

I have the same problem with KML/KMZ files exported by OpenTracks. It seems that the "gx:" prefix is not required for <gx:track> and <gx:coord> tags.
Here is a stripped KML file that does not work in GpsPrune but in other applications:

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://www.opengis.net/kml/2.3"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:opentracks="http://opentracksapp.com/xmlschemas/v1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/kml/2.3 http://schemas.opengis.net/kml/2.3/ogckml23.xsd
                        http://opentracksapp.com/xmlschemas/v1 http://opentracksapp.com/xmlschemas/OpenTracks_v1.xsd">

<Document>
<open>1</open>
<visibility>1</visibility>
<name><![CDATA[]]></name>
<atom:generator><![CDATA[OpenTracks]]></atom:generator>
<Placemark>
<name><![CDATA[]]></name>
<description><![CDATA[]]></description>
<styleUrl>#track</styleUrl>
<MultiTrack>
<altitudeMode>absolute</altitudeMode>
<interpolate>1</interpolate>
<Track>
<when>2023-05-25T12:00:00.000Z</when>
<coord/>
<when>2023-05-25T12:00:00.010Z</when>
<coord>-35 35 35</coord>
<when>2023-05-25T12:00:00.020Z</when>
<coord/>
</Track>
</MultiTrack>
</Placemark>
</Document>
</kml>

[mojo-hakase]

The following patch fixes the issue.

diff --git a/src/tim/prune/load/xml/KmlHandler.java b/src/tim/prune/load/xml/KmlHandler.java
index 0b41304..5fd3419 100644
--- a/src/tim/prune/load/xml/KmlHandler.java
+++ b/src/tim/prune/load/xml/KmlHandler.java
@@ -46,7 +46,7 @@ else if (tagName.equals("coordinates"))
 			_insideCoordinates = true;
 			_coordinates = null;
 		}
-		else if (tagName.equals("gx:track"))
+		else if (tagName.equals("gx:track") || tagName.equals("track"))
 		{
 			_insideGxTrack = true;
 		}
@@ -92,13 +92,13 @@ else if (tagName.equals("when"))
 			else
 				_whenList.add(_value);
 		}
-		else if (tagName.equals("gx:coord"))
+		else if (tagName.equals("gx:coord") || tagName.equals("coord"))
 		{
 			if (_insideGxTrack) {
 				_whereList.add(_value);
 			}
 		}
-		else if (tagName.equals("gx:track"))
+		else if (tagName.equals("gx:track") || tagName.equals("track"))
 		{
 			processGxTrack();
 			_insideGxTrack = false;

[dmillman]

My KMLs are also from OpenTracks.

[activityworkshop]

Thanks, @mojo-hakase for the explanation, that makes it a lot clearer.
I find this particular snippet a little confusing:

<when>2023-05-25T12:00:00.000Z</when> <coord/> <when>2023-05-25T12:00:00.010Z</when> <coord>-35 35 35</coord> <when>2023-05-25T12:00:00.020Z</when> <coord/>
because it seems to have three timestamps but only one useful set of coordinates. So it represents just one point? But anyway, I can see that it's very similar to the gx: tags.

So if your patch works for reading these kml files, then the next question is what should GpsPrune do about saving a track to kml / kmz?

It appears that now we have three potentially incompatible formats of kml -- firstly the kml before 2.3 which is unable to handle timestamps of points, then thanks to Google Extensions the "before 2.3 with gx tags", and now the "after 2.3" variety as well.

When saving KML, GpsPrune currently has for this purpose an awkward pair of radio buttons to select between either "Standard KML" or "Extended KML with timestamps". If you save as "Standard KML" then you lose all your timestamps but you can expect any program to be able to load it. If you save as "Extended KML with timestamps" then you keep your timestamps but if some program doesn't understand the Google Extensions then it will probably just refuse to load it.

Now with the 2.3 variety as well, I have no idea how widespread support is for these three variants. Does GpsPrune need to offer three radio buttons in future instead of two? To me, that doesn't sound very friendly and I'm not sure how to describe the three options so that the user can make the right choice!

Also, may I ask out of interest, why do you prefer saving from OpenTracks as KMZ instead of GPX?

[mojo-hakase]

Regarding the empty coord tags, I don't know why OpenTracks exports it that way.

Since I have almost zero knowledge about KML, I'm not sure what is the best way to handle KML output. I would say giving the user the option, marking the default option as recommend, is a good idea. Like this maybe:

   - KML 2.3 (recommend)
   - KML 2.2 Extended
   - KML 2.2 Standard (without timestamps!)

I chose KMZ simply because it's the default option in OpenTracks. Also my navigation/maps app on the phone does not open GPX files.

[activityworkshop]

Apparently the empty <coord/> tags are intentional - they're to indicate something happening at a given timestamp (for example, starting a recording) where no position is available. See OpenTracksApp/OpenTracks#639 .

This doesn't cause problems for GpsPrune directly, because it should just ignore them (and throw away the timestamps), but if you save the file again then GpsPrune will have forgotten that these "pointless" timestamps (intentional joke) existed. So depending on what you want to use the file for afterwards, maybe this removal presents other problems.

About the three options, yes you're probably right. But maybe three radio buttons is too many and they should be in a dropdown instead (meaning that you have to open the dropdown to see what the other options are). If you loaded a kml 2.2 file, should the default export option still be kml 2.3 do you think?