You are not logged in.

#151 2013-10-29 07:09:08

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

EvanE wrote:

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.

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.

Last edited by openzzz (2013-10-29 07:13:41)

Offline

#152 2013-10-29 08:36:26

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,247
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

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

Offline

#153 2013-10-29 16:16:28

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

toc-rox wrote:

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

Vorschlag kam bereits in Post #62

Offline

#154 2013-10-29 17:23:14

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,946
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

toc-rox wrote:

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?

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.

toc-rox wrote:

Was sind das für Höhenangaben?

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.


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#155 2013-10-29 17:28:32

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,283
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:

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

Offline

#156 2013-10-29 18:57:35

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,283
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:

Es scheint die Mehrheitsmeinung hier zu sein, dass ele=568 sich auf WGS84

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:

streckenkundler wrote:

Bei den Höhenangaben ist die Angabe des Höhenbezugssystems zwingend erforderlich. Höhenangaben ohne Angabe des Bezussystems sind weitestgehend wertlos.

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?)

Offline

#157 2013-10-29 19:25:28

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:

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.

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.


Nakaner wrote:
toc-rox wrote:

Was sind das für Höhenangaben?

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.

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)

Offline

#158 2013-10-29 19:39:20

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: 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/Bun … __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)

Offline

#159 2013-10-29 20:37:21

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

EvanE wrote:
Nakaner wrote:
toc-rox wrote:

Was sind das für Höhenangaben?

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.

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)

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.

Offline

#160 2013-10-29 20:56:09

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

streckenkundler wrote:

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:
...
Sven (Verwirrung stiftend?)

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.

Offline

#161 2013-10-29 21:22:18

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

openzzz wrote:

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.

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?

Offline

#162 2013-10-29 21:52:09

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nahmd,

Doch schon. Per Definition ist ele=* in WGS84 und wer da etwas anderes einträgt macht eine falsche Angabe.

Geht an der Realität vorbei.

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?

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

Offline

#163 2013-10-29 22:17:21

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Netzwolf wrote:

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

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)

Offline

#164 2013-10-29 22:32:25

Nop
Moderator
Registered: 2009-01-26
Posts: 2,723

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

seichter wrote:

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.

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


Nothing is too difficult for the man who does not have to do it himself...
Projekte: Reit- und Wanderkarte mit Navigation - Kartengenerator Map Composer - GPS Track Editor Track Guru

Offline

#165 2013-10-29 23:04:03

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

EvanE wrote:

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.

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.

Offline

#166 2013-10-29 23:05:49

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,946
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

EvanE wrote:
Nakaner wrote:

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.

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.

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.

openzzz wrote:

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

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.

openzzz wrote:

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


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#167 2013-10-29 23:26:19

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

seichter wrote:

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.

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.

Offline

#168 2013-10-29 23:29:24

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,946
Website

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

openzzz wrote:

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?

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


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#169 2013-10-29 23:33:48

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,946
Website

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

Last edited by Nakaner (2013-10-29 23:35:22)


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#170 2013-10-29 23:38:48

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:

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.

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.

Offline

#171 2013-10-29 23:40:57

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:

Bedenke bitte, dass es Länder gibt, in denen es mehr als ein Höhenbezugssystem gibt. Wir haben in der Deutschland derzeit drei:

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.

Nakaner wrote:

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.

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/Shared … poster.jpg. Eine Maschenweite etwa auf Kreisgröße müsste ausreichen, dichter sind die Korrekturpunkte in den GPS-Geräten ziemlich sicher auch nicht.

Offline

#172 2013-10-29 23:43:59

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:
openzzz wrote:

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?

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

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.

Offline

#173 2013-10-29 23:52:37

seichter
Member
Registered: 2011-05-21
Posts: 3,094

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

openzzz wrote:

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.

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?

Offline

#174 2013-10-30 00:17:21

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nahmd,

openzzz wrote:

Die Auffassung, jeder Kamikaze-Mapper macht das was er will, egal welches Koordinatensystem, finde ich ziemlich dilletantissimo.

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.

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?

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

Offline

#175 2013-10-30 00:20:41

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Nakaner wrote:
EvanE wrote:
Nakaner wrote:

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.

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

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.

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.

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.


Nakaner wrote:

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.

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.


Nakaner wrote:
openzzz wrote:

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), ... wurde/wird in den alten Bundesländern verwendet

  • SNN76 (Staatliches Nivellementnetz 1976), ... 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, ...

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.

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)

Offline

Board footer

Powered by FluxBB