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ß _______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
