BaseCamp doesn't read Orux GPX file

[Ivan_S]

Hi to all from a newcomer,
I've been for years a satisfied Oruxmaps user (version 7) and I recently bought from Playstore and installed Oruxmaps v. 10.1.3 GP on my new Android phone.
After some adaptation problems to the new version menus it works, but when I try to open on my PC a track GPX file generated by OruxMaps it doesn't work and I get a message of 'unknown error'.
Any idea on how to solve the problem?
Thank you in advance,
Ivan

[Ivan_S]

Hi,
waiting for help, i tried to upload one of the Orux generated track files that BaseCamp doesn't open in GPSvisualizer.com and 'convertied' it in a "new" GPX file.
The "new" file is regularly read by BaseCamp, so it seems that the file structure generated by Oruxmaps is at the origin of the problem.
Again, any idea on how to solve it?
Thank you in advance,
Ivan

[orux]

Hi,
waiting for help, i tried to upload one of the Orux generated track files that BaseCamp doesn't open in GPSvisualizer.com and 'convertied' it in a "new" GPX file.
The "new" file is regularly read by BaseCamp, so it seems that the file structure generated by Oruxmaps is at the origin of the problem.
Again, any idea on how to solve it?
Thank you in advance,
Ivan

We're sorry, but if basecamp doesn't provide more information about the problem, it's hard to resolve.

The GPX created with OruxMaps is correct, it can be opened with any app I know, without problems.

orux

[Ivan_S]

Thank you for the answer,
no, Basecamp just report 'unknown error'. Given that BC regularly open GPX track files created with a previuos version of Oruxmaps I was wondering if the new Oruxmaps version introduced variations in the GPX file structure, that's the reason of my question and/or if someone noticed the same problem. The error doesn't seem to be attributable to BC.

I would also have a question about routes; whenever a route is loaded it is not visible because by default  the 'hide route' option in the tracks/route menù is checked and the tracks/routes menù must be accessed  to uncheck the 'hide route' option. I don't understand the reason of these default choice.
By
Ivan

[LaurentG]

It would be a good idea to share with us
- the GPX file that Basecamp fails to load
- and its conversion you did (that Basecamp loads)

We (and Orux) could then compare both, trying to find what, present in the 1st one but not in the 2nd, could be problematic...

[Ivan_S]

Thank you LaurentG, thank you Orux,
I tried a file content analysis, but my knowledge are limited ...
I'm attaching two files:

Ivan Original track not readable by BaseCamp.GPX  = the file obtained by OruxMaps and not readable by BaseCamp as described,
Ivan track converted by GPSvisualizer.GPX  =  the same file uploaded on GPSvisualizer and 'converted' in a GPX file then readable by BC.

I deleted most of the points on both files to reduce size and increse readability.
If something is not clear please let me know
Ivan

[Ivan_S]

Sorry, it seems that only one file was attached, I add the other
Ivan

[LaurentG]

I'm not sure it's the best idea to have done modifications in files... even if it is to reduce size and increase readability....
It would be preferable to analyse "original" files...

Nevertheless, I've analysed your files.

1) I confirm that 1st file is not "readable" by BaseCamp, while the second one is. On the other hand, even the 1st file is readable by some other apps, like JOSM or GoogleEarth, or french Geoportail, ... or OruxMaps itself, even "old free" version, ie. 7.4.26
This (readability by other tools) leads to think that issue is in BaseCamp and not in GPX file itself.

2) I then compared both files.
The "reprocessed" file contains the same data than the "original" one, except some data :

- Both files contain some "Metadata", but not with the same content
- The two waypoints "Start" and "End" are not at all in the reprocessed file
- The track type ("Bicicletta su strada") is not in the reprocessed file
- Extension data relative to Track and/or to TrackPoints are also missing in the reprocessed file

Surely, issue in basecamp cannot come from different metadata. But it could from any of the data that are missing in the reprocessed file.
So I only had remove all of them except one and see if file became readable by basecamp to determine which one was the cause of problem.

And the result is that basecamp fails when extension data relative to trackpoints are present, giving speed at each trackpoint.
These extensions are all in the form

Code Select Expand

<extensions>
<gpxtpx:TrackPointExtension>
<gpxtpx:speed>0.25</gpxtpx:speed>
</gpxtpx:TrackPointExtension>
</extensions>


If these data are not managed by Basecamp, they should be simply ignored, and not cause to fail.

Please note also that there are also extension data associated to the two waypoints that do not prevent loading by basecamp

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="ICON" subtype="0">38</om:ext>
</om:oruxmapsextensions>
</extensions>


and also relative to track itself (that do not prevent loading as well)

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="TYPE" subtype="0">8</om:ext>
<om:ext type="DIFFICULTY">0</om:ext>
</om:oruxmapsextensions>
</extensions>

Result of my analysis : GPX file generated by OM is perfect from formal standpoint, and it is Basecamp that contains a bug, preventing it to ignore some extension data


Finally, I did a last test : let extension data for trackpoints, but modify them to make them with same format than other (the ones accepted in basecamp) oruxmaps extension, ie. replace their definition with

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="SPEED">0.25</om:ext>
</om:oruxmapsextensions>
</extensions>

In such a case, file becomes "loadable" by basecamp, even with extension data on trackpoints.

This means that basecamp is not "troubled" by the fact that there is extension data on trackpoint, but only if it is "gpxtpx" extension....

[orux]

I'm not sure it's the best idea to have done modifications in files... even if it is to reduce size and increase readability....
It would be preferable to analyse "original" files...

Nevertheless, I've analysed your files....

Thanks for this analysis.

You can prevent that data from being exported in the gpx:

Settings-->Tracks/routes-->GPX settings-->export sensors data. Uncheck speed.
But maybe you can do this additional test:
At the beggining, replace:xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1"
with:xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v2"
then try to load it again in basecamp,


orux

[LaurentG]

I was imagining that URL in xmlns:gpxtpx could be the cause (even if I don't know exactly the use (and role) of this url)
And I just did the test you recommend, and with xmlns:gpxtpx updated to v2 as you indicate, it works in Basecamp.

But it remains very surprising to me, since both URL (/v1 and /v2) are responding the same, ie. "Page not found" !

Surely something I don't understand clearly....

[orux]

I was imagining that URL in xmlns:gpxtpx could be the cause (even if I don't know exactly the use (and role) of this url)
And I just did the test you recommend, and with xmlns:gpxtpx updated to v2 as you indicate, it works in Basecamp.

But it remains very surprising to me, since both URL (/v1 and /v2) are responding the same, ie. "Page not found" !

Surely something I don't understand clearly....

Hello!

Both are URI,s not URL,s.

The xsd used for validating the xml is here:

https://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd



orux

[Ivan_S]

Many thanks Laurent, wonderful analysis.
I can easily send you the original file, I only deleted data points, but it seems not necessary now to repeat the analysis.
It will take some time to me to assimilate the information and try to overcome the problem as suggested by Orux and I'll let you know within next week.

A residual doubt would be: Why the problem appear in the new OM version? Was something changed in the way OM build the GPX file or what?
Nobody reported the same problem before or it depends on a particular OM setting?

The BC version I'm using is 4.7.4 and it always worked with GPX file from many different origin (OM 7.4 generated, downloaded by various sites, etc.)
If BC is too "flimsy" and crashes with formally correct files please let me know how I can try to inform Garmin about the problem.
Best regards and, again, thanks
Ivan

[LaurentG]

A residual doubt would be: Why the problem appear in the new OM version? Was something changed in the way OM build the GPX file or what?

The speed parameter (that is "behind" the issue) was not exported at all in old OM versions (at least in "free" version, 7.4.26)
But, as Orux mentioned in his own answer, in recent versions of OM, you can choose to export it or not. If you choose to do not export it, no more issue.

And, on a more long term perspective, I'm quite sure that in the next version of OM, Orux will modify the xmlns:gpxtpx parameter to v2, and the issue will disappear...

[LaurentG]

Both are URI,s not URL,s.

The xsd used for validating the xml is here:

https://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd

Hi @orux, thanks, I've (almost.... ) understood.

And I can see inside the XSD that it points to the URI.
And the difference between XSD v1 and v2 is that "Speed" (and some others) do not exist in v1, but only in v2, that obviously explain the issue.

But please help me once again : how to retrieve the xsd when provided only the URI ?

(in other word : how to determine the https://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd URL when only URI "http://www.garmin.com/xmlschemas/TrackPointExtension/v2" is provided...? )

[Ivan_S]

Hi Laurent and Orux,
I tested both the approaches suggested by Orux and, of course, they works, so I can now recover old tracks and load directly in BC any future track.

The reasons of differences among OruxMaps versions are still obscure to me, but now it is not relevant and I'll follow your future discussion on the subject, if any.
Perhaps Garmin changed their reference schemes but then they did not implemented in BC? (forget about if this a stupid sentence )

About Laurent statement:
" But it remains very surprising to me, since both URL (/v1 and /v2) are responding the same, ie. "Page not found" !"

To me it happened that ....v1 was not found while ...v2 open the corresponding xmlschema
Perhaps BC v. 4.7.4 does not access the v2 xmlschema and return the unknown error, I'll try the upgrade to the next version and we'll see.

Thank you again, hope my post was not wasted time for you,
Ivan