Question

I would like to continue the discussion from this post: GPX Schema validation problems. To go directly to the point, I want to ask how people are parsing and working with GPX files in their software or give me suggestions as to how one should do it.

Although one may say, well just parse the trkpt elements and use them in your software, the things are not that simple for me. Firstly, as discussed in the cited post above, a lot of the gpx-producing-devices(software, gps-handheld-devices, etc) produce gpx files which do NOT conform to the official GPX schema(elements are laid-out in the wrong order, value types changed, elements’ names changed, etc.). My initial taught when starting parsing gpx files, is firstly check if they validate against the GPX schema . There are a lot of them which contain the actual GPS data ( sequence of latitude/longitude/elevation values ) but the format in which it is presented ( although nicely hidden by the GPX suffix) may be designed anyhow. So the file will contain the required data, but will not conform to the GPX schema. How is this problem overcomed ? Is there any way to make the software accept generic GPX files as input ?

Secondly, I would like to point out I am not interested in various suggestions you may have(e.g. first pre-process the GPX file and then parse it, change your schema, etc.) as to how to solve the problem. I am more interested if someone knows how things are done in practice. So if anyone has or has had any experience with processing GPX files in (possibly) commercial environment please do share your thoughts.

I hope I made my points clear.

Thanks,

Petar

Answer 1

In my applications I’m using a normal XML parser (e.g. pythons xml.dom.minidom) I’m just using the tag names to access the information I need.
As it was mentioned in the other Thread, the thing that makes validation fail is the <xsd:sequence> in the GPX standard definition. While it’s true that GPX producing devices should respect the standard, it’s actually not that big of a deal on the parsing side (at least with the GPX Files/Devices I worked on).

If a GPX file contains additional information then it will be dropped (unless you chose to extract the tagnames unknown to you).

If this method fails because the file is not vaild XML or the GPX uses different tag names for e.g. lat lon information there is no other way to read the file than to write a special importer for this specific use case (I have not seen such files, except for corrupted ones, in the wild)