Habe ChatGPT zwei GPX files Typ Track derselben Route analysieren lassen. Eine Datei habe ich mit dem new export aus der Android App erstellt. Die andere Version habe ich mit dem old export im Webbrowser erstellt. ChatGPT hat nur einen signifikanten Unterschied im Header gefunden der in old export nicht vorhanden ist.
Die new export Datei enthält zusätzlich eine schemaLocation-Angabe (inkl. Garmin-spezifischer Erweiterungen). Diese Erweiterungen werden zwar nicht genutzt, führen aber aller Wahrscheinlichkeit nach zum Problem mit der RE App. Somit liegt der Fehler bei Kurviger, weil die sich beim new Export nicht an den Mindeststandard Für gpx Dateien halten.
Habe dem Android App Support eine Mail geschrieben mit diesen Erkenntnissen. Hoffe die Korrigieren das.
Als Newbee darf ich noch keine Dateien hochladen. Siehe weiter oben.
Ich kann noch nicht mal mehr auf deinen Post antworten, weil Newbees nicht mehr als drei Post nacheinander verfassen dürfen, o.ä. Bin demnach ziemlich eingeschränkt.
Das ist nicht richtig.
Das ist eine grundsätzliche Einstellung im System.
Wenn man mehreren Leute antworten möchte, reicht meist ein Post aus und bedient sich dem @usernamen. Damit wird die Kommunikation auch recht schmal gehalten. Zitieren kann übrigens auch jeder User.
Apparently, the Royal Enfield app objects to the extended trkpt timestamps. It does import whole seconds. It also imports without trkpt timestamps. Wurstkuchl_new.gpx (254.4 KB) Wurstkuchl_new_-_.gpx (599.7 KB)
Okay, but what does that mean and how could it help to fix the problem? Kurviger should just turn back to old export for simple GPX files by removing the Garmin specific meta data, which are unused anyway.
Sorry for not uploading the files yet. Have to create some because all my existing files include my home address, which I am not willing to share.
It helps developers to understand what they need to change, so that the new export works for RE as well. The SW architecture may have changed significantly, so the old export component does not fit any more.
Yes, I just tried with one gpx and can confirm. When the fraction of the second is removed, the gpx loads.
Does not work with fraction .756
<time>2025-09-13T15:23:42.756Z</time>
Import possible without fraction:
<time>2025-09-13T15:23:42Z</time>
As far as I checked the xsd:datetime a fraction of a second is valid. From technical view I see no issue on Kurviger side. Implementation on RE seems incomplete to me.
Edit: .. wrote an email to support from royal enfield.
Curious to see how they react. Just asked ChatGPT to compare my files with regards to the time issue. So it indeed seems to be a poor implementation by Royal Enfield.
I mailed to royal enfield as well couple of days ago. I now provided them with an update about the timestamp issue. Maybe it helps if several people report this issue.
I do understand to a certain degree, but to be honest, I don’t have knowledge about gpx files. This is why I signed in for this forum and raised my hand in this thread. First reaction was that it must be a fault of the royal enfield app. And this kind of reaction is something what drives me crazy. Next reaction was to ask me to provide files, but as a newbie I was not able to do so, which was kind of annoying. Therefore I tried to figure things out by myself and I used ChatGPT for help.
I furthermore tried to validate the theory that the issues with the import of gpx files with a three digit seconds timestamp is the root cause. Therefore I checked the files I have first exported from the kurviger app with the new export and then processed with the locus Maps 3 Classic app (simple import/export), which caused the file to be accepted by the Royal enfield app and guess what? Locus also uses three digits seconds formate in it’s timestamps which is accepted by the royal enfield app without any error.
So to me it seems that we are not yet on the right track.
Possibly RE has another problem with the timestamps by the new Kurviger export. The timestamps do contain the date in the Y 1900 ? and the timestamps do start at zero (null) hour. Some softwares do have a problem with zero.
Not at home, no pc. I can test tomorrow evening. Mobile edit, sorry for eventual typos.
Possibly a false answer, I referenced a file anonimised by an osm tool. I should not answer in thé middle of the night after a restaurant visit with schnapps. (No worry I was not the car driver)
I did another test with a random tour of 116 km and I wanted to upload three files here. One kurviger new export, old export and the locus processed new export each of the same track. Of course I tested all three tracks with the RE App for importability. Kurviger files behaved as before. New export caused the error, old export was successful, but the locus file this time behaved differently than all the times before. It failed, what it never did before. So I am totally confused now. So maybe the error has something to do with the seconds format of the timestamps, but it seems to be a bit more complex. And it seems to be on the RE App side, but I honestly don’t understand what the problem is. If I should upload the three files, just give me a hint.
My bad, I guess. I appolagize if my choice of words made you feel uncomfortable.
Most of us discussing here are just ordinary users like you and do not belong to the development team. Our ability to help is limited to trying to locate the error and inform the developers what needs to be corrected. That includes mainly Kurviger developers, but also any other 3rd party (RE or other App providers).
GPX is a universal file format. It is possible to verify if a GPX is valid or not. The authors of the GPX file format provide an XSD file that allows to verify if a GPX is valid or not. This is documented here: Validating GPX Files
Our GPX is valid GPX 1.1 and our GPX can be read by pretty much any app or device that supports GPX.
If there is an app that can’t read the GPX this usually means that there is an issue with this app or device. If that app claims that they can read GPX files, they should be able to read our GPX files, as they are valid.
So it is the responsibility of that 3rd party to fix their import.
With all that said, we try to provide a wide compatibility with as many apps and devices as possible. Changing our export requires to consider the effects of that change. We recently improved our export to make sure the timestamps between track points don#t contain jumps. Removing accuracy from these points could create issues with the timestamps again. So it’s not just a minor change with no side effects.
Therefore, I still think that this is an issue that should be fixed by Royal Enfield unless there is other information that we have not considered. If RE won’t change their app, we can always rediscuss if Kurviger can change the export. But in my opinion the first priority should be RE.
