Klein Twülpstedt/ Seltsame Umlaute in manchen Namen

Moin,

Entschuldigt bitte meine laienhafte Ausdrucksweise:
Es gibt anscheinend in Utf8 verschiedene Möglichkeiten einen Umlaut wie ü darzustellen.
In diesem Zusammenhang ist mir z.B. https://www.osm.org/node/1534403755 aufgefallen.

Das ü in diesem Namen ist anders kodiert als das ü, das ich mit meiner Tastatur produziere. Sprich, im Hex Editor sieht der Name anders aus.

Mir ist das aufgefallen, weil das Programm mkgmap (Garmin Karten) mit dem Zeichen nichts anfangen kann und ein “u?” daraus macht.

Was ist da passiert? Kann/sollte man das in OSM korrigieren?
Edit: genauer gesagt, mkgmap hat Probleme mit dem Namen, wenn die Garmin Karte z.B. die code-page 1252 verwenden soll.

Grundsätzlich gibt’s relativ viele UTF Zeichen die zueinander sehr ähnlich aussehe, siehe http://www.unicode.org/Public/security/revision-05/confusables.txt aber in diesem Fall hat sich anscheinend jemand einfach sein ü zusammengebastelt: https://www.fontspace.com/unicode/analyzer#e=VHd1zIhscHN0ZWR0

Korrigieren: IMHO ja.

Es gibt global 46 Nodes mit diesem “ü”: https://overpass-turbo.eu/s/1cV1

(seit dem letzten Thread zur global Suche ist diese Art von Query jetzt auch deutlich flotter mit 6s)

Ist ja auch nicht “falsch” sondern nur “unüblich”, längerfristig sollten die Tools natürlich damit umgehen können.

Yep, das ist ein normales u mit nachträglich draufgesetzten Pünktchen. Vermutlich von keiner Suchfunktion als ü zu finden.

… davon allein zehn in Klein Twülpstedt :smiley:

Nö, JOSM findet beide Schreibweisen von Twülpstedt, wenn ich mit “selbsteingegebenem” Namen suche. Das ist ja gerade das verwirrende. Nach Unicode Logik mag das aber richtig sein.


$ curl -s https://api.openstreetmap.org/api/0.6/node/1534403755.json | jq -r .elements[0].tags.name | utf
    4b Lu K LATIN CAPITAL LETTER K
    6c Ll l LATIN SMALL LETTER L
    65 Ll e LATIN SMALL LETTER E
    69 Ll i LATIN SMALL LETTER I
    6e Ll n LATIN SMALL LETTER N
    20 Zs   SPACE
    54 Lu T LATIN CAPITAL LETTER T
    77 Ll w LATIN SMALL LETTER W
    75 Ll u LATIN SMALL LETTER U
   308 Mn ̈ COMBINING DIAERESIS
    6c Ll l LATIN SMALL LETTER L
    70 Ll p LATIN SMALL LETTER P
    73 Ll s LATIN SMALL LETTER S
    74 Ll t LATIN SMALL LETTER T
    65 Ll e LATIN SMALL LETTER E
    64 Ll d LATIN SMALL LETTER D
    74 Ll t LATIN SMALL LETTER T
    2c Po , COMMA
    20 Zs   SPACE
    46 Lu F LATIN CAPITAL LETTER F
    72 Ll r LATIN SMALL LETTER R
    69 Ll i LATIN SMALL LETTER I
    65 Ll e LATIN SMALL LETTER E
    64 Ll d LATIN SMALL LETTER D
    68 Ll h LATIN SMALL LETTER H
    6f Ll o LATIN SMALL LETTER O
    66 Ll f LATIN SMALL LETTER F
     a Cc 

Hier nochmal der interessante Teil:


    75 Ll u LATIN SMALL LETTER U
   308 Mn ̈ COMBINING DIAERESIS

Wie das passiert ist, weiß ich nicht. Was: Siehe https://de.wikipedia.org/wiki/Kombinierendes_Zeichen
Meiner Meinung nach sollte das korrigiert werden. Idealerweise kommt Software damit zwar klar, aber ich würde nicht davon ausgehen. Außerdem ist’s hässlich.

OK, dann rudere ich mal zurück. Aber:

Jein. “nicht falsch” ist es bei den meisten anderen kombinierenden Zeichen (Beispiel: a und ̃ ist gleichwertig zu ã), aber das gilt nicht für die Diärese. Die sieht zwar genauso aus wie Umlautpünktchen, ist aber funktional etwas vollkommen anderes. Die Diärese ändert nicht die Aussprache eines Vokals, sondern trennt zwei Vokale voneinander (Beispiel: der Name Noël). Damit ist ein ü nicht gleichwertig zu einem u mit Diärese.

Also ist diese Schreibweise des ü auch in Unicode-Logik falsch. Warum, sollte einem OSM-Mapper unmittelbar einleuchten: Im Schriftbild sieht es gleichwertig aus, aber ein Screenreader bekommt Schluckauf, weil er die Diärese als abgesetzten Vokal interpretieren muss. Der muss dann Tw-Ulpstedt oder so was lesen. Auch hier wird nicht für den Renderer gearbeitet :smiley:

Das Unicode-Konsortium hat anfangs viele Kombinationen aus Akzent o.ä. und Grundbuchstaben oder auch Kombinationen aus zwei Buchstaben einen eigenen Unicode-Punkt spendiert für das fertig zusammengesetzte Zeiten. Irgendwann wurde es dem Unicode-K. aber zu viel, so dass einige exotische Sprachen mit seltenen Kombinationen ihre akzentuierten Buchstaben nur mit kombinierendem Zeichen bekommen können …
Kombinierendes Zeichen ist nicht nur die Diärese, sondern auch ein Trema/Umlautpunkte/…, Unicode unterscheidet da nicht.
Die deutschen Pünktchen entstanden übrigens aus einem hochgestellten e: Aͤ/aͤ, erst später haben sich die e’s, die in Sütterlin wie zwei Striche aussehen, zu zwei Strichen bzw. Punkten abgeschliffen … Insofern sind unsere Pünktchen nix anderes wie andere (kombinierende) Akzente und es gilt Simons “Ist ja auch nicht “falsch” sondern nur “unüblich”” voll und ganz.
Wer die Diäresis ubedingt vom Trema unterscheiden will/muss, muss zusätzlich zum CGJ greifen

Siehe 2. Beitrag in diesem Thread https://forum.openstreetmap.org/viewtopic.php?pid=846427#p846427

Wenn ich das richtig sehe, dann sollten zumindest in D alle Tag-Werte, die so ein COMBINING DIAERESIS enthalten, genauer angeschaut werden. Kann man da nicht einen Bot einsezen? Zumindest im Zusammenhang mit A,O,U,a,o oder u könnten diese dann automatisiert zu Ä,Ö,Ü,ä,ö oder ü konvertiert werden.
Ich werde mal schauen, warum der entsprechende Java code in mkgmap das nicht somacht wie erwartet.

Ich denke, das kann man noch zu Fuss machen, dafür braucht es keinen Bot: https://overpass-turbo.eu/s/1cXa
Global nur 105 Nodes…