Also die “Meinung” sollte bei Feldern einer Datenbank keine Rolle spielen. Das muss exakt definiert werden. Könnt ihr euch das Chaos vorstellen, wenn bei den 2D-Koordinaten plötzlich eine Mischung aus WGS84, Gauss-Krüger, UTM, Lambert (Frankreich) u.s.w. Koordinaten eingetragen werden, ununterscheidbar ins gleiche Datenfeld ohne Datums-Normierung? Die OSM-Karte wäre dann ziemlicher Schrott. So etwas würde seinen Augen keiner mehr zumuten. Zum Glück ist OSM noch eine 2D-Karte, dass das "ele"nd nicht optisch auffällt. 3D-Karten auf OSM-Basis werden noch mit alternativen Höhendaten gefüttert (z.B. STRM). Naja, ist vielleicht auch sinnvoller, weil Höhen bei OSM normalerweise sowieso nicht getaggt werden. Unvollständig bringt das nicht so viel.
Wie gesagt, in einer Datenbank braucht man eine ordentliche Definition. Gibt’s das bei OSM nicht? Ich hatte in der Frühphase des OSM-Projektes nie ganz verstanden, wie überhaupt die ganzen Straßentypen/kategorien definiert sind. Das ist wohl organisch gewachsen. Der Nachteil dabei, wenn erst später definiert wird, ist, dass evtl. viel Mapping-Arbeit für die Katz war und neu gemacht oder konvertiert werden muss. Die einzige Definition zum ele-Tag war die Wiki-Seite. Das ist doch “die” Definition, oder?
Man könnte natürlich auch grundsätzlich die lokale Höhe als Default für das ele-Tag definieren. Aber in der Datenverarbeitung wäre es besser mit einer weltweit einheitlichen Definition, vor allem wegen der Interoperabilität. WGS84 ist dafür schon eine gute Lösung. Vor allem wird es von den GPS-Geräten ausgespuckt. Die meiste Consumer-GEO-Software ist heutzutage WGS84-basiert. Die lokale Höhe sollte eher an der Benutzerschnittstelle berechnet werden, bei Eingabe oder Ausgabe. Beispielsweise könnte OSM bei eine ü.NN-Höhenangabe automatisch das WGS84-Datenfeld dazu anlegen.