Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

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

Da ich mich nur ungern wiederhole :roll_eyes:
Und wie das unsere irischen Freunde 2009 bei einem Import gelöst haben, könnt ihr hier am Croagh Patrick sehen. Da die dem Wiki-Braten wohl auch nicht trauten, haben sie ele=* und ele:wgs84 =* sowie einige andere ele mit drauf gepackt, und so kann sich jede Auswertung nach Belieben bedienen.

Doch nun noch ein Vorschlag für die Zweifler an der richtigen Verwendung der wgs84-Höhe als Standard elends-value:
Statt hier weiter im Kreis und (zumindest teilweise OT) zu diskutieren, könnte doch mal jeder per overpass oder sonstwie die ele seiner Gegend suchen, kontrollieren und berichtigen. Da ich in dieser Diskussion einen Trend hin zu wgs84 als Standardhöhe sehe, was ja der wie auch immer zustande gekommenen Jahre alten Wiki-Definition entspräche, kann ja jeder die gefundenen ele entsprechend kennzeichnen:
ele:unknown=* >>(Höhensystem der Angabe unbekannt)
ele=* >>(wgs84-Höhe verifiziert
ele:= >>(whatever you want)

Wir könnten die Höhendiskussion auch hier fortsetzen: http://forum.openstreetmap.org/viewtopic.php?id=21009 http://forum.openstreetmap.org/viewtopic.php?id=18946 http://forum.openstreetmap.org/viewtopic.php?id=17034

Ich schlage vor, wir berücksichtigen alle drei Bestandteile des WGS84, ignorieren auch nicht das Kapitel 6 der Definition (PDF 1MB) (mehr amtliche Definition geht nicht…), und tragen die Höhe über dem Geoid ein. Wer das Wiki ändert, sollte auch gleich das erste Beispiel (Breithorn) ändern. Die dort angegebene Höhe ist eine über Meer.

Grüße, Max

Den Trend sehe ich so nicht … vielmehr sollte zusammen mit der Höhe in einem zusätzlichen Tag das Bezugssystem erfaßt werden. Desweiteren schließe ich mich maxbe an und schlage die Verlagerung der Diskussion in den genannten Thread vor.

Gruß Klaus

+1

Edit: wegen off topic gelöscht.

+1

Und die Berge hast du auch alle bestiegen und die Schilder abgelesen?
Oder Couch-Surfing und von der Wikipedia abgepinselt?

Nein, ich will da kein System zerschlagen, nur bevor ich irgendwelche Daten erfasse informiere ich wie die Felder definiert sind. Das sollte eigentlich jeder Mapper bevor er loslegt. Ich hatte für meine eigenen Projekte auch schon viele Datenstrukturen definiert. Da ist dann Selbstdisziplin erforderlich, auch wenn man später nicht immer glücklich mit seinen Entscheidungen ist. Ich habe auch schon Definitionen geändert. Das bedeutet dann aber, dass der komplette Datenbestand konvertiert werden muss, Programme umgeschrieben werden müssen etc. Darum macht man das ungern und eher selten. Am elegantesten ist es, von vorneherein sich gründlich Gedanken zu machen, um nachher nichts mehr umdefinieren zu müssen. Aber so wie hier, dass man jahrelang gegen eigene Regel verstößt hatte ich noch nie erlebt. Hast du noch nicht in großen Industrieprojekten gearbeitet, wo das ganze direkte monetäre Konsequenzen hat?

Ob das nun ein 3-er Satz an Koordinaten ist oder die Höhe separat ausgezeichnet wird, spielt doch keine Rolle ob man sauber definiert oder nicht. Sicherlich ist OSM ein zweidimensionales Modell und die Höhe nicht so sehr relevant.

Also ich verstehe, du willst die Bedeutung des ele-Tags umdefinieren (WGS84 → NHN / ü. NN). Wir können das gerne für OSM ganzheitlich durchsetzen. Aber da müssen wir wirklich erstmal an die Defintion ran, dass man sich auf eine internationale gemeinsame Grundlage stellt. Deutsche Sonderwege sind doch sinnlos.

Meine Frage zum Unterschied WGS84-Geoid-Höhe und DHHN92-Höhe ist noch nicht beantwortet worden. Ich finde die Meinung von Experten auch wichtig, also Geodäten die sich mit den Höhensystemen auskennen. Womöglich ist der Unterschied zwischen der WGS84-eigenen Geoidhöhe und den nationalen Systemen gar nicht so groß, so dass eine Definition ele = WGS84-Geoidhöhe relativ konsistent zum Datenbestand wäre. Dann müsste man nur dazuschreiben, dass die Geoid-Höhe gemeint war. NMEA gibt ja auch in erster Linie im Höhenfeld die Geoidhöhe an und liefert den Korrekturwert gleich mit.

Außerdem, wieso “elevation”? Ich kenne es in Geodaten nur als “altitude”. Elevation ist für mich ein Höhenwinkel.
Ich hatte schon gelesen, dass man das evtl. umdefinieren wollte, mit einem alt-Tag.
Eigentlich eine gute Gelegenheit dazu. Ich werds mal auf der OSM-Liste ansprechen.