Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

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.

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.

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.

Die 92 steht dafür, dass die letzten Nivellements (Höhenmessungen) in den Jahren 1990-92 durchgeführt worden sind. Der Beschluss zur Einführung wurde 1993 gefasst. 1994 fand die Ausgleichung statt. Siehe auch http://www.pfiff.nrw.de/hilfe/dok/pi_normalhoehen.pdf Die meisten Ländern haben DHHN92 erst in den 2000er-Jahren für ihr Höhenfestpunktfeld eingeführt.

Laut meiner Google-Recherche sind die Höhenfestpunktfelder in folgenden Ländern umgestellt: Thüringen, Bayern, Baden-Württemberg, Saarland, NRW, Schleswig-Holstein, Mecklenburg-Vorpommern, Sachsen-Anhalt, Brandenburg, Berlin, Sachsen. Bei den anderen habe ich auf die Schnelle nichts zur Umstellung gefunden.

Und wie gesagt - die eigenmächtige und undiskutierte Änderung eines einzelnen Mappers damals ist in meinen Augen keine Definition. Ganz besonders wenn sie in der Praxis fast komplett ignoriert wurde.

bye, Nop

Also du meinst das hier definiert nicht den ele-Tag?

http://wiki.openstreetmap.org/wiki/Key:ele

Und was sonst? Ist der undefiniert? Macht jeder was er will?
Dann sollte das mal zentral für OSM abgestimmt werden.

Ich meine daß auf dieser Seite ein einzelner Mapper ohne vorherige Diskussion oder Unterstützung von mehr als seiner eigenen Meinung die bestehende Definition “m über NN” auf eine Aussage geändert hat, die völlig an der Realität vorbei geht. Und damit Chaos und Unsicherheit erzeugt hat.

Um es als Definition zu akzeptieren müßte es für mich entweder

• die bis dato bestehende Definition kompatibel ergänzen anstatt sie zu invalidieren und
• die reale Mappingpraxis wiedergeben
• oder durch eine Diskussion und zumindest den Hauch einer Mehrheitsentscheidung mit mehr als einer Einzelmeinung belegt sein

Den jetzigen Zustand bezeichne ich als groben Fehler, nicht als Definition.

Und ja, leider ist es so daß bei OSM jeder macht was er grad lustig ist - und es kommt leider des öfteren vor, daß ein Einzelner völligen Blödsinn ins Wiki einträgt. Normalerweise wird das gleich wieder rückgängig gemacht. Aber wenn niemand aufgepaßt hat und das gleich wieder rausschmeißt, sieht es dann Jahre später so aus als wäre das “Gesetz”.

In diesem Fall hat einfach niemand hingeschaut. Wozu auch, jedem unbedarften oder pragmatischen Mapper ist intuitiv klar daß man das mappt was in der Realität zu sehen ist. Und das ist auf Schildern in Deutschland m über NN.

bye, Nop