Ich habe eigentlich eher an folgende allgemeinere Hinweise gedacht:
-
Gebäudebestand im Kataster und den daraus abgeleiteten Produkten (DGK5, Maps4BW) ist nicht top-aktuell.
-
Bei Gebäuden ist im Kataster in Westdeutschland und in Ostdeutschland bei Gebäuden, die nach der Wende entstanden sind, das “aufsteigende Mauerwerk” eingetragen und nicht der Dachvorsprung.
-
Im Wald sind die amtlichen Daten nicht besonders aktuell.
-
usw.
Die Höhenproblematik haben wir derzeit nur in NRW. Wenn aber noch weitere Ländern dem Vorbild NRW folgen, brauchen wir die Infos zu Höhen(bezugssystemen) nicht redundant ablegen.
Man könnte natürlich auch grundsätzlich die lokale Höhe als Default für das ele-Tag definieren.
Bedenke bitte, dass es Länder gibt, in denen es mehr als ein Höhenbezugssystem gibt. Wir haben in der Deutschland derzeit drei:
-
DHHN12 (Deutsches Haupthöhennetz 1912), auch unter der Bezeichnung Normal-Null (NN) bekannt, Bezugspegel Amsterdam, wurde/wird in den alten Bundesländern verwendet
-
SNN76 (Staatliches Nivellementnetz 1976), auch unter der Bezeichnung Höhen-Null (HN) bekannt, Bezugspegel Kronstadt/Ostsee, wurde/wird in den neuen Bundesländern verwendet
-
DHHN92 löst die beiden ab. Manche Länder (z.B. Sachsen-Anhalt und Baden-Württemberg) haben schon umgestellt, Bezugspegel Amsterdam
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.
Dazu mal die Frage in den Raum gestellt: Gibt es eine Tabelle mit den Geoidundulationen (d.h. Abstand WGS84-Ellipsoid zu DHHN12/DHHN92/SN76) unter einer freien Lizenz? Welche Maschenweite/Gitterweite und welche Genauigkeit hat diese? Die Vermessungsverwaltungen bieten solche Tabellen zum Kauf an.
Man sollte daher in den Editoren für die Höhenangebe eine Vorlage einbauen, bei der man eingeben kann, welches Bezugssystem die Höhe hat. Gibt der Benutzer WGS84 als Bezugssytem an, wird seine Höhe im ele-Tag gespeichert. Gibt er DHHN92 ein, landet die Höhe in ele:DHHN92. Gibt er gar nichts oder “unbekannt” ein, landet die Höhe in ele:unknown und jeder Datennutzer kann diese Angaben einfach herausfiltern. Die Editoren sollten dann aber auch einen Link zu einer allgemeinverständlichen Erläuterung des Höhenproblems (Unterschied ellipsoidischer Höhe–Gebrauchshöhe) bieten oder ele-Tags nicht in die OSM-DB hochladen.
Die Datennutzungssoftware (oder die Importtools für die Datenbaken, z.B. osm2pgsql), sollten fähig sein, ellipsoidische Höhen anhand einer Lookup-Tabelle in Gebrauchshöhen umzuwandeln. Auf osm.org sollte man IMHO die Anzeige von Höheninformationen abschalten oder immer als “435 (WGS84)” ausgeben, damit weniger Leute für den Renderer taggen.