Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Genauere Höhenangaben scheinen mit Nutzung von NRW-Atlas oder anderer vergleichbarer “OpenData”-Quellen inzwischen an Bedeutung zu gewinnen.
Da kann ich mir die Bemerkung nicht verkneifen, dass sich die Festlegung im Wiki, dass die Höhenangaben in OSM im WGS84-System angegeben werden, sich zwar gut anhört, aber etwas blauäugig ist.

WGS84 ist ein rein geometrisch definiertes System (Referenzellipsoid), das sich nicht auf den Meeresspiegel bezieht. Die Vermessungsdienste werden das vermutlich auch in hundert Jahren nicht für die Höhe verwenden, weil nicht nur der Meeresspiegel nicht stimmt (wäre noch verschmerzbar), sondern auch die Waagrechte und Senkrechte zwar nur gering, aber messbar abweichen. Deswegen gibt es überall (natürlich auch in NRW) Referenzgeoide, die den hypothetischen Meeresspiegel nachbilden http://www.bkg.bund.de/nn_175526/DE/Bundesamt/Geodaesie/RefSys/RefHoehe/Hoehe__node.html__nnn=true. Da spielt sogar die unregelmäßige Massenverteilung eine Rolle. Fakt ist: Die Höhen zwischen diesem lokalen Geoid und WGS84 weichen in D um 34 m (Ostsee) bis 50 m (Alpen) ab.

Ich wag mal zu behaupten, dass fast alle Nutzer von OSM (alle außer den an dieser Diskussion beteiligten), wenn sie auf eine Angabe ele=450 stoßen, auf der Tafel aber 410 m steht, sagen werden: OSM ist falsch.

Deshalb plädiere ich dafür, wenn schon die reine OSM-Lehre für ele angewendet wird, dass dann wenigstens die lokale Höhe obligatorisch auch angegeben wird, ob als ele:local oder ele:DHHN92 wäre mir egal. Das hätte ich gerne in einem Wiki zum NRW-Atlas stehen, am liebsten sogar im englischen zum Tag ele.

Jedes halbwegs ernst zu nehmende GPS-Gerät hat die Korrektur der Höhenwerte als Tabelle im Speicher, bei einer Toleranz von 1 m brauchen die Stützpunkte in Länge und Breite nicht all zu dicht zu liegen. Üblicherweise wird auf die lokale Höhe korrigiert, denn alles andere führt nur zu Irritationen. Bösartig könnte ich fragen: Welche WGS84-Höhe ist im Wiki denn gemeint, die echte, unkorrigierte (die nicht angezeigt wird) oder die korrigierte (die angezeigt wird)? (siehe auch Streckenkundler)

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.

Gute Frage. Die Verwirrung ist die Wiki-Seite schuld. Das müsste in der Tat erst sauber definiert werden.

Gibt es bei OSM kein Gremium, dass sich um Definitionen kümmert?
Jedes professionelle Datenbankprojekt definiert erstmal ordentlich den Typ und die Bedeutung
der Datenfelder bevor die Datenbank mit Daten gefüttert wird.

Nun, wie wird es bei NMEA 0183 gemacht:
die GPS-Datensätze GP* verwenden WGS84 mit dem WGS84 Geoid. In der GPGGA-sentence steht die “Höhe über Geoid”. Zusätzlich wird noch ein Datenfeld “geoidal separation” übertragen, der lokalen Differenz von Geoidhöhe und Spheroid/Ellipsoid-Höhe.
Eigentlich eine sehr vernünftige Definition - könnte man in OSM übernehmen.
Ich hatte aber nun öfters gehört, dass manche GPS-Receiver sich nicht daran halten, einige die
Geoidkorrektur machen und andere nicht (wo die Software dann nachträglich korrigieren muss).
Die WGS84-Geoidkorrektur muss über eine Tabelle erfolgen (Schwerefeldform der Erde) - eine einfache
Formel dazu gibt es nicht.

Die OSM-Community müsste sich da mal dransetzen, eine wirklich eindeutige Definition zu schaffen.

Die GPS-Geräte spucken gerade nicht die WGS-basierte Höhe aus, sondern im Normalfall den auf das lokale Geoid korrigierten Wert.
Ob jetzt der lokale oder der WGS-Höhenwert als Default definiert ist/wird, soll mir egal sein. Im Lichte dieser Diskussion scheint es mir aber fast unvermeidlich, möglichst beide Werte anzugeben. Otto Normalnutzer und auch Otto Normalmapper kennt den Korrekturwert für seine Gegend üblicherweise nicht.

Den Vorschlag, ein allgemeines Wiki für “zur Nutzung freigegebene Daten der Vermessungsbehörden” wie NRW-Atlas oder Maps4BW zu erstellen, finde ich sehr sinnvoll und ich erkläre mich auch bereit, daran mitzuarbeiten. Da könnten dann auch die Korrekturwerte tabellarisch (Regionen dürften reichen) aufgeführt werden (das sind übrigens gerade die “geoidal separation”-Werte in den NMEA-Datensätzen).

Eine Frage: Eine Angabe der Art ele=410(+30) mit der Bedeutung: “WGS-Höhe=410 mit Korrektur +30 gibt lokale Höhe 440” wäre kürzer als
ele=410 & ele:DHHN92=440, wäre sie aber auch vernünftig auswertbar?

Nahmd,

Geht an der Realität vorbei.

Wer soll das eingeben?

Der Normalnutzer™ sieht eine Höhenangabe an einem Wegweiser, einem Bahnhof oder einer Hütte und trägt den Wert ein. Als “ele=”, wo auch sonst? Er wird nicht im Wiki nachschlagen, ebensowenig wie er “name=” bei einer Straße oder “maxspeed=30” nachschauen wird, einfach deshalb, weil es kein offensichtliches Problem gibt: Höhen sind trivial. Für den normalen Nutzer.

Also: lasst den Benutzer unter “ele=*” das eintragen, was er vorfindet.

Und packt die wohldefinierten Werte unter “ele:Bezugssystem” oder vergleichbar. Ich würde für das kanonische Bezugsystem ein “ele_wgs84” nutzen statt einer Namensraumkonstruktion, um das Besondere dieses Wertes zu kennzeichnen, das ist aber reine Geschmackssache.

Daraus lässt sich maschinell ein “ele_local” erstellen. Und der Otto-Normalrenderer wird zuerst ele_local verwenden, dann (optional wenn Wert und Software vorhanden sind) ele_wgs84 umrechnen, und zuletzt “ele”.

So sind Erfasser, Datennutzer und die Vermessungsexperten zufrieden.

Ihr könnt auch viel Aufwand in die Definition von Erfassungsregeln stecken und die in vielen Sprachen im Wiki dokumentieren. Wird der Normalerfasser nicht lesen.

Gruß Wolf

Hallo Wolf

Ob der realen Situation kann ich dir leider nur zustimmen.

In den deutschen Map_Features steht zu ele der Satz:
"Höhe in Metern über Normal Null (bezogen auf WGS 84) "
Gibt es überhaupt ein Normal Null bei WGS 84?
Mir scheint der zitierte Satz ein Widerspruch in sich selbst zu sein.

Edbert (EvanE)

Sehe ich ganz genauso.

Ein Indiz dafür ist, daß seit über 4 Jahren die Inhalte von ele als unverändert als m über NN für Berge und Pässe auf meiner Karte angezeigt werden. In all der Zeit gab es nicht eine einzige Rückmeldung über falsche Höhen. :slight_smile:

bye, Nop

Richtig: Höhe in WGS84 bezieht sich auf ein fiktives Ellipsoid, das weltweit so gewählt wurde, dass die Abweichung von Normal Null global möglichst gering ist.
Höhe über (lokalem) NN ist WGS-Höhe - Korrektur aus Tabelle.

Fazit bisher für mich: ele=* als alleiniger Eintrag mit WGS-Höhe ist realitätsfern und irritierend.

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.

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

Auch wenn die Vermessungsverwaltung schon umgestellt hat, kursieren die Angaben in den alten Systemen noch recht lange. Schließlich lösen sich all die Kartenblätter und Höhentafeln an Wanderwegen nicht mit der Umstellung in Luft auf. Daher ist eine Definition des ele-Tags als Höhe im ortsüblichen System ähnlich unbrauchbar wie eine Angabe ohne Bezugssytem.

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. :slight_smile:

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.

Doch, das ist die WGS84-Höhe über Geoid. WGS84 definiert die Höhe über dem EGM96-Geoid.
Das spucken einfache GPS-Geräte üblicherweise aus (die teureren Garmins mit barometrischem
Höhenmesser sind vermutlich umschaltbar).

Wie der Unterschied nun zum nationalen DHHN92 aus dem NRW-Atlas ist, keine Ahnung.
Der ist ja an einen Referenzpunkt in Wallenhorst bei Osnabrück fixiert.
Haben wir Geodäten in der Runde die sich damit auskennen?

Die Auffassung, jeder Kamikaze-Mapper macht das was er will, egal welches Koordinatensystem,
finde ich ziemlich dilletantissimo. Man kann ja ruhig definieren, dass ohne Systemangabe das lokale System
gelten soll. Aber das muss man wirklich klar definieren und nicht jedem Mapper nach seinem persönlichem
Geschmack überlassen. Aktuell steht da im Wiki WGS84 - das ist doch jetzt die Stelle wo es definiert wird, oder?
Seid froh, dass bei den 2D-Koordinaten wenigstens Einigkeit und Konsistenz herrscht.
Oder soll ich die Strände vom letzten Urlaub in Frankreich jetzt nach Lambert-Koordinaten mappen?
Meine alte Frankreichkarte hat noch kein WGS84.

Auf jedem Fall wäre im Wiki eine Angabe wichtig, ob die WGS84 Geoid- oder elliptische Höhe gemeint ist.

Hier, ich! Bin zwar noch Student, aber im 5. Semester.

Ich habe jetzt mal eine Seite im Wiki in meinem Userspace angelegt, wo wir allgemeine Hinweise zur Nutzung von Katasterdaten sammeln können. Jeder von euch ist eingeladen, sich dort einzubringen!

Wenn die Seite fertig ist, kann man sie aus meinem Userspace herausschieben und von den Infoseiten (Maps4BW & Co.) aus verlinken.

Wer legt eine Seite für NRW an?

EDIT: Die Seite mit Hinweisen zur Nutzung von Katasterdaten soll Informationen sammeln, die nicht nur für NRW gelten, sondern auch für Baden-Württemberg, Berlin, Hamburg usw.

Ich halte es auch für sinnvoll, die Datenbank auf WGS84 zu vereinheitlichen, damit es automatisch verarbeitbar ist.
Aber für die Kartenansicht würde ich die Höhe über NHN bevorzugen. Dort werden Bergspitzen mit der Höhe beschriftet.
Der Renderer müsste für den Fall WGS84 → NHN umrechnen.

Gerade habe ich mal die Tags geprüft. Ein ele=… Tag wird direkt auf den Gipfel beschriftet.
Laut definition würde die Karte dann WGS84 Höhen zeigen. Aber man sieht, dass die Mapper doch
die NHN-Höhe aus Wikipedia genommen haben. In dem Sinne ist die Beschriftung dann
(in meinen Augen) wunschgemäß, nur eben widersprüchlich in der Definition der Tags.

Ist halb so wild, der Unterschied beträgt nur bis zu 15 cm. Das ist für OSM mMn irrelevant.
Ein (scheinbarer) Fehler von 40 m stört mich da weit mehr.

Die käuflichen Daten erlauben eine Korrektur bis in den Zentimeter-Bereich. Wenn man sich mit etwa einen Meter Genauigkeit zufrieden gibt, bekommt man für D von Ostsee bis Schwarzwald 17 Stufen http://www.bkg.bund.de/nn_193464/SharedDocs/Bilder/Bilder-Geodaesie/RefH-Quasigeoidhoehen-de,property=poster.jpg. Eine Maschenweite etwa auf Kreisgröße müsste ausreichen, dichter sind die Korrekturpunkte in den GPS-Geräten ziemlich sicher auch nicht.

Ok, denn müsstest du die Frage ja beantworten können.
Unterschied zw. WGS84 Geoid-Höhe und DHHN92-Höhe?

Vielleicht sind das ja nur ein paar cm, so dass wir uns unnötigerweise Sorgen machen.
Dann würde eine Definition “WGS84-Geoid-Höhe” für die ele-Tags noch ungefähr
zu den lokalen Angaben passen.

Die Unterschiede der Geoide kann man für OSM mMn getrost vernachlässigen.
Natürlich muss für den Auswerter eindeutig definiert werden, was ein ele=* bedeutet. Im Moment stehen sich nur die Aussage im Wiki und die Mapping-Praxis zu 99% (oder mehr) diametral gegenüber.
Eine ketzerische Frage: Was lässt sich leichter ändern?

Nahmd,

Das ist eine bösartige Beleidigung der Tausende Mitstreiter, die seit Jahren Daten zusammentragen, und all der Verwalter der Karten und Tools, die bereits im täglichen Einsatz sind. Besser Daten, die hinreichend gut sind und existieren, als perfekte Daten, die nicht existieren.

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie.

Definiert wird es durch das, was die Datenerfasser eintragen. Und wenn fast alle lokale Höhenangaben eintragen, dann stehen fast nur lokale Höhenangaben in der Datenbank. So einfach ist das. Und das Wiki muss angepasst werden. Dookratie at its best. Raus mit dem weltfremden WGS84-Quatsch aus dem Wiki und stattdessen “ortsübliche Höhenangaben”. Das “ortsüblich” genauer zu definieren, bringt nix: der Hüttenwirt kann mir nicht sagen, auf welches System sich die Höhenangabe auf der 90 Jahre alten Holztafel bezieht. Und zwischen den Höhenangaben auf meinen über 100 Jahren alten Karten und den heutigen liegen vielleicht mal 10 Meter, ein Wert, der in der Praxis nicht interessiert. Und – ich formuliere mal flapsig – ob man sich auf Nordsee, Ostsee, oder Adria bezieht, macht schlimmstenfalls mal nen Meter aus. Who cares?

Nicht falsch verstehen: natürlich ist das alles sehr schwammig jetzt, und es spricht nichts dagegen, das ganze auf eine saubere Grundlage zu stellen. Aber bitte: mit einem neuen Tag. “ele_wgs84” oder was auch immer. Egal wie ihr das “ele=*” definieren wollt: da werden weiterhin täglich die vor Ort vorgefundenen Daten eingetragen. Und das ist auch gut so, denn nur deshalb haben bereits jetzt unsere Berge und Pässe Höhenangaben.

Die Vorstellung, dass ein paar Heinzl aus dem deutschen Forum da irgendetwas vorschreiben und die zigtausendfach bewährte Methode der Erfassung “irgendwie definierter Höhen” verbieten könnten, ist absurd.

Die korrekte Vorgehensweise wäre: definiert einen neuen Schlüssel “ele_wgs84”. Dann setzt dieses Tag für möglichst viele OSM-Objekte. Wie ihr an die Daten kommt? Keine Ahnung. Und wenn (größenordnungsmäßig) ähnlich viele Objekte mit “ele_wgs84” getaggt sind wie mit “ele”, und wenn ihr die Übersetzungsproblematik geklärt habt, und wenn ihr die implementierten Algorithmen und die zugehörigen Parameter dern Datennutzern bereitstellen könnt, dann, ja dann kann man beginnen, eine Umstellung zu diskutieren.

Visionen alleine sind zu wenig.

Gruß Wolf

Und schon sind wir wieder bei einem Unterschied.
Die Waldwege für Maps4BW stammen nach meiner Erinnerung von der Forstverwaltung, die ein Interesse hat, ihre alten Rückewege auch in Zukunft benutzen zu können und gleichzeitig wenig Interesse hat, die Waldwege ständig zu aktualisieren.
Beim NRW-Atlas stammen die Daten zu den Waldwegen meines Wissens nach von der Geoverwaltung und sind zumindest in meinem Gebiet recht aktuell.

Die Problematik “Wie aktuell sind die Daten?” und “Wie sind Gebäude eingetragen?” besteht natürlich überall. Schließlich gibt es bei jedem Kartenwerk einen Stichtag, nach dem keine Änderungen mehr einfließen. Aber die Gebäude-Erfassung scheint je Land einheitlich zu sein, bzw. es gibt einen Wechsel Dach → Mauerwerk oder eben nicht.

Also nichts gegen eine Übersichtsseite mit allgemeiner Erwähnung möglicher Probleme. Aber die Ausprägung sind je Land unterschiedlich und daher sollte Problem bei den Ländern besprochen werden, wo sie wirklich auftreten.

Die Probleme sind sicher überall gleich, wenn auch die Ausmaße unterschiedlich sind. Bei Maps4BW haben wir anscheinend nur die üblichen Höhenangaben für Berge, beim NRW-Atlas, genauer deren DGK5 haben wir sehr viel mehr Höhenangaben.

Ich bin übrigens dagegen Problembeschreibungen auszulagern, dann werden sie noch weniger beachtet, als sowieso schon. Auf einer Übersichtsseite für alle Bundesländer kann / soll man die Probleme durchaus ansprechen, aber dort wo sie verstärkt auftreten, sollte man sie gezielt zum Thema machen.

Durch Redundanz, findet man die Problembeschreibung dort, wo sie tatsächlich existieren und nicht in eiorgendeinem verlinkten Dokument, das man dann auch noch grne übersieht, weil einem das Stichwort nichts sagt.
Keine / wenig Redundanz ist kein Wert an sich, sondern für strukturierte Datenbanken eine Arbeitserleichterung. Die Benutzung der Daten wird durch die Notwendigkeit, sich all die vielen Redundaanz-Schnippsel zusammen suchen zu müssen, hingegen sehr viel aufwändiger.

20 Jahre nach der Umstellung solten alle aktuellen Kartenwerke auf dem ‘neuen’ System beruhen.
In den alten Bundesländern ist der Unterschied zwischen DHHN92 und DHHN12 zudem so gering, dass bei den Höhenangaben mit 0.1m Genauigkeit dies nur sehr selten zum tragen käme. Und selbst wenn, die paar Ausreißer (mit +/- 0.1m) tun uns bei der neuen Datenfülle überhaupt nicht weh.

Bitte teil uns doch mit, welche Bundesländer wann auf DHHN92 umgestellt haben und welche ggfs. noch nicht. Ohne diese Information ist deine obige Aussage nur FUD (bitte im EDV-Lexikon nachschlagen).

Edbert (EvanE)

Hallo Wolf

Danke, du hast meinen Abend gerettet.
PS: Hervorhebung von mir.

Und jetzt will ich endlich Mappen!
Edbert (EvanE)

Für Karten ist die Definition des Koordinatensystems so ziemlich das Elementarste überhaupt.
Da kann man nicht schlampen. Wie gesagt, die Karte sähe ziemlich schrottig aus, wenn man in
Frankreich die “ortsüblichen” Lambert-Koordinaten benutzen würde.
So weltfremd finde ich WGS84 gar nicht. Das ist die Basis der meisten GEO-Anwendungen.
Das spucken die GPS-Geräte aus (NMEA-Felder), Google KML nutzt es. UTM-Karten nicht,
aber wer trägt schon Easting-Norting statt Longitude/Latitude in OSM ein?
UTM wird regulär in WGS84 umgerechnet.

Derzeit sind ele-Tags als WGS84, ele:local als lokale NHN definiert. Wer’s genau nimmt
kann mit ele:xyz das System konkret angeben. Wo ist das Problem? Ist doch sauber definiert.

Wenn du mit der OSM-Regelung nicht einverstanden bist müsstest du das auf Gesamtprojektebene
ansprechen. Das muss für OSM einheitlich sein.

Es wäre den App-Programmierern, z.B. von OsmAnd, nicht zuzumuten die ganzen regionalen
Vorlieben zu berücksichtigen. Oder für den Renderer, der die Berghöhen einzeichnet.
Wer Geodaten verarbeitet, muss sich auf eine klar definierte Datengrundlage verlassen können.