bei den maxweight-tags hier im kleinsten und ärmsten Bundesland ist mir aufgefallen, dass als Dezimaltrenner das hierzulande übliche Komma statt dem Punkt verwendet wurde. Das kommt wegen der üblichen Gewichtsgrenzen (3,5;5,5;7,5 Tonnen) relativ häufig vor. Es ist natürlich müßig, so etwas von Hand zu korrigieren. Gibt es da schon Batchverfahren, um dieses zu bereinigen?
Andere Tags mit Dezimalfeldern wie maxheight, maxwidth, width usw. sind davon natürlich auch betroffen, tauchen lediglich seltener auf. Vermutlich stellt sich das Problem in den anderen “Komma-Ländern” ähnlich dar.
Ich würde behaupten, solange der Sinn trotzdem eindeutig bleibt, ist es Aufgabe der Software, das korrekt zu verstehen. Ob 3,5;5,5; ODER 3.5;5.5; dort steht, beide Varianten ergeben - minimale “Intelligenz” im Renderer/etc. vorausgesetzt, das gleiche (eindeutige) Ergebnis. Schreibt natürlich jemand 3.5,5.5, dann wird es schon schwieriger
Natürlich kannst du das über die API auch gesammelt korrigieren; dein Korrektur-Algorithmus ist aber der gleiche, der auch im Renderer eingebaut werden könnte.
Punkt und Komma werden regional unterschiedlich verwendet.
Die Benutzerschnittstellen kommen mit beiden Varianten gut zurecht.
Wie es in der Datenbank gespeichert wird kann uns (Benutzern) egal sein.
Denn die Anwendungsprogramme können damit sowieso korrekt umgehen.
“Verboten” ist aber eine Dateneingabe mit “Tausendertrennzeichen”, ein solches führt immer zu Inkonsistenzen.
Bei der Ausgabe kann die Software hingegen problemlos Tausendertrennzeichen einfügen und so die Lesbarkeit verbessern.
Es ist immer hilfreich, sich auf ein Datenformat zu einigen. Sonst braucht man sich hinterher auch nicht wundern, wenn Router und Renderer was ganz anderes machen, als man sich vorgestellt hat.
Nachdem sowohl “.” als auch “,” Dezimal- oder Tausenderzeichen sein können und “,” auch noch ein Trennzeichen, kommt man schnell in den Bereich, wo das nicht mehr automatisch entwirrt werden kann.
Auf Benutzerebene soll die Eingabe hingegen möglicht den Benutzergewohnheiten entsprechen.
Dafür gibt es intelligente Benutzerschnittstellen.
Wenn in einem Feld nur Zahlen als Eingabe zugelassen sind, dann ist die Unterscheidung des Dezimaltrennzeichens recht einfach.
Falls mal eine Uneindeutigkeit auftritt, dann kann man den Benutzer einfach um Entscheidung per Klick bitten:
Meintest Du: 22.000,00 € oder 22,00 €
Und bei komplexeren Eingaben hilft eine Auswahlliste oder eine grafische Unterstützung (Beispielfoto, etc).
Klar, das Detenformat sollte eindeutig sein, zumindest in der Datenbank. Eine Prüfung/Konvertierung sollte in den Editoren vorgenommen werden. Naja, das 1000er Trennzeichen-Problem ist eher theoretisch: Werte >1000 sollten bei den üblichen Einträgen (maxheight, maxweight, maxspeed, maxwidth…) doch selten vorkommen Das “,” statt “;” bei Aufzählungen/Mehrfachwerten sehe ich schon eher als problematisch an…
Eigentlich sollte das Dezimal-/Tausendertrennzeichen aus den Ländereinstellungen des Betriebssystems entnommen werden, damit die Benutzereingabe entsprechend bewertet werden kann. Dann kann es datenbankintern richtig und eindeutig gespeichert werden. Andere Eingaben dürfen nicht akzeptiert werden. Dann gibt es bei dem Feldwert in der Datenbank und bei der der Darstellung keine Doppeldeutigkeiten. Momentan werden die Eingaben aber 1:1 als Text in die Datenbank übernommen. Aus dem Datenwirrwarr dann das richtige zu interpretieren ist dann eher Glücksache.
Ich hab gerade die Osm Wiki Seite gesucht, wo steht, dass Zahlenwerte in OSM generell mit . statt , geschrieben werden sollen, aber die scheint es nicht zu geben?
Steht es also immer nur auf den Seiten zu den einzelnen Tags?
Mehrere mahlen gelesen dass das Komma dezimal jetzt auch als ‘Eingabe’ erlaubt ist (GitHub wahrscheinlich). Ich weiß nicht wie Progs 1,234 verstehen solten, moeglich hängt es von der geografischen Lage der Eingabe ab oder wie gesagt die einstellungen. Grade in JOSM getested mit neuen Brückenlänge von 123,5. No problem. Demnächst die QA warnungen abwarten.
Immer dieses autobezogene Weltbild!
gauge=1.435 wäre ein Kandidat für (hier falsch gesetztes) Tausendertrennzeichen mit (hier richtig verwendeter) Einheit mm
gauge=0.165 wäre ein Kandidat für (hier richtig gesetztes) Dezimaltrennzeichen mit (hier falsch verwendeter) Einheit m (da müsste das m dazu oder eben 16.5), das mit der Spurweite fehlt mir noch im Diskussionsfaden der Modellbahnanlagen … flöt
Beides wären drei Ziffern hinterm Trennzeichen und eine Ziffer davor, daher automagisch nicht auseinanderzufieseln …
ist mir aufgefallen, dass als Dezimaltrenner das hierzulande übliche Komma statt dem Punkt verwendet wurde. Das kommt wegen der üblichen Gewichtsgrenzen (3,5;5,5;7,5 Tonnen) relativ häufig vor. Es ist natürlich müßig, so etwas von Hand zu korrigieren. Gibt es da schon Batchverfahren, um dieses zu bereinigen?
