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

[Christian Müller]

> Gesendet: Samstag, 11. Januar 2025 um 20:58
> Von: "Markus via Talk-de" <talk-de at openstreetmap.org>
> An: talk-de at openstreetmap.org
> CC: Markus <liste12A45q7 at gmx.de>
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
>
> Danke Jochen,
> 
> Dann stimmt also die Angabe im Wiki noch :-)
> 
> Das ist für Mapping im Feld auch nach Rundungen immer noch ausreichend.
> 
> Das bedeutet aber auch, dass Indoor-, Architektur-- Inneneinrichtungs-
> und Spielzeugeisenbahnmapping noch eine 8. Nachkommastelle bräuchte?
> 
> Und dass Genauigkeiten /echter/ Lasermessungen verloren gehenNiemand
> hier, der Genaueres weiss?


Es wurde gesagt, dass es Bestandteile in der Toolchain gibt,
welche mit einer größeren Genauigkeit arbeiten.  Das bedeutet,
dass beim Abspeichern / Upload hin zur OSM-DB Genauigkeit ver-
loren geht, wenn die ursprüngliche Datenerhebung und der ver-
wendete Software-Stack für das Editing genauer ist.

Es bedeutet nicht, dass z.B. bei der Arbeit mit einem anderen
Server, die gleichen Einschränkungen bestehen (müssen).  Ohne
es geprüft zu haben, ist aber zu vermuten, dass die Aussage
auch auf die andere öffentliche Instanz,
https://www.openhistoricalmap.org

zutrifft.


Man muss sich die ganze Toolchain anschauen, um abzuschätzen,
ob es einen Teil gibt, der Daten verlusthaft weiterverarbeitet.

Populär ist die Overpass API, sieht man sich z.B.

https://github.com/drolbr/Overpass-API/blob/master/src/lib/overpass.h

an, sieht man, dass sowohl die Strukturen Overpass_C_Node als
auch Coord mit dem Datentyp "double" arbeiten.  Gleiches gilt
für den Editor JOSM, siehe

https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/coor/ILatLon.java


Auch wenn die OSM-DB "nur" mit einer float Genauigkeit Daten ab-
speichert, kann es nützlich sein (lies: nicht "sinnlos"), bei der
Verarbeitung und Änderung den Datentyp double zu nutzen, da das
Resultat von mehreren Edit-Operationen (z.B. Verschieben) damit
genauer ausfällt, als wenn durchgehend mit float gerechnet wird,
da sich Rundungsfehler nach jeder weiteren Operation verstärken
können, Referenzen dazu:

https://en.wikipedia.org/wiki/Floating-point_arithmetic#Representable_numbers,_conversion_and_rounding
https://de.wikipedia.org/wiki/Gleitkommazahl#Gleitkommaarithmetik

(Einige der angesprochenen Probleme sind zudem auch bei Verwendung
des Datentyps double präsent.)



Gruß