Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Leute, können wir mal wieder zum Threadthema kommen?

Viele Grüße

Dietmar

Um auf den NRW-Atlas zurückzukommen: Seit 1.1.2011 wird ETRS89 als Basis verwendet. Die (veröffentlichten) Shape-Daten in BaWü und nach meiner Kenntnis auch in Bayern basieren auf Gauss-Krüger Zone 3 (bzw. GK4). Nach Transformation insbesondere zusammen mit der Feinkorrektur BeTA2007 stimmen die Stützpunkte der Grenzen bis auf Zentimeter überein. Das sollte für OSM reichen.
Maps4BW unterstützt mehrere Projektionen, mindestens eine davon ist Merkator, die Standardprojektion in JOSM, das gleiche gilt für den NRW-Atlas.
WGS84 ist übrigens ein sphärisches Koordinatensystem und ist von den nachgeschalteten Projektionen auf Ebenen (UTM, GK etc) nicht betroffen, diese aber sehr wohl von den Ellipsoid-Koordinaten darunter.
Ich hoffe, da kam jetzt NRW-Atlas oft genug vor :wink:

Das Problem ist nicht, dass die Höhenangaben falsch wären (die sind in sich meist korrekt), sondern dass bei ele=* völlig unklar ist auf welches Referenz-System sich diese Angaben beziehen.
Meiner Meinung nach wird das meist eine lokale Angabe sein, aber auch da weiß man nicht ob eine Höhenangabe bei einem Bahnhof nicht aus dem 19. Jahrhundert ggfs. noch aus der Länderbahnzeit stammt.

@seichter: Ballone und Flugzeuge waren mehr als Scherz gedacht.
Es gibt aber durchaus einen Hintergrund dafür: Einerseits Ballon-Festivals, andererseits Flugzeug-Parkplätze.

Edbert (EvanE)

An Dieser Stelle:
ETRS89 und Gauss-Krüger Zone 3 (oder eben 4) sind zwei völlig verschiedene Dinge. Beide gehen nicht konform und und es erfordert eine Transfomation.

Richtig, BeTA 2007 ist hinreichend genau.

Was man aber auch wissen und im Hinterkopf haben sollte: ETRS89 und WGS84 unterschiedliche Dinge aber doch nah verwand. Sie sind sogar sehr nah verwand. ETRS89 ist ein projiziertes Koordinatensystem, WGS84 ein geodätisches. Beide, also ETRS89 und WGS84 haben weitestgegend die gleichen geodätischen Grundlagen. Das ETRS89 ist mit dem Geoid GRS80 und Schwerefeldmessungen genauer definiert.

Da nun projizierte UTM- XY-Koordinaten mit der Basis GRS80 und solche mit der Basis WGS84 weitestgehend gleiche Basis haben, gibt es Unterschiede nur im Submeterbereich und diese sind für unsere Zwecke irelevant.

ETRS89 mit UTM-Abbildung (UTM-Zone 32 oder 33 ect. ) wird Standard in Europa, daran können müssen wir und jetzt schon gewöhnen.

Basis der Geodaten und deren Verwendung

Was man schauen muß: was ist die geographische Basis der Projektion. Beim der Merkator- Projektion (korrekterweise Pseudomerkator) was z.B. in JOSM als Standard verwendet wird, ist es WGS84 (Verwandschaftzu GRS80 s.o.) Daher werden reguläre Daten aus ETRS80 (UTM Zone 32 oder 33) in JOSM auch korrekt dargestellt (auch wenn eine nervige Fehlermeldung kommt; sollte mal bereinigt werden)

Fazit: solange man Vektordaten mit der aktuellen (sauber definierten) geographischen Basis verwendet, sollte es keine Probleme geben. Stehen wider erwarten doch noch Daten in Gauss-Krüger zur Verfügung, steht auch hier noch immer mein Angebot, die Daten mittels BeTA2007 nach ETRS89 zu kovertieren, wie ich es für das fränkisch-bayrische Freistaatkonglomerat ( :smiley: ) schon gemacht habe. Mail oder PN reicht. (http://forum.openstreetmap.org/viewtopic.php?id=19130&p=1.

Sven, der gerne versucht, Dinge so sauber und korrekt wie möglich definieren will :).

Hallo Sven,

Auch wenn wir immer mehr Off-topic werden, das ist so nicht ganz richtig.

ETRS89 und WGS84 sind beide geodätische Bezugssysteme. Beide verwenden den GRS80-Ellipsoid, unterscheiden sich jedoch in ihrer Festlegung. ETRS89 ist ein System für die Landesvermessung in Europa und daher an den europäischen Kontinent gebunden. Daher driften, wie ein paar Posts vorher erwähnt, die beiden Systeme nach und nach auseinander.

Die deutschen Vermessungsverwaltungen verwenden ETRS89 immer zusammen mit der Abbildung UTM. Geodätische Daten wie ETRS89, WGS84, Rauenberg/Potsdam und Pulkowo können mit verschienden Arten von Koordinaten verwendet werden:

  • geozentrische Koordinaten x, y, z mit Ursprung in der Mitte des verwendeten Ellipsoids

  • geographische Koordinaten (Länge und Breite) wie sie u.a. in der OSM-Datenbank gespeichert werden

  • abgebildete Koordinaten X, Y, z.B. Gauß-Krüger-Abbildung* und UTM. Bei beiden Verfahren wird das Ellipsoid auf einen Zylinder abgebildet. Diese abgebildeten zweidimensionalen Koordinaten sind dann winkeltreu (ganz wichtig für die Vermessung). Mit ihnen kann man dann sehr leicht vermessungstechnische Berechnung durchführen, da man nun ebene und keine spährische Geometrie mehr betreibt. Früher gab’s noch keine grafikfähigen, programmierbaren Taschenrechner. :slight_smile:

Alle deutschen Länder stellen um oder haben es schon. Baden-Württemberg, hinsichtlich der Umstellung auf ETRS89/UTM recht langsam, will 2016 fertig sein (Stand 02/2013).

Viele Grüße

Michael, der die Inhalte aus der Vorlesung Landesvermessung nicht so schnell vergisst, OSM-Forum und talk-de sei Dank :slight_smile:

*) Die Gauß-Krüger-System der deutschen Bundesländer haben unterschiedliche geodätische Daten. Im Westen wird das Bessel-Ellipsoid verwendet, der Osten verwendet(e) das Krassowski-Ellipsoid.

Doch schon. Per Definition ist ele=* in WGS84 und wer da etwas anderes einträgt macht eine falsche Angabe. Wie sollte man das sonst auch unterscheiden können? Der Computer kann die Intention des Mappers nicht riechen. Wenn die Werte aus dem lokalen System stammen muss man ele:local= oder ele:xyz= nehmen. Ich finde das durchaus vernünftig definiert. Da muss man sich eben nur dran halten.

p.s. da wir jetzt offenbar eine ununterscheidbare Mischung verschiedener Systeme haben müsste man dringend aufräumen.
Am einfachsten für die automatische Verarbeitung wäre es, wenn die Datenbank alles komplett in WGS84 speichert
und die Editoren andere Systeme automatisch dorthin konvertieren.

Wiki-Seite für NRW-Atlas?

Ich schlage mal vor, eine Wiki-Seite zum Thema NRW-Atlas anzulegen. Dort könnte man dann die vielfältigen Erkenntnisse dieses Theras einbringen:

Wo finde ich die Daten?
Darf ich die Daten wirklichlich verwenden?
Wie muß ich referenzieren?
Was enthalten die verschiedenen Layer?
Wie bekomme ich die Layer in Josm angezeigt?
Worauf muß ich achten?
Was sind das für Höhenangaben?

Gruß Klaus

Vorschlag kam bereits in Post #62

Die letzte Frage, worauf man achten sollte, braucht man IMHO nicht auf der Infoseite zu NRW beantworten. Da wir über kurz oder lang noch mehr Open-Data-Länder haben werden, sollte man im Wiki eine separate Seite mit “Hinweise zum Umgang mit deutschen Katasterdaten” anlegen. Diese könnte man dann von den einzelnen Länderseiten (MAPS4BW, NRW, Berlin, Hamburg) verlinken.

Es scheint die Mehrheitsmeinung hier zu sein, dass ele=568 sich auf WGS84 und ele:DHHN92=(passender Wert) auf DHHN92 bezieht. Diese Meinung sollte man auf der ele-Seite im Wiki hervorheben.

und auch andere gängige Höhensysteme listen und eventuell mit Link zu http://www.spatialreference.org/versehen.

Sven

Ich hab noch mal recheciert… Welche WGS84- Höhe? Geoid oder Spheroid. Beides ist definiert und mit Parametern hinterlegt. Bei meinen ArcGis hat das WGS84-Höhensystem folgende Kenn-Nummern:

WGS84 (Spheroid): 115700
WGS84 (Geoid): 105700

Hier einige WGS84-Systeme:

http://www.spatialreference.org/ref/sr-org/7428/ WGS84 Geoid
http://www.spatialreference.org/ref/epsg/4326/ WGS84, XY-Komponente des GPS
Weitere Spheroidische…
http://www.spatialreference.org/ref/epsg/4978/
http://www.spatialreference.org/ref/epsg/4979/
http://www.spatialreference.org/ref/epsg/4327/
http://www.spatialreference.org/ref/epsg/4328/
http://www.spatialreference.org/ref/epsg/4329/

Von daher bleibe ich bei meiner Aussage:

Es sei denn, auf der Wiki-Seite steht eindeutig, mit welchen Parametern (EPSG-Code) die einfache ele-Angabe definiert ist.

Da ja nicht Höhenangaben in der Masse wie Straßen- und Wegeeigenschaften erfasst werden, betrachte ich den vergleichsweise geringen Aufwand, gleich die korrekten Angaben zu machen als machbar. Eine verwendbare Doku im Wiki vorausgesetzt.

Sven (Verwirrung stiftend?)

Je nach Bundesland sind die Ausprägungen gegebenenfalls sehr unterschiedlich.
Zum Beipiel besteht Maps4BW aus genau einer Karte, während der NRW-Atlas aus einer Ansammlung vieler Karten mit unterschiedlichen Ausprägungen besteht.

Einige Unterschiede seien exemplarisch genannt:

  • Maps4BW hat eine schlechtere Auflösung als die ALK vom NRW-Archiv
  • Maps4BW stellt etliche topographische Merkmale wie Böschungen
    überhaupt nicht dar, die in der DGK5 des NRW-Atlas enthalten sind.
  • Es ist natürlich einfacher wie bei Maps4BW nur eine Karte als
    Hintergrund zu benutzen, statt sch aus dem NRW-Atlas die passenden
    Karten/Layer zusammen suchen zu müssen.

Als Fazit gibt es vieles, was beim NRW-Atlas zu beachten ist (z.B. Höhenangaben), das bei Maps4BW jedoch überhaupt nicht auftaucht. Eine einheitliche Beschreibung ist zwischen den beiden nicht möglich.

Einspruch, das Wiki fordert zwar seit 2009, dass Werte in ele=* der WGS84-Höhenrefenrenz entsprechen sollen.
Genauso lange wird diese Forderung von den Mappern nicht wahrgenommen oder schlicht ignoriert.

Das was wirklich in ele=* steht, sind praktisch ausschließlich lokale Höhenangaben, von einem Schild, einem Wegweiser oder aus der Wikipedia / einer Karte / einem Buch entnommen.

Edbert (EvanE)

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.