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

[Christian Müller]

> Gesendet: Samstag, 11. Januar 2025 um 21:12
> Von: "Markus via Talk-de" <talk-de at openstreetmap.org>
> An: "Florian Lohoff" <f at zz.de>, "Markus via Talk-de" <talk-de at openstreetmap.org>
> CC: Markus <liste12A45q7 at gmx.de>
> Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB (Nachkommastellen)
>
> Übrigens: Meter-Angaben mit 15 Nachkommastellen entsprechen der
> Genauigkeit, die mit einem Elektronenmikroskop maximal erzielbar sind
> und das ist ja nicht so geeignet fürs Mapping - auch nicht für
> Mikromapping ;-)
> 

Es geht im Kontext OSM nicht um diese 15 Nachkommastellen, diese
werden hier nur deshalb theoretisiert, weil mit der Einführung
einer achten Nachkommastelle, der Datentyp double statt float
gewählt wird.

Die Rechner wurden nicht mit OSM im Hinterkopf, und der Maßgabe
gebaut, dass es Fließkommazahltypen mit Längen zwischen denen von
float und double bräuchte.

https://en.wikipedia.org/wiki/Double-precision_floating-point_format
ordnet den Begriff "float" keiner spezifischen Präzision (mehr) zu,
dort wird unterschieden zwischen

half - 16bit
single - 32bit
double - 64bit
quadruple - 128bit
octuple - 256bit

Synonym dazu wird "float" mit den Bitbreiten ge-suffixed, also
float16, float32, etc. - was eindeutiger ist, als zu riskieren,
dass "float" von einem neueren Compiler beispielsweise in einen
breiteren Typ als 32-bit umdefiniert wird (das gab es bereits
mit int - ursprünglich 16bit breit, später ohne Namensänderung
auf 32bit aufgebohrt)

Zumindest nativ gibt es auf den populären Rechnern keinen Fließkomma-
zahltyp der, hypothetisch für OSM nützlich, zwischen 32bit und 64bit
angesiedelt wäre.

Die zwei Gründe, die ad hoc einfallen, die API der OSM Datenbank
so anzupassen, dass sie eine weitere Nachkommastelle unterstützt,
wären imho:

- Vermeidung von Fehlerfortpflanzung, ungewollte Verschiebungen
durch Maschinenrundung

- der Wunsch auch am Äquator höher als 10cm aufzulösen


Ob der Aufwand den Nutzen rechtfertigt, müssen diejenigen be-
urteilen, die eine Änderung dahingehend bewirken wollen.  Allerdings
wirkt es auch nicht sonderlich kunstfertig, wenn große Teile der
Toolchain komplett mit "double", also float64 arbeiten, aber gerade
das Datengrab/Backend nicht:

Die Frage nach der Sinnhaftigkeit lässt sich aus diesem technischen
Blickwinkel auch umgekehrt aufzäumen:

Welchen Sinn macht es, diese historisch gewachsenen 7 Nachkomma-
stellen im Backend zu halten, wenn das restliche Ökosystem mit 15
arbeitet?  Das erscheint aus technischer Sicht wenig ästhetisch.

Andererseits kann aus anderen Gründen eine höhere Präzision auch
unerwünscht sein, weil dies evtl. als Einladung zu Anwendungen und
Applikationen verstanden wird, die ethisch nicht mit den Grundsätz-
en von OSM vertretbar sind.

Da es für die eine oder die gegenteilige Design-Entscheidung nicht
zwangsläufig einen singulären, lapidaren Grund gibt, kann auch die
einfach formulierte Frage nach der Sinnhaftigkeit zu Antworten
führen, die zunächst nicht offensichtlich oder gar widersprüchlich
sind.


OpenStreetMap hat als wichtiger Konkurrent zum kommerziellen Google
Maps damals wie heute Optionen, eine Alternative bereitgestellt.

Damals haben viele gefragt:  "Wieso OpenStreetMap?"  .. es gibt doch
Google Maps.  Als es um die Vereinnahmung _öffentlicher_ Daten durch
Tech-Konzerne ging, hat auch kein Beteiligter im Projekt nach der
"Sinnhaftigkeit" gefragt.  Wichtig war es, Leute zu befähigen, selbst
Initiative zu ergreifen und sich Themen wie informationelle Selbst-
bestimmung nicht aus der Hand nehmen zu lassen.

Womit ein weiterer Aspekt genannt wäre, unter dem die ursprüngliche
Frage beleuchtet werden kann:  Soll das Backend Nutzern die Fähig-
keit nehmen, Daten mit einer Präzision im 1cm oder im Millimeter-
bereich abzuspeichern?

Wenn die Technik dadurch nicht in Mitleidenschaft gezogen wird,
ließe sich hier argumentieren, dass die Technik nicht _limitierend_
sondern _befähigend_ wirken solle.  D. h. keine technische Vorgabe
soll abschließend entscheidend, sondern derjenige, der die Tools
verwendet.


Unter der Maßgabe, dass es sich um ein Ökosystem mit zahlreichen
Teilnehmern handelt, wird es so sein, dass eine große Gruppe keine
höhere Genauigkeit bei der Speicherung der Koordinaten im Backend
braucht, oder sich nicht vorstellen kann, wozu diese nützlich sein
könnte.  Andererseits bedeutet die Nicht-Verfügbarkeit derselben
auch, dass niemand zeigen könnte, wozu das evtl. doch öffentlich
nützlich ist.

Der bisherige Software-Stack ist eher mächtig, die Bearbeitungs-
und Filterwerkzeuge sind zahlreich.  Ein Datentrafo, der vorhandene
Präzision vernichtet, also float32 mittels float16 beschneidet,
ist einfach geschrieben.  Die Umkehrung, Präzision hinzuzufügen,
wo sie ggf. doch benötigt wird, ist schwieriger.  Projekte, welche
z.B. 3D-Modelle in andere Datenbanken ausgelagert haben, zeigen auf,
dass es mit Verlinkung/Referenzierung grundsätzlich funktioniert,
allerdings ist das oft keine generische, sondern eine anwendungs-
bezogen spezifische Lösung.



Gruß