[Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)

[Christian Müller]

Die Links

https://de.wikipedia.org/wiki/Gleitkommazahl#Ung%C3%BCltigkeit_der_Assoziativ-_und_Distributivgesetze
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Minimizing_the_effect_of_accuracy_problems

beschreiben das Problem, dass mathematisch gleich-
wertige Formeln in ihrer algorithmischen Umsetzung
für die Maschine, und basierend auf den IEEE Fließ-
kommazahltypen, unter Umständen deutlich unter-
schiedliche Ergebnisse erzielen.

Für die Berechnung von pi stellt der dritte Link
exemplarisch zwei Wege dar, wovon nur einer in der
maschinellen IEEE-Umsetzung hin zur korrekten Lösung
konvergiert.

Die Wahl des Datentyps ist nicht allein ausschlag-
gebend für die Koordinatengenauigkeit oder den Er-
halt selbiger bei Erfassung, Änderung und ggf.
Wiederverwendung eines Datensatzes.

Bei ungeschickter Wahl der Rechenverfahren z.B.
für die Editieroperationen kann es zu Auslöschungen

https://de.wikipedia.org/wiki/Gleitkommazahl#Ausl%C3%B6schung

Absorptionen, Unter- oder Überläufen kommen.  Da die
beschriebenen Probleme vollumfänglich auf alle IEEE
Typen zutreffen, darf man aber m. E. schließen, dass
eine ausgereifte Funktion, die bereits dahingehend
optimiert wurde, solche Genauigkeitsprobleme zu mini-
mieren, nicht weniger präzise arbeitet, wenn sie mit
Variablen vom doppelt breiten Datentyp aus der gleich-
en Familie arbeitet.

Demnach wäre der Aufwand vertretbar, solche Anwendungen,
die nicht mit "double" OSM-Daten verarbeiten, umzustell-
en, falls eine (hypothetische..) Umstellung des OSM-Back-
ends in dem Modus erfolgt, dass man Rückwärtskompatibilität
ausschließt.

Dieser Ausschluß könnte dann Sinn machen, wenn alle Daten-
sätze an einem Tag x konvertiert wurden, und zu befürchten
ist, dass alte Editoren im Zyklus Laden-Editieren-Speichern
eine höhere Genauigkeit überschreiben, wenn/solange sie
intern auf float32 Datentypen operieren..

.. alternativ dazu, allerdings mit höherem programmatischen
Aufwand, könnte die OSM-API wahlweise den Edit von Koord-
inaten solange zulassen, wie sie im Bestandsformat vor-
liegen.  D.h. eine Aktualisierung durch float32 Anwendungen
würde erst dann von der API abgelehnt, nachdem eine float64
Anwendung lat/lon Werte mit höherer Genauigkeit für eine
bestimmte Koordinate übermittelt hat und damit den Daten-
satz "befördert" hat bzw. intern ein dafür vorgesehenes
Flag gesetzt hat.  (In diesem Modus ließe man intern die
Koexistenz beider Formate zu, bis die letzte Koordinate
per Edit konvertiert wurde.)


.. oder man führt einen weiteren Elementtyp ein, etwa
"node64", sofern man der Überzeugung ist, dass höhere
Präzision dauerhaft nur eine untergeordnete Rolle spielt.
Auch in diesem Fall müssten alle Tools den Umgang damit
lernen, da ansonsten wegen des Sichtproblems (die einen
sehen und bearbeiten Daten diesen Typs; die anderen er-
halten sie gar nicht..) mit Doppeleinträgen, also sowohl
als "node" als auch als "node64" zu rechnen ist.
(daher sei von diesem Vorschlag gleich wieder Abstand
genommen..)


Referenz dazu:
https://wiki.openstreetmap.org/wiki/API_v0.6#Elements_2


Die v0.6 API wird seit April 2009 genutzt, Änderungen
daran müssen wohlüberlegt sein.  Da sie das interne
DB-Format nicht veröffentlicht, wäre denkbar, intern
double zu verwenden, aber nur 8 oder 9 Nachkomma-
stellen bei der Kommunikation über die API zu ver-
äußern, womit der Zuwachs an übertragenen Daten über-
schaubar bliebe.  Für die ebenfalls veröffentlichten
DB-Abzüge gilt dies aber nicht und Leute die einen
privaten OSM-Server in Kopie betreiben wären im Zug-
zwang eine solche Backend-Entscheidung mitzutragen,
sprich u.U. mehr Speicherplatz für die Instanz be-
reitzustellen.


Laut
https://taginfo.openstreetmap.org/sources/db

existieren derzeit ca. 9,634 Milliarden nodes
in der Datenbank.  Ohne Optimierung oder Kompression
würde die DB bei einer Umstellung von float (4 byte)
auf double (8 byte) damit statt ca. 71.8 GB also
143.6 GB für die Datenhaltung der Koordinaten in
Anspruch nehmen.

Für mobile Offline-Nutzung auf PDAs und Smart-
phones erscheint das erstmal als nicht hinnehm-
bar, aber man muss bedenken, dass die DB nicht
unverändert auf solchen Geräten genutzt wird
und die bereits vorhandenen Toolchains zur Vor-
verarbeitung lediglich mit dem geänderten Ein-
gabe-Format umgehen müssten, während die Ausgabe
unverändert bliebe und somit keine Mehr-Inanspruch-
nahme auf den mobilen Datenträgern bedeutet.

Ein Mehraufwand serverseitig besteht.  Wenn
man nur die IEEE-Typen betrachtet, welche
von den verbreiteten Datenbanksystemen unter-
stützt werden, fallen für die Möglichkeit, eine
weitere Nachkommastelle abzuspeichern, +8 bytes
pro Koordinate an.  Bei einer Mischlösung mit
einem weiteren Elementtyp weniger, die aber
weitreichendere und aufwendigere Software-
anpassungen zur Folge hätte, als eine
vollständige Umstellung.



Gruß