Webplaner zu ITN, Umlaute-Salat, vermeidbar?

Hallo!
Ich probiere grad das Abo, u.a. wegen der Wegpunkte-Benamung. Bisher habe ich das immer in einem Zwischenschritt im ITN-Converter erledigt. Mir fällt auf, daß die deutschen Umlaute als übler Zeichensalat dort landen, also wahrscheinlich auch im Tom.
Gibt es eine Möglichkeit, das zu vermeiden, ohne jetzt jeden Umlaut als ae oe usw. zu schreiben?
Zeichensatz-Einstellungen, oder sowas?
Viele Grüße: Spilles
No english version, it’s about german Umlaute, so…

Hast du es mal im TomTom probiert? So weit ich mich erinere verwendet TomTom einen komischen Zeichensatz, deshalb geben wir das so komisch aus. Sollte TomTom mittlerweile einen Standardzeichensatz wie UTF8 verwenden, dann könnte man das leicht anpassen.

Isn’t the only strange encoding the UTF-16LE of CoPilot 9?

I see every other export format using UTF-8.

Ja, hab’s probiert, es kommt das gleiche Durcheinander im Tom an. WIMRE habe ich nie auf Umlaute achten müssen, weder bei den Dateinamen, noch bei den Wegpunktnamen.

Ich habe noch weitere Tests gemacht, mit dem Standard-GPX-Format kommen die Umlaute richtig rüber, aber das wisst ihr ja sicher. :wink: Also, ich würde gerne den gleichen Zeichensatz für den Export nach ITN haben. Kann auch auf das alte Navcoreformat 5-8 beschränkt sein, mir egal.

Danke und Gruß: Spilles

Ok, I did a bit more research. TomTom used to use ISO-8859-1 but they switched to UTF-8. So it’s probably safe to switch to UTF-8.

Some info seems to exist here, they mention:

“The character encoding of the description is assumed to be Windows-1252 (the Latin alphabet), sometimes called ANSI.”

Can I do something to clearify this?
I’ve opened the ITN in Notepad++, with UTF-8 everything is as desired, mit Umlauten. If i change to ANSI, the mess is there…

941602|5005286|Fischerhütte|0|
946053|5009743|Wegpunkt 23|0|
952530|5010550|BayrSchanz|0|
958835|5015858|Wegpunkt 25|0|
948606|5022942|Wegpunkt 26|0|
950483|5030357|Wegpunkt 27|0|
946026|5031525|Steinau - weitester Punkt|0|
943766|5027375|Wegpunkt 29|0|
941173|5019702|Wegpunkt 30|0|
924649|5008897|Schoellkrpn|0|
931204|5005660|Engländer|0|
941013|4997849|Wegpunkt 33|0|
938213|4990104|Autobahn Rohrbrunn|0|
931026|4986263|zur Geishöhe|0|

Ok I double checked. The server is actually exporting ITN as UTF8. So the file is in UTF8.

So, TomTom is apparently expecting ANSI. So we would have to change the encoding to ANSI on the server.

@Spilles what TomTom device are you using?

I use a TT Urban Rider, 4GC01, Anwendung 9.205

Thanks, the Urban Rider is a relatively old device, maybe someone with a newer TomTom Rider could double check this, just to be sure?

Yes, it’s not new, but it works. :wink:
May I propose a test? Kurviger offers two TT export formats, the “Navcore 5-8” seems to be older than my Rider. I can use these files and can’t tell the difference. How about switching this format to ANSI and see what happens?

Ich nutze den Rider 2013 und exportiere zuerst nach GPX und dann ebenso via ITN-Converter zu lesbarem Text.

NAVCore 5-9 bzw. 9.5, soweit mir bekannt geht es da wohl um die maximale Zeilenanzahl bzw. Wegpunkte einer Datei.

Den Unterschied den ich sehe ist das Zeichenformat.
Im Notepad++ wird mir bei Kurviger exportiert UNIX (LF) angezeigt.
Der ITN-Converter liefert dagegen WINDOWS (CR+LF).
Windows arbeitet wohl mit ANSI.

Eine Umstellung zu ANSI würden nicht nur ich begrüssen!

I use the Rider 2013 and export first to GPX and then also via ITN converter to readable text.

NAVCore 5-9 or 9.5, as far as I know, it is probably about the maximum number of lines or waypoints of a file.

The difference I see is the character format.
In Notepad++ I get UNIX (LF) for Kurviger exported.
The ITN-Converter delivers WINDOWS (CR+LF).
Windows probably works with ANSI.

Not only I would welcome a change to ANSI!

1 Like

Nachtrag:

Da stelle ich soeben fest, der Rider selbst erzeugt via GPX2ITN ja selbst ein ITN-File mit der Kodierung “UNIX (LF)” und “UTF-8”.
Nehme ich nun ein ITN-File vom Kurviger-Web, lade das Im Rider und speichere ohne Änderung das File unter einem neuen Namen ab, dann stimmen die Umlaute!
Der Rider selbst erzeugt aber nun eine Kodierung “UNIX (LF)” und “UTF-8-BOM
Lade ich ein ITN-File vom Kurviger-Web im Notepad++ und andere die “Kodierung” auf “UTF-8-BOM” so stimmen die Umlaute im TT-Rider.

Rufe ich auf dem Rider das von GPX2ITN umgewandelte ITN-File auf, so ersetzt mir der Rider selbständig die Einträge von “TT-01” auf zB. “A73 Talbrücke Langer Grund”. Umlaute sind korrekt.
Speicher ich dieses Datei nun auf dem Rider so wird die Kodierung wieder verändert zu “UTF-8-BOM”. Das File nun im Notepad++ geöffnet und nun habe ich den Umlaut-Salat auch hier. Mit Kodierung “ANSI” erscheint es wieder korrekt.
Der Fehler liegt für mich bei Tomtom.

Ich kenne mich da nicht mehr aus!

https://software-lupe.de/tipp/utf-8-ohne-bom-mit-notepad/

Addendum:

I just realized that the Rider itself creates an ITN file with the encoding “UNIX (LF)” and “UTF-8” via GPX2ITN.
If I now take an ITN file from the Kurviger web, load it in the Rider and save the file under a new name without any changes, then the umlauts are correct!
But the Rider itself now creates an encoding “UNIX (LF)” and “UTF-8-BOM”.
If I load an ITN-file from Kurviger-Web in Notepad++ and change the “encoding” to “UTF-8-BOM” the umlauts in the TT-Rider are correct.

If I call the ITN file converted by GPX2ITN on the Rider, then the Rider replaces me independently the entries of “TT-01” on e.g. “A73 Talbrücke Langer Grund”. Umlauts are correct.
If I save this file on the Rider, the encoding is changed again to “UTF-8-BOM”. I opened the file in Notepad++ and now I have the umlaut-salad here too. With encoding “ANSI” it appears correct again.
The error lies for me with Tomtom.

I do not know myself there any more!

I hope that the translation by DeepL.com is understandable

https://software-lupe.de/tipp/utf-8-ohne-bom-mit-notepad/

Unterschreib ich, doppelt und dreifach! Ich habe jetzt auch noch mal ein paar Tests gemacht und muß sagen, daß die Aussage von Notepad++ für mich nicht maßgebend ist. Lade ich die ITN aus Kurviger in den ITN-Converter, dann habe ich Salat. Der Converter verhält sich genau wie mein Rider, so viel weiß ich immerhin.

Du musst aus Kurviger-WEB oder -APP als GPX-Route exportieren. Das GPX-File in den ITN-Converter laden und beim abspeichern als ITN wird dann das Format convertiert.

So ist es, und bitte nach:
WINDOWS (CR+LF) mit ANSI
so wandle ich seit Jahren GPX-Routen zu ITN-Files. Teilweise stehen da von Basecamp zu einem WP kleine Kurzgeschichten zu Tankstellen oder Gasthöfen. Da hat es nie Probleme mit den Umlauten gegeben.

You have to export from Kurviger-WEB or -APP as GPX-Route. Load the GPX file into the ITN converter and then when you save it as ITN the format is converted.

So it is, and please after:
WINDOWS (CR+LF) with ANSI.
this is how I convert GPX routes to ITN files for years. Partly there are from Basecamp to a WP small short stories to gas stations or inns. Since there have never been problems with the umlauts.

Translated with DeepL Translate: The world's most accurate translator (free version)

Ja, das habe ich ja im Prinzip schon seit Jahren so gemacht. Jetzt kann man aber im Web-Planer bereits die WP benamsen, warum sollte ich da immer noch ein weiteres Zwischenprogramm benutzen. Genau das war doch mein erster Punkt… :wink:

Why should I use additional programms, Kurviger should instead export in the right codeset.

Mit den CR/LF habe ich kein Problem bemerkt, würde sich sowas auf Umlaute auswirken?

Der Umweg über GPX und ITN-Converter hat nur den Zweck die richtige Zeichen-Kodierung (Umlaute) vom GPX nach ITN zu transferieren. Und ja, das sind überflüssige 5sek die man benötigt.
CR/LF > ich habe nur den Unterschied bemerkt und bin so auf diese Zeichen-Kodierung gestossen. Inwieweit sich das auf die Umlaute auswirkt vermag ich nicht zu sagen.

Das war schon damals der Umweg beim Motoplaner. Der konnte schon die Benamsung ins ITN auswerfen. Aber oben wird doch angekündigt die Kodierung passend abzuändern.

The detour via GPX and ITN converter has only the purpose to transfer the correct character encoding (umlauts) from GPX to ITN. And yes, that’s a superfluous 5sec you need.
CR/LF > I just noticed the difference and that’s how I came across this character encoding. To what extent this affects the umlauts I cannot say.

That was already at that time the detour with the Motoplaner. That could already throw the Benamsung out into the ITN. But above is nevertheless announced the coding suitably to change.

Thanks for providing this additional information. I will add this to the todo list and will keep you updated :slight_smile:.

Mir geht’s nicht um die Zeit. Ich wollte nur nicht nochmal Konvertierungsschritte durchführen, die möglicherweise andere Probleme mit sich bringen. Aber Du hast schon recht, der ITN Converter hat eigentlich noch nie was kaputt gemacht. Beim Motoplaner habe ich den aber noch nicht benutzt, oder doch? Da ging das Durchrattern der WP-Liste sowieso einfacher.

OK, nice.

BTW Zeit: Ich habe gerade gelernt, daß in der OSM-Kartenbasis 2 Jahre alte Vollsperrungen nicht eingepflegt sind. Gegen die Zeit die es braucht, das alles gegenzuchecken ist der Schritt über ITN-Conv ein Klacks…