Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

DD1GJ wrote:

Einen herzlichen Dank an die Bezirksregierung Köln für die äußerst unbürokratische und großzügige Nutzungserlaubnis und an Gregor, der den Stein ins Rollen gebracht hat.

... und an dich, weil du so erfolgreich Briefe an Ämter schreibst.
Max

DD1GJ wrote:

...
Einen herzlichen Dank an die Bezirksregierung Köln für die äußerst unbürokratische und großzügige Nutzungserlaubnis und an Gregor, der den Stein ins Rollen gebracht hat.

Viel Spaß
Joachim

Dem kann ich mich nur anschließen, denn endlich bin ich in der Lage meinen 450 km entfernten Geburtsort auf dem Sofa zu vervollständigen, indem ich das Wissen von den Besuchen bei meinem Vater mit den Fakten aus dem NRW-Atlas verbinde um z.B. Hausnummern, Bachläufe und Naturschutzgebiete genauer und umfassender zu mappen.

maxbe wrote:

DD1GJ wrote:

Einen herzlichen Dank an die Bezirksregierung Köln für die äußerst unbürokratische und großzügige Nutzungserlaubnis und an Gregor, der den Stein ins Rollen gebracht hat.

... und an dich, weil du so erfolgreich Briefe an Ämter schreibst.
Max

+1

Gruß Klaus

NRW wrote:

Gegen die von Ihren "OSM-Mappern" mittels GIS-Editoren beabsichtigten Nutzungen der WMS-Darstellungsdienste des NRW-Atlas zur Lagekontrolle, Qualitätssicherung und zur Ableitung von Geodaten kann ich keine Einwände erkennen.

Gibt es schon WMS-Urls für JOSM ?

chris66 wrote:

Gibt es schon WMS-Urls für JOSM ?

Ist oben zweimal verlinkt:
http://www.bezreg-koeln.nrw.de/brk_inte … index.html

In JOSM:
WMS Hinzufügen
Dienst-URL eingeben, z.B. DOP40 http://www.wms.nrw.de/geobasis/wms_nw_dop40
Ebenen abrufen
DOP40 auswählen
Bildformat auswählen

Ergebnis:
wms:http://www.wms.nrw.de/geobasis/wms_nw_dop40?FORMAT=image/png&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

Super, Danke! Bing adé. 😉

Edit: Wo kann man nochmal das Aufnahmedatum der Fotos nachschauen?

Edit2: nach Häuserbestand müsste es von Mitte 2012 sein.

Nur zur Klarstellung: "Abpausen": Ja - Importieren: Nein. ?
Deckt sich genau mit meinen Wünschen und Vorstellungen. Werde mal als alter Castroper (*) ein wenig die Gegend verbessern.

Danke an Jochim und natürlich auch an das Geodatenzentrum, Köln

Gruss
walter

• ) was ist der lateinischen Name von "Wanne-Eickel"? --> Castrop-Rauxel
  

Nachtrag: Luftbilder krieg ich aber die Metadaten sind leer. Bekomme nur weisse Käsekästchen mit gelben Rand.
any Hints? Nutze Josm.

Walter

klaro: dieser URL bietet nur Orthophotos an. Den anderen muß ich wohl suchen.

Gefunden: http://www.wms.nrw.de/geobasis/wms_nw_alk_raster danach das selbe Spielchen wie vorher von Jochen beschrieben.
Wieder ein Beweis meiner These: Schau immer in den Originaldokumenten nach - verlasse dich nicht auf Sekundärliteratur

wambacher wrote:

Nur zur Klarstellung: "Abpausen": Ja - Importieren: Nein. ?

Was ich interessant finde ist, daß es solche Erlaubnisse öfters gibt. Ich habe z.B. eine ähnliche Erlaubnis für die Verwendung der Höhendaten von CIAT/CGIAR bekommen. Weiterverarbeiten unkritisch, speichern und wiederverkaufen: Nein.

Es ist eher die Gewöhnung an die eigene aggressiv virulente Lizenz die zu der Erwartungshaltung führt daß ein Abzeichnen schon einem Import gleichkommt. Die Bereitsteller sehen das oft wesentlich lockerer.

bye, Nop

Ich habe mir den WMS-Layer jetzt mal installiert ... super Qualität ... das bringt nochmal einen Schub für die OSM-Daten.

Gruß Klaus

toc-rox wrote:

Ich habe mir den WMS-Layer jetzt mal installiert ... super Qualität ... das bringt nochmal einen Schub für die OSM-Daten.

Gruß Klaus

welchen? Ortho oder Alk? Weil die Ortho mit 40 cm Auflösung nicht sooo toll sind - aber wohl aktueller.

Hicks,
walter

wambacher wrote:

Alk

Ja gerne. 😎

Mal ne Frage: hab ich das nun richtig verstanden, dass ich das in JOSM verwenden darf? Und auch die Hausnummern davon abpausen kann?
Wie sieht es mit dem Versatz aus? AUch wenn Alk im Spiel ist: kann ich davon ausgehen, dass sie lagegetreu sind?

Ich habe ferner gerade bei Alk einen Feldweg entdeckt, der dort eingezeichnet ist. In natura kann ich den so nicht bestätigen.

Danke!

wambacher wrote:

Weil die Ortho mit 40 cm Auflösung nicht sooo toll sind - aber wohl aktueller.

Hicks,
walter

Also mir reicht die Quali. 😎

chris66 wrote:

Also mir reicht die Quali.

Mag ja von Ecke zu Ecke unterschiedlich sein. Hier mal Castrop:

http://osm.wno-edv-service.de/DataServe … m/alk1.png
http://osm.wno-edv-service.de/DataServe … /bing1.png

wambacher wrote:

...
Mag ja von Ecke zu Ecke unterschiedlich sein. Hier mal Castrop:
...

Ist Castrop nicht die Verballhornung von "Katastrophe"? 🤣

Zumindest für diesen Ecke in Köln
http://www.openstreetmap.org/#map=18/50.91235/7.02221
kann ich sagen, dass das ziemlich alte Bilder sind.

Das auf der südlichen Seite des großen BÜs sichtbare Gebaude mit dem Parkplatz existiert seit Anfang 2011.

Bernd

wambacher wrote:

welchen? Ortho oder Alk?

Beide ... "unser Dorf soll schöner werden".

Gruß Klaus

poppei82 wrote:

Mal ne Frage: hab ich das nun richtig verstanden, dass ich das in JOSM verwenden darf? Und auch die Hausnummern davon abpausen kann?
Wie sieht es mit dem Versatz aus? AUch wenn Alk im Spiel ist: kann ich davon ausgehen, dass sie lagegetreu sind?

Ich habe ferner gerade bei Alk einen Feldweg entdeckt, der dort eingezeichnet ist. In natura kann ich den so nicht bestätigen.

Ja, Du kannst alles in JOSM verwenden und auch die Hausnummern abpausen (bitte nach dem Karlsruher Schema). Die Lagegenauigkeit müsste stimmen, aber ich werde sie heute Abend nochmals überprüfen.

Für das ALK und sonstigen Karten gelten die gleichen Vorsichtsmaßnahmen wie bei MAPS4BW, insbesondere bei Feld- und Waldwegen.

wambacher wrote:

chris66 wrote:

Also mir reicht die Quali.

Mag ja von Ecke zu Ecke unterschiedlich sein. Hier mal Castrop:
http://osm.wno-edv-service.de/DataServe … m/alk1.png
http://osm.wno-edv-service.de/DataServe … /bing1.png

Das ist ja auch ein unfairer Vergleich.
Du hast beide WMS in JOSM auf ca. 10cm Auflösung hochskaliert. Die 40cm Auflösung entspricht ungefähr unserem Zoomlevel 18, die 30cm Auflösung von Bing sind auf unseren Zoomlevel 19 (entsprechend ~20cm) von Bing hochskaliert. Leider sind die Bing-Bilder nicht überall von gleicher Qualität. Von daher hat das DOP40 durchaus ein Chance gegenüber den Bing-Bilder je nach deren Qualität.

In Bonn z.B. stammen die Bing-Bilder aus dem Hochsommer, haben also volle Belaubung, was viele Details verdeckt. sind in Bonn die Bingbilder eher vom Typ "Bild mit Soße drüber". Zusätzlich sind wir in Bonn durch die Bilder von Aerowest mit 10cm Auflösung verwöhnt. Die sind leider inzwischen 10 Jahre alt und damit sind viele Änderungen an Straßen, neuen Gebäude usw. nicht sichtbar. In solchen Fällen muss halt das (schlechtere aber wesentlich neuere) Bing-Bild in die Bresche springen.
Sprich ich werde die relativ aktuellen DOP40 mal die Tage ausprobieren.

PS-1: Ich nutze auch meistens Z19 / 10cm fürs Mappen.
Von daher ist dein Vergleich nicht wirklich abwegig.
PS-2: Allgemein wird die Befliegung in NRW alle drei Jahre wiederholt.
Es können also Bilder ab 2010 sein (oder halt neuer).
PS-3: In ALK sind im Prinzip Wege-Rechte eingetragen. Die können
genutzt werden oder eben nicht (mehr). Das sind insbesondere bei
Feld- und Waldwegen keine Aussagen über den aktuellen Zustand.

Edbert (EvanE)

Nun kann man auch die Gemeindegrenzen verbessern. (WMS:Layer: Kommunen)

DD1GJ wrote:

Für das ALK und sonstigen Karten gelten die gleichen Vorsichtsmaßnahmen wie bei MAPS4BW, insbesondere bei Feld- und Waldwegen.

... und auch allgemein bei Gebäudegrundrissen (gerade eben im MAPS4BW-Artikel im Wiki ergänzt). Nicht immer wird ein Gebäude eingemessen und ins Liegenschaftskataster aufgenommen. Meistens verzichtet der Eigentümer pflichtwidrig darauf, einen Öffentlich bestellten Vermessungsingenieur bzw. das Vermessungsamt mit der Gebäudeaufnahme zu beauftragen. Manchmal wird dann das Vermessungsamt (in machen Bundesländern auch der ÖbVI) von Amts wegen tätig und schickt dem Eigentümer einen Gebührenbescheid. Ist das Gebäude jedoch sehr alt, sehr klein oder sehr günstig (Errichtungskosten), muss man das Gebäude gar nicht ins Liegenschaftskataster aufnehmen.

Viele Grüße

Michael

EvanE wrote:

wambacher wrote:

Mag ja von Ecke zu Ecke unterschiedlich sein. Hier mal Castrop:
http://osm.wno-edv-service.de/DataServe … m/alk1.png
http://osm.wno-edv-service.de/DataServe … /bing1.png

Leider sind die Bing-Bilder nicht überall von gleicher Qualität. Von daher hat das DOP40 durchaus ein Chance gegenüber den Bing-Bilder je nach deren Qualität.

Genau das habe ich ja geschrieben - meine ich zumindest.

Gruss
walter

wambacher wrote:

EvanE wrote:

Leider sind die Bing-Bilder nicht überall von gleicher Qualität. Von daher hat das DOP40 durchaus ein Chance gegenüber den Bing-Bilder je nach deren Qualität.

Genau das habe ich ja geschrieben - meine ich zumindest.

Hallo Walter

Im Grunde schon, kam aber (bei mir) nicht so klar rüber.

Edbert (EvanE)

Nakaner wrote:

DD1GJ schrieb:

Für das ALK und sonstigen Karten gelten die gleichen Vorsichtsmaßnahmen wie bei MAPS4BW, insbesondere bei Feld- und Waldwegen.

... und auch allgemein bei Gebäudegrundrissen (gerade eben im MAPS4BW-Artikel im Wiki ergänzt). Nicht immer wird ein Gebäude eingemessen und ins Liegenschaftskataster aufgenommen. Meistens verzichtet der Eigentümer pflichtwidrig darauf, einen Öffentlich bestellten Vermessungsingenieur bzw. das Vermessungsamt mit der Gebäudeaufnahme zu beauftragen. Manchmal wird dann das Vermessungsamt (in machen Bundesländern auch der ÖbVI) von Amts wegen tätig und schickt dem Eigentümer einen Gebührenbescheid. Ist das Gebäude jedoch sehr alt, sehr klein oder sehr günstig (Errichtungskosten), muss man das Gebäude gar nicht ins Liegenschaftskataster aufnehmen.

+1: Die amtlichen Karten kann man nicht bedenkenlos abzeichnen.
Trotzdem: Die meisten Gebäudeumrisse (letztlich aus Kataster) sind das genaueste (zusammen mit Aerowest), was man an Georeferenzierung für OSM verwenden darf.
Andere Quellen (Bing etc) zusätzlich als Plausibiltätskontrolle zu verwenden, ist immer eine gute Idee, da Aktualität, Auflösung oder Sichtbarkeit (Belaubung, Schatten) mal da und mal dort besser sind und das sich auch gelegentlich durch neue Daten ändert.
Ich schalte da nicht selten zwischen mehreren Hintergrundlayern hin und her (Überblenden geht auch).

seichter wrote:

Nakaner wrote:

DD1GJ schrieb:
Für das ALK und sonstigen Karten gelten die gleichen Vorsichtsmaßnahmen wie bei MAPS4BW, insbesondere bei Feld- und Waldwegen.

... und auch allgemein bei Gebäudegrundrissen (...). Nicht immer wird ein Gebäude eingemessen und ins Liegenschaftskataster aufgenommen. ...

+1: Die amtlichen Karten kann man nicht bedenkenlos abzeichnen.
Trotzdem: Die meisten Gebäudeumrisse (letztlich aus Kataster) sind das genaueste (zusammen mit Aerowest), was man an Georeferenzierung für OSM verwenden darf.

Andere Quellen (Bing etc) zusätzlich als Plausibiltätskontrolle zu verwenden, ist immer eine gute Idee, da Aktualität, Auflösung oder Sichtbarkeit (Belaubung, Schatten) mal da und mal dort besser sind und das sich auch gelegentlich durch neue Daten ändert.
Ich schalte da nicht selten zwischen mehreren Hintergrundlayern hin und her (Überblenden geht auch).

In Bonn (+ Sankt Augustin, Siegburg, Troisdorf) haben wir ja den Vorteil Aerowest (teilweise noch von 2003) über einen TMS-Server benutzen zu dürfen. Seit es die neuen Bing2012 Bilder gibt, habe ich in JOSM immer beide Hintergrundebenen geöffnet. Bing ist wegen der Qualität meist ausgeblendet (gegen 10cm Auflösung von Aerowest hat man kaum eine Chance) und wird eingeblendet, wenn es um die Aktualität geht (da sind 9 Jahre Unterschied von großer Bedeutung).

Edbert (EvanE)

Hallo

Ich habe mir gestern Abend einige der WMS-Layer aus dem NRW-Atlas in JOSM installiert und ein wenig damit gespielt. Dabei sind mir einige Dinge aufgefallen.

- Das Digitale Orthophote DOP40 ist heller und kontrastreicher als das
Bing2012 Bild. Es ist weitgehend ohne Belaubung hat jedoch weniger
Auflösung. Zudem ist es älter (vermutlich von 2010) als Bing2012.
Hier in Bonn steht es also unentschieden zwischen den beiden.

- Einige der schematischen Layer (DGK5, ALK, ...) haben einen Mindest-Zoom.
Zoomt man weiter heraus, erscheint nur noch der weiße Hintergrund.

- Die Automatisierte Liegenschaftskarte (ALK) ist für Details genial.
Damit kann man auch sehr gut Landuse-Grenzen ausrichten.
Es zeigt sich dass die Lagegenauigkeit der Aerowest-Bilder sehr gut ist.
Es braucht nur noch Korrekturen im Bereich von weniger als einem Meter.

- Die Grenzen gehen nur bis auf die Gemeinden herunter. Stadtbezirke
oder Stadtteile, wie sie bei kreisfreien Städten existieren, fehlen leider.

- Die Digitalen Topographischen Karten (DTK) sind selbst als DTK10
(1:10 000) in der Regel zu grob für unsere Art des Detail-Mappings.

Was ich noch nicht gefunden habe, ist eine Karte, in der auch der unterirdische Verlauf von Bächen eingetragen ist. Oft kann man das als lineare Fortsetzung abschätzen, aber das geht nicht, wenn es einen deutlichen Versatz gibt.

In Summe ist die Verfügbarkeit des NRW-Atlas für OSM ein echter Fortschritt.

Edbert (EvanE)

Bitte beim Ausrichten nicht vergessen, dass die Landuses auch jemand mit GPS vermessen haben könnte. Die Grenzen können aktueller sein als ALK. 😉

EvanE wrote:

Was ich noch nicht gefunden habe, ist eine Karte, in der auch der unterirdische Verlauf von Bächen eingetragen ist. Oft kann man das als lineare Fortsetzung abschätzen, aber das geht nicht, wenn es einen deutlichen Versatz gibt.

In der DTK10 ist das eingetragen ... zumindest in "meinem" Gebiet.

Gruß Klaus

aighes wrote:

Bitte beim Ausrichten nicht vergessen, dass die Landuses auch jemand mit GPS vermessen haben könnte. Die Grenzen können aktueller sein als ALK. 😉

Auf dem Lande hast du natürlich recht. Ich dachte mehr an die Stadt also z.B. die Grenze zwischen Residential und Commercial. Das kann man mit ALK sehr gut an den Grundstücksgrenzen ausrichten. Auch auf dem Lande richten sich die Grenzen zwischen Wald/Acker/Wiese oft/meist an den Grund-/Flurstücken aus. Dort muss es aber nicht immer so sein.

Ein wahrer Segen ist ALK bei Hochhäusern. Die sind im Luftbild nicht nur meistens schräg, sondern das Dach ist durch die perspektivische Verzeichnung auch größer als der Abdruck auf dem Boden. Ein schönes Beispiel ist der "Lange Eugen" (ehemaliges Abgeordneten-Hochhaus) in Bonn. Bei Aerowest, Bing2012 und dem DOP40 vom NRW-Atlas sieht das Gebäude sehr verschieden aus (einfach in JOSM mal vergleichen). Das Gleiche gilt für den benachbarten Post-Tower.

Wo wir gerade über den NRW-Atlas reden: Was sollen wir als Source-Tagg nehmen?
Mein Vorschlag ist: NRW-Atlas gefolgt von ALK/DOP40/DGK5/DTK10/... je nachdem welche Karte man verwendet hat.

Edbert (EvanE)

toc-rox wrote:

EvanE wrote:

Was ich noch nicht gefunden habe, ist eine Karte, in der auch der unterirdische Verlauf von Bächen eingetragen ist. Oft kann man das als lineare Fortsetzung abschätzen, aber das geht nicht, wenn es einen deutlichen Versatz gibt.

In der DTK10 ist das eingetragen ... zumindest in "meinem" Gebiet.

Hallo Klaus

Danke für den Tipp.
Ausgerechnet die Digitale Topografische Karte 1:10 000 (DTK10) hatte ich nicht ausprobiert.
Die Digitale Grundkarte 1:5000 (DGK5, nur in Schwarz/Weis) schien mir für Bäche nicht ergiebig.

Edbert (EvanE)

Bei aller allgemeinen Begeisterung:

Bitte nicht vergessen, dass wir die Realität abbilden wollen und nicht einfach nur noch eine Blaupause von amtlichen Karten malen. Und in den bei uns vorliegenden amtlichen Daten (die ich nicht verwenden darf und nicht verwende) sind doch diverse Fehler enthalten. Zum Beispiel Hausnummern, für die es (noch) keine Gebäude (mehr) gibt. Leider gibt es hier auch Mapper, die diese Karten rechtswidrig nutzen (erkennbar an eben solchen nirgends sonst ersichtlichen Hausnummern, der Flächendeckung auch bei versteckten Gebäuden, großen Adressmengen in kurzer Zeit nebst nicht gemapptem Gebäudegrundriss und an der Übernahme von "amtlichen" Wegen, die in der Natur noch nie vorhanden waren (auch Ämter fehlinterpretieren Luftbilder ;-) ) oder schon lange nicht mehr vorhanden sind).

Scheinbar ist es den Ämtern aber auch zu mühsam hiergegen vorzugehen ;-) (Weil die Beweisführung auch nicht trivial ist?)

pyram wrote:

... Leider gibt es hier auch Mapper, die diese Karten rechtswidrig nutzen ...

Rechtswidrig? Was genau meinst du?

Gruß Klaus

toc-rox wrote:

Rechtswidrig? Was genau meinst du?

Hinsetzen und einfach die Daten abmalen ist ein Verstoß gegen das Urheberrecht, weil eine Karte durchaus auch eine Datenbank in diesem Rechtssinne sein kann, also nicht nur die Form der Darstellung (Optik) geschützt ist. In Bayern gibt es meines Wissens nach keine Freigabe dafür...

Zulässig wäre, mit dieser Karte durch die Gegend zu laufen und die mit dieser Hilfe gefundenen Hausnummern oder was auch immer dann erfassen. Dann gibt es auch keine Phantomnummern und Straßen (residentials), die in der Realität bestenfalls Grundstückszufahrten sind.

pyram wrote:

toc-rox wrote:

Rechtswidrig? Was genau meinst du?

Hinsetzen und einfach die Daten abmalen ist ein Verstoß gegen das Urheberrecht, weil eine Karte durchaus auch eine Datenbank in diesem Rechtssinne sein kann, also nicht nur die Form der Darstellung (Optik) geschützt ist. In Bayern gibt es meines Wissens nach keine Freigabe dafür...

Langsam, immer langsam.
Wir reden hier über die freigegebenen Daten des Landes Nordrhein-Westfalen (kurz NRW-Atlas). Dein Einwand trifft also nicht auf den Gegenstand dieser Diskussion zu.

In anderen Bundesländern gibt es noch abweichende Regelungen (dort könnte das ggfs. rechtswidrig sein). Aber eine Freigabe wird mittelfristig wohl in allen Bundesländern erfolgen. NRW war nicht der erste und wird sicher nicht der letzte sein, der Geodaten freigibt.

Edbert (EvanE)

EvanE wrote:

Wir reden hier über die freigegebenen Daten des Landes Nordrhein-Westfalen (kurz NRW-Atlas). Dein Einwand trifft also nicht auf den Gegenstand dieser Diskussion zu.

Bin nicht schnell ;-) , du hast nur den Zusammenhang nicht richtig erkannt.

Mein Beitrag war eigentlich #32 (Insbesondere der erste Satz). Das was Du kommentierst war meine Reaktion auf die Rückfrage #33, die gewissermaßen OT war, aber nicht unbeantwortet bleiben sollte.

pyram wrote:

EvanE wrote:

Wir reden hier über die freigegebenen Daten des Landes Nordrhein-Westfalen (kurz NRW-Atlas). Dein Einwand trifft also nicht auf den Gegenstand dieser Diskussion zu.

Bin nicht schnell ;-) , du hast nur den Zusammenhang nicht richtig erkannt.

Mein Beitrag war eigentlich #32 (Insbesondere der erste Satz). Das was Du kommentierst war meine Reaktion auf die Rückfrage #33, die gewissermaßen OT war, aber nicht unbeantwortet bleiben sollte.

Ich habe den Zusammenhang durchaus gesehen (die Beiträge folgen ja aufeinander).

Allerdings schreibst du in Post #32 (Umbrüche von mir):
"Und in den bei uns vorliegenden amtlichen Daten (die ich nicht
verwenden darf und nicht verwende) sind doch diverse Fehler
enthalten. ... Mapper, die diese Karten rechtswidrig nutzen ..."
Das ist im Zusammenhang mit der Freigabe des NRW-Atlas für mich nicht nachvollziehbar.

Wenn du dich mit deiner Aussage auf ein anderes Bundesland als Nordrhein-Westfalen beziehen wolltest, so hättest du das kenntlich machen sollen. Wie ich in meiner vorigen Antwort schrieb, kann in anderen Bundesländern durchaus noch nicht erlaubt sein, was wir in NRW seit kurzem dürfen.

Edbert (EvanE)

EvanE wrote:

Wenn du dich mit deiner Aussage auf ein anderes Bundesland als Nordrhein-Westfalen beziehen wolltest, so hättest du das kenntlich machen sollen.

Mea culpa. Das "bei uns" war etwas unpräzise, wenn man mein Kerngebiet (Bayern) nicht kennt/extra rechergiert und sollte lediglich verdeutlichen, warum ich dem Ganzen etwas reserviert gegenüberstehe (mir wurden schon mehrfach mit solchen Daten (na ja: unbewiesen, aber woher soll's kommen) richtige Informationen demoliert) :-(

Die Aussage über die Fehler in den Daten dürfte nämlich auch für NRW gelten ;-) . Wenn "begeistertes abmalen" irgendwann Standard sein sollte, werde ich meine Mitarbeit an dem Projekt wohl überdenken, weil ich keinen Sinn darin sehe, eine "Kopie" von freigegebenen Daten (inclusive deren Fehler) zu erstellen oder gegen "amtliche Daten" anzumappen. (Du dafst das natürlich gerne anders sehen.)

pyram wrote:

Wenn "begeistertes abmalen" irgendwann Standard sein sollte,

Da geht der Trend wohl langsam hin.

Ich hatte letzte Woche noch ein Schlüsselerlebnis. Wegen einer "Note" hatte ich ein Wohngebiet anhand BING versucht
so gut als möglich zu ergänzen. Vor 2 Tagen bin ich dann zur Ergänzung der Hausnummern hingeradelt und
war erschreckt wie falsch meine Bing-Interpretation war...

pyram wrote:

Die Aussage über die Fehler in den Daten dürfte nämlich auch für NRW gelten ;-) . Wenn "begeistertes abmalen" irgendwann Standard sein sollte, werde ich meine Mitarbeit an dem Projekt wohl überdenken, weil ich keinen Sinn darin sehe, eine "Kopie" von freigegebenen Daten (inclusive deren Fehler) zu erstellen oder gegen "amtliche Daten" anzumappen. (Du dafst das natürlich gerne anders sehen.)

Die Kombination aus allem macht es ... amtliche Daten die übernommen werden können, freie Orthofotos aus verschiedenen Quellen und am wichtigsten: das lokale Wissen der Mapper.

Gruß Klaus

toc-rox wrote:

pyram wrote:

Die Aussage über die Fehler in den Daten dürfte nämlich auch für NRW gelten ;-) . Wenn "begeistertes abmalen" irgendwann Standard sein sollte, werde ich meine Mitarbeit an dem Projekt wohl überdenken, weil ich keinen Sinn darin sehe, eine "Kopie" von freigegebenen Daten (inclusive deren Fehler) zu erstellen oder gegen "amtliche Daten" anzumappen. (Du dafst das natürlich gerne anders sehen.)

Die Kombination aus allem macht es ... amtliche Daten die übernommen werden können, freie Orthofotos aus verschiedenen Quellen und am wichtigsten: das lokale Wissen der Mapper.

+1
Die Gebäudeumrisse (letztlich aus Katasterdaten) sind (fast immer) sehr genau und eignen sich vor allem auch für Georeferenzierung (und damit für die Kalibrierung der Luftaufnahmen).
Wenn man dann noch an abweichende Objekte ein "source=local_knowledge" und/oder "note=amtliche Daten falsch/veraltet" dranhängt, wird da hoffentlich niemand drüberbügeln.

seichter wrote:

... wird da hoffentlich niemand drüberbügeln.

Mir wurden bereits reihenweise präzise "HiRes aerial imagery"-Gebäude mit dem bing-Luftbild "verbessert" (und das nicht mal mehr rechtwinklig und komischerweise obwohl noch viele Bereiche im Stadtgebiet gar keine Gebäude haben). Viele machen sich nicht die Mühe, das Source-Tag anzusehen (oder kennen es nicht).
Lageverbesserung (die ich nicht ganz so wichtig sehe - weder fürs Routing, noch für die Kartendarstellung) durch amtliche Referenzobjekte... die Hoffnung stirbt zuletzt.

Auch wurden private Zufahrtswege zu Residentials umgetaggt, weil im BayernAtlas das falscherweise so dargestellt wird (trotz Luftbild, das zeigt, das das Unfug ist). Reaktion des Ummappers: "...kleine Hinweisschildchen "Privatweg, Benutzung auf eigene Gefahr"; dies sind m.E.keine StVO-relevanten Ausschilderungen..." (aber das ist auch ein anderes Thema).

toc-rox wrote:

Die Kombination aus allem macht es ...

Ja, es gibt auch Mapper, die das können :-)

Mein Beitrag sollte halt auf die Begeisterungsbremse treten und zum Nachdenken anregen. Ich hoffe, das ist gelungen.

pyram wrote:

Lageverbesserung (die ich nicht ganz so wichtig sehe - weder fürs Routing, noch für die Kartendarstellung) durch amtliche Referenzobjekte... die Hoffnung stirbt zuletzt.

Da schon die GPS-gestützten Geräte Fehler von etlichen Metern haben, sollte wenigstens die Karte genauer sein.
Auch für das Kartenbild ist es besser, wenn an den Nahtstellen zweier Vorlagen nicht zu große Versätze auftreten.

Dass man die amtlichen Werke nicht unbesehen (begeistert) übernehmen kann, ist hier schon ein paarmal gesagt worden.

seichter wrote:

...
Dass man die amtlichen Werke nicht unbesehen (begeistert) übernehmen kann, ist hier schon ein paarmal gesagt worden.

Stimmt.
Das Gebäude ist im NRW-Atlas (ALK) total daneben http://www.openstreetmap.org/browse/way/125267516 , was man auch bei einem Vergleich mit den Luftbildern erkennt.

Aber hier wird man sicher einiges verbessern können (source=rough guess) http://www.openstreetmap.org/browse/way/83676214

Gilt die Nutzungserlaubnis für ganz NRW oder nur den Regierungsbezirk Köln?

Hallo BFX,

BFX wrote:

Gilt die Nutzungserlaubnis für ganz NRW oder nur den Regierungsbezirk Köln?

das Dezernat 74 (Geodatenzentrum, Geodateninfrastruktur) der Bezirksregierung Köln ist für alle Geodaten-Sachen in NRW zuständig.

Yepp, hier auch: Gebäude besser vom DOP40 abmalen. Die Position der Hausnummer im ALK innerhalb des Gebäudeumrisses
passt auch nicht immer.

chris66 wrote:

Die Position der Hausnummer im ALK innerhalb des Gebäudeumrisses passt auch nicht immer.

Meinst du Lage der Hausnummer bzg. des Hauses? Also Hausnummer im falschen Teil bei Häuserblöcken?
Oder : da wo Hausnummer ist, sollte Eingang sein ?

Gruss
walter

ja, letzteres.

Nakaner wrote:

Ist das Gebäude jedoch sehr alt, sehr klein oder sehr günstig (Errichtungskosten), muss man das Gebäude gar nicht ins Liegenschaftskataster aufnehmen.

Viele Grüße

Michael

Hallo zusammen,
die genaue Definition laut Vermessungsgesetz
https://recht.nrw.de/lmi/owa/pl_text_an … 5144653193
Abschnitt III
Liegenschaftskataster
§ 11 Inhalt und Zweck
des Geobasisinformationssystems für den Bereich des Liegenschaftskatasters

(3) Gebäude sind dauerhafte, selbstständig benutzbare, überdeckte bauliche Anlagen, die wegen ihrer Bedeutung im Liegenschaftskataster nachzuweisen sind. Sie können von Menschen betreten werden und sind geeignet oder bestimmt, dem Schutz von Menschen, Tieren, Sachen oder der Produktion von Wirtschaftsgütern zu dienen.

Mit besten Grüßen
nicht die Göre

ps: mein Onkel wollte wissen was ich hier so mache und da hat er etwas rumgelesen und wollte das nur mal Richtigstellen
Entschuldigung, aber Weihnachten steht vor der Tür, wegen der Geschenke und so ;-)

Vermessung ist zwar Ländersache, aber so ähnlich wird es wohl in allen Landesgesetzen stehen.
Problem bei den amtlichen Daten ist mMn eher die Aktualität. Neubauten, abgerissene Gebäude und Umbauten tauchen auch in den Katastern der Gemeinden erst mit Verzögerung auf und das muss dann auch erst noch zum Land transferiert werden. Davon abgesehen sind die für die Nutzung freigegebenen Daten meist ein paar Jahre alt.

seichter wrote:

Vermessung ist zwar Ländersache, aber so ähnlich wird es wohl in allen Landesgesetzen stehen.
Problem bei den amtlichen Daten ist mMn eher die Aktualität. Neubauten, abgerissene Gebäude und Umbauten tauchen auch in den Katastern der Gemeinden erst mit Verzögerung auf und das muss dann auch erst noch zum Land transferiert werden. Davon abgesehen sind die für die Nutzung freigegebenen Daten meist ein paar Jahre alt.

Da muss ich teilweise widersprechen.

Eine Befliegung für die Orthophotos findet (in NRW) alle drei Jahre statt. Im Grunde erfolgt das kontinuierlich jedoch immer an anderen Orten. Das gesamte Land wird in Summe in drei Jahren komplett beflogen. Je nachdem sind die Orthophotos als 1-3.5 Jahre alt. In Bonn wahrscheinlich von 2010, auf jeden Fall klar älter als die Bing2012 Bilder.

Auch die Liegenschaftskarte (ALK), die Grundkarte (DGK) sowie die topographischen Karten haben ähnliche Aktualisierungsrythmen. Man kann also Glück haben (aktueller als ein Jahr) oder auch Pech (älter als drei Jahre).

Häuser und Straßenführungen ändern sich ja zum Glück selten, sobald sie mal existieren. Allerdings muss man seine Gegend recht gut kennen, um zu wissen, wo es Änderungen gegeben hat. An solchen Stellen, muss man dann vor Ort prüfen, wie der aktuelle Stand der Dinge ist.

Letztlich ist die Aktualität (hoffentlich durch Besichtigung geprüft) einer der Vorteile von OSM. Das sollten wir durch 'blindes' Abzeichnen von amtlichen Unterlagen nicht verspielen.

Man kann auch mal Glück haben.
In Bonn wurde 2012/13 eine Kreuzung in einen ampelgeregelten 'Kreisverkehr' den sogenannten Trajektknoten umgebaut (Freigabe Juni 2013). Das ist natürlich noch auf keinem Luftbild drauf und auch nicht in der ALK enthalten. Aber zu meinem großen Erstaunen ist die DGK5 in diesem Bereich top-aktuell. So konnte ich die Größenordnung / Lage nach vielen Besuchen den realen Gegebenheiten anpassen.

Noch etwas: Aufgrund der Tatsache, dass alle Luftbilder und Karten bei der Veröffentlichung an irgendwelchen Stellen 'veraltet' sind, sollte man abgerissene Häuser nicht einfach in OSM löschen, sondern den Umriss erhalten, nur die Taggs entfernen und eine Notiz des Inhalts "... abgerissen ... Datum (der Besichtigung)" hinzufügen. Andernfalls trägt das womöglich ein anderer Mapper nach den Bildern / Karten wieder ein. Das gilt natürlich auch für aufgegebene Wege oder geänderte Wegführungen.

Edbert (EvanE)

Hallo Edbert,

EvanE wrote:

Eine Befliegung für die Orthophotos findet (in NRW) alle drei Jahre statt.

gibt es auch CIR-Bilder? Mit denen kann man Viele Sachen bedeutend besser unterscheiden (u.a. auch Gewässer im Wald).

fragt Sven (der aber in NRW nicht unbedingt Mappen will)

streckenkundler wrote:

EvanE wrote:

Eine Befliegung für die Orthophotos findet (in NRW) alle drei Jahre statt.

gibt es auch CIR-Bilder? Mit denen kann man Viele Sachen bedeutend besser unterscheiden (u.a. auch Gewässer im Wald).

Hallo Sven

Über das NRW-Archiv werden nur DOP40 und die Metadaten dazu als Ebenen angeboten. Die Antwort lautet also: Nein.

Das schließt nicht aus, dass Geobasis NRW solche Bilder besitzt. Sie gehören nur nicht zu den "Offenen Daten". Auch bei den Orthophotos besitzt das Land / Geobasis NRW Bilder mit besserer Auflösung (10cm oder besser).

Für Bäche (auch im Wald) bietet sich die DTK10 an. Die Bäche sind dabei leicht generalisiert, was in meinen Augen für OSM kein Nachteil ist. Brauchen wir wirklich jede kleine Änderung innerhalb 5m Abstand? Falls doch kann man die DGK5 zu Rate ziehen.

BTW: Was bedeut CIR? (Alles kann man nicht kennen.)

Edbert (EvanE)

EvanE wrote:

BTW: Was bedeut CIR? (Alles kann man nicht kennen.)

Edbert (EvanE)

Color-Infrarot-Luftbild

EvanE wrote:

Auch die Liegenschaftskarte (ALK), die Grundkarte (DGK) sowie die topographischen Karten haben ähnliche Aktualisierungsrythmen. Man kann also Glück haben (aktueller als ein Jahr) oder auch Pech (älter als drei Jahre).

in den Metadaten zu Liegenschaftskarte steht
Aktualität: 13.01.2013

Hallo Edbert,

Auf Arbeit hatte ich keine Zein mehr reinzuschauen, aber jetzt im Zug... 🙂

EvanE wrote:

Über das NRW-Archiv werden nur DOP40 und die Metadaten dazu als Ebenen angeboten. Die Antwort lautet also: Nein.

Auch im Online-Shop werden nur Echtfarbluftbilder (hier DOP20 [Digitales Orthophoto 20cm Bodenauflösung]) angeboten.

EvanE wrote:

Das schließt nicht aus, dass Geobasis NRW solche Bilder besitzt. Sie gehören nur nicht zu den "Offenen Daten". Auch bei den Orthophotos besitzt das Land / Geobasis NRW Bilder mit besserer Auflösung (10cm oder besser).

Auch werden sie nicht zum Kauf angeboten, was mir den Schluß nahe legt, daß sie schlichtweg nicht zur Verfügung stehen. Ich eigentlich schade... (aber man kann nicht alles haben). Bei und in Brandenburg sind sie zu mindestens verfügbar. Ob sie irgendwann mal nutzbar sein werden.... hm... ich hoffe ja...

http://www.geobasis-bb.de/GeoPortal1/produkte/dop.htm

FGOSM22 wrote:

EvanE schrieb:

BTW: Was bedeut CIR? (Alles kann man nicht kennen.)

Edbert (EvanE)

Color-Infrarot-Luftbild

ja, sie werden oft auch Falschfarbluftbilder genannt. Das, was bei einem normalen Luftbild grün ist (z.B. Wald) ist bei einem CIR rot. Das hat den Vorteil, daß man Farbunterschiede besser sieht: z.B. Unterscheidung Laub-/ Nadelwald, Feuchtigkeitsgradienten im Offenland. Das hat in dem Fall u.a. was mit dem Chlorophyll der Pflanzen zu tun.

EvanE wrote:

(Alles kann man nicht kennen.)

Das macht auch nichts, Fragen kostet nichts.... 🙂

Sven (mit solchen Luftbildgeschichten dienstlich beschäftigt.)

seichter wrote:

Vermessung ist zwar Ländersache, aber so ähnlich wird es wohl in allen Landesgesetzen stehen.

Ja, das steht so oder so ähnlich in allen Vermessungsgesetzen aller Bundesländer außer Thüringen. Die Vermessungsgesetzt bzw. die dazugehörigen Verwaltungsverordnungen unterscheiden sich i.d.R. nur hinsichtlich Mindestgröße des Gebäudes, Mindesterrichtungskosten oder dem maximalen Alter, damit nicht hundert Jahre nach der Errichtung plötzlich eine Einmessung in Rechnung gestellt wird. Nur Thüringen hat letztes Jahr (kann auch schon zwei Jahre her sein) die Gebäudeeinmessungspflicht leider abgeschafft.

EvanE wrote:

Auch die Liegenschaftskarte (ALK), die Grundkarte (DGK) sowie die topographischen Karten haben ähnliche Aktualisierungsrythmen. Man kann also Glück haben (aktueller als ein Jahr) oder auch Pech (älter als drei Jahre).

EvanE wrote:

Man kann auch mal Glück haben.
In Bonn wurde 2012/13 eine Kreuzung in einen ampelgeregelten 'Kreisverkehr' den sogenannten Trajektknoten umgebaut (Freigabe Juni 2013). Das ist natürlich noch auf keinem Luftbild drauf und auch nicht in der ALK enthalten. Aber zu meinem großen Erstaunen ist die DGK5 in diesem Bereich top-aktuell. So konnte ich die Größenordnung / Lage nach vielen Besuchen den realen Gegebenheiten anpassen.

Wenn ein neu errichtetes Gebäude eingemessen und im Innendienst (Büro) verarbeitet wurde, kommt die Änderung nach einer Prüfung durch das Vermessungsamt in die ALK. Wer als Datennutzer (z.B. Ingenieurbüro, Stadtwerke) einen Auszug aus der ALK kauft, erhält die tagesaktuellen Daten (alles, was schon eingepflegt wurde). Was man in Webservices (z.B. WMS-Dienste) sieht, ist nicht tagesaktuell. Diese werden nur hin und wieder aktualisiert. Sie greifen nicht direkt auf die Haupt-Datenbank zu (wie bei OSM, wo die Hauptdatenbank auch nur der Datenerfassung dient).

Folgendes bezieht sich ausschließlich auf NRW:
Die digitale Grundkarte (DGK5) ist kein 1:1-Rendering der ALK. Sie ist in Sache der Kommunen. Diese bekommen Änderungen aus der ALK mitgeteilt. Sie übernehmen jedoch nicht alles aus der ALK, da z.B. die Landnutzung im Kataster nicht so aktuell ist, sondern bedienen sich auch anderer Datenquellen (z.B. eigene Vermessunge/Begehungen, amtliche Ortophotos, ...).

EvanE wrote:

In Bonn wurde 2012/13 eine Kreuzung in einen ampelgeregelten 'Kreisverkehr' den sogenannten Trajektknoten umgebaut (Freigabe Juni 2013). Das ist natürlich noch auf keinem Luftbild drauf und auch nicht in der ALK enthalten. Aber zu meinem großen Erstaunen ist die DGK5 in diesem Bereich top-aktuell. So konnte ich die Größenordnung / Lage nach vielen Besuchen den realen Gegebenheiten anpassen.

Edbert (EvanE)

die ALK ist auch keine TOP Karte, solange wie da keine Vermessung stattgefunden hat wir das nicht in die Liegenschaftkarte kommen.

Mit besten Grüßen
nicht die Göre

hier noch die Beschreibung zur Deutsche Grundkarte 1 : 5.000 (DGK5)
http://www.bezreg-koeln.nrw.de/brk_inte … index.html

Hallo an alle

Vielen Dank für die hilfreichen Antworten.
CIR = Color InfraRed = Falschfarben Film/Bild.
Damit kann ich etwas aus meinen alten Fototagen anfangen.

Ich versuche mal meine bisherigen Erfahrungen mit dem NRW-Atlas zusammen zu fassen.

Erst ein mal können die Karten im Web heute (vor allem aus organisatorischen Gründen) nicht tagesaktuell sein (Hinweis von Nakaner). Es ist also immer von einem Alter zwischen 0.5 und 4 Jahren (z.B. Luftbilder) auszugehen. Welche Daten in den 'technischen' Karten (ALK/DG5/DTK*) jeweils schon enthalten sind, kann sich von Ort zu Ort unterscheiden (letzte Update Information vor/nach dem Stichtag). (Die Daten vom Liegenschaftsamt sind natürlich tagesaktuell.)

Das DOP40 (Digitales OrthoPhoto, 40cm Auflösung) ist wegen der geringen Auflösung leider nur begrenzt nützlich. Zudem stehen akuellere Bild mit besserer Auflösung über Bing2012 zur Verfügung. Je nach deren Qualität (teils zu dunkel, volle Belaubung) sind die Bilder von DOP40 dennoch eine nützliche Ergänzung.

Die ALK (Automatisierte LiegenschaftsKarte) kümmert sich um Grundstücke (einschließlich der Straßen und Wege im öffentlichen Besitz) und Gebäude. Darin ist sie sehr präzise. Neben der Lage und Form kann man auch Straßennamen und insbesondere Hausnummern daraus entnehmen.

Die DGK5 (Digitale GrundKarte 1:5000) basiert auf den ALK-Daten hat jedoch einen erweiterten Umfang von topographischen Elementen wie Böschungen / Flüsse und Bäche / Teiche und Seen / Sport- und Spielplätze. Insbesondere sind dort auch Wirtschaftswege (Feld und Wald) und einige Pfade enthalten. Die aus meiner Sicht nützlichsten Informationen der DGK5 sind jedoch die Höhenangaben, sehr oft auf den Kreuzungen von Straßen und Wegen.

Die DTK10 (Digitale Topographische Karte 1:10 000) zeigt ein generalisierte Bild einschließlich der Landnutzung. Trotz ihrer für OSM-Verhältnisse geringen Auflösung ist sie nützlich für das Erfassen von Bächen insbesondere in Waldgebieten, da man die in Luftbildern meist nur sehr schlecht erkennen kann und ein Vermessen mit GPS wegen der Schwierigkeiten der Durchführung nur selten gemacht wird.

Die Verwaltungsgrenzen liegen nur bis zur Stadt oder Verwaltungsgemeinschaft vor, Stadt- oder Ortsteile (bei OSM admin_level>8) sind leider nicht enthalten. Aber immerhin ist das ein Anfang.

Zum Schluss noch einmal der (von vielen bereits erwähnte) Hinweis, nicht ungeprüft von ALK, DGK5 oder TK10 oder Luftbildern abzuzeichnen:
- Die Karten sind nicht topaktuell, können es auch nicht sein. Neue Dinge
wie Abriss, Neubau, Straßenänderungen, Neubaugebiete fehlen oft.
- Nicht jedes Wegerecht, das in den amtlichen Karten verzeichnet ist, wird
auch wirklich genutzt. Das betrifft vor allem kleine und Wirtschaftswege.
- Auch amtliche Karten sind nicht völlig frei von Fehlern. Bekannt sind
verwechselte Hausnummern (gegenüber der Anbringung vor Ort).
Es gilt also immer die eigene Ortskenntnisse einzubringen oder zusätzlich zu besichtigen.

Edbert (EvanE)

EvanE wrote:

Ich versuche mal meine bisherigen Erfahrungen mit dem NRW-Atlas zusammen zu fassen.

Danke für deine Super Zusammenfassung!

Vielleicht hast du, oder jemand anders Lust das Ganze ins Wiki zu stellen, wie es DD1GJ (http://forum.openstreetmap.org/viewtopi … 39#p370539) für BaWü geta hat: http://wiki.openstreetmap.org/wiki/Maps … er_Hinweis
VIelleicht kann man das ja nur kopieren und etwas anpassen.

Ich würde es machen, kann zeitlich gerade aber gar nicht. 🙁

Ein (für mich) wichtiger Gesichtspunkt ist, ob die Karte georeferenziert ist, noch besser, wenn man sie per WMS-Dienst als Hintergrundebene einbinden kann. Ich habe es mit der NRW-ALK probiert, die sogar als Vektorkarte verfügbar ist. Da gibt es dann saubere Linien bis zur höchsten Zoomstufe. Stellenweise fast übergenau: Ich habe Hausvorsprünge im Zentimeterbereich gesehen, deren Existenz ich teilweise nicht beschwören würde, da sie nicht rechtwinklig sind. Da würde ich eher auf Rundungsfehler bei benachbarten Stützpunkten tippen. Das ist aber eher ein Luxusproblem: Das ist jedenfalls die genaueste Karte, die mir bisher untergekommen ist.

poppei82 wrote:

EvanE wrote:

Ich versuche mal meine bisherigen Erfahrungen mit dem NRW-Atlas zusammen zu fassen.

Danke für deine Super Zusammenfassung!

Vielleicht hast du, oder jemand anders Lust das Ganze ins Wiki zu stellen, wie es DD1GJ (http://forum.openstreetmap.org/viewtopi … 39#p370539) für BaWü geta hat: http://wiki.openstreetmap.org/wiki/Maps … er_Hinweis
VIelleicht kann man das ja nur kopieren und etwas anpassen.

Ich würde es machen, kann zeitlich gerade aber gar nicht. 🙁

DAS hatte ich befürchtet. 😉

Neben meinen Erfahrungen, die gerne jemand in so einer Seite verwenden darf, braucht es ja noch andere Informationen, wie die Genehmigung.

Die Situation mit dem NRW-Atlas ist ja anders als mit Maps4BW für Baden-Württemberg.
In BaWü hat man eine Karte während man in NRW einen Atlas von mehreren Karten hat. Das hat Vor- und Nachteile: Detailiertere Informationen einerseits, die Notwendigkeit mehrere Karten zu laden andererseits.

Beide Bilddienste sind übrigens WMS-Dienste und verwenden keine Kacheln, wie es OSM-Karten und viele Luftbilder machen. Nachteil ist, dass diese Dienste nach meiner Kenntnis nur mit JOSM und Merkaartor verwendet werden können. Potlatch und iD bleiben leider außen vor.

PS:
Mir wäre es lieber, wenn jemand anderes die Aufgabe übernimmt, das ins Wiki zu stellen. Zuarbeiten ist in Ordnung, aber die ganze Seite zu erstellen, dafür fehlt mir doch die Zeit. Das Muster Maps4BW kann man ja wegen der anderen Situation nicht einfach als Startpunkt verwenden.

Edbert (EvanE)

EvanE wrote:

Die Situation mit dem NRW-Atlas ist ja anders als mit Maps4BW für Baden-Württemberg.
In BaWü hat man eine Karte während man in NRW einen Atlas von mehreren Karten hat. Das hat Vor- und Nachteile: Detailiertere Informationen einerseits, die Notwendigkeit mehrere Karten zu laden andererseits.

Die generellen Hinweise aus dem Maps4BW-Wiki kann man sicher übernehmen, die rechtliche Lage schätze ich sogar besser ein, da die Bedingungen für OSM günstiger formuliert sind und zwar auf der Eingangsseite, d.h. sie gelten für alle Teilkarten des Atlas.
Der Nachteil, dass man u.U. mehrere Teilkarten laden muss, wird mMn weit dadurch überwogen, dass diese (je nach Zielrichtung) viel genauer sind. In der Maps4BW werden z.B. Gebäudeumrisse durch viel zu breit gerenderte (und ungenauere) Straßen überdeckt. Ich wäre froh, wenn wir hier im Süden ebenso erstklassige Karten hätten (aber immer im Hinterkopf: nicht blind übernehmen).

wambacher wrote:

chris66 wrote:

Die Position der Hausnummer im ALK innerhalb des Gebäudeumrisses passt auch nicht immer.

Meinst du Lage der Hausnummer bzg. des Hauses? Also Hausnummer im falschen Teil bei Häuserblöcken?
Oder : da wo Hausnummer ist, sollte Eingang sein ?

Mittlerweile meine ich beides. 😉

chris66 wrote:

wambacher wrote:

chris66 wrote:

Die Position der Hausnummer im ALK innerhalb des Gebäudeumrisses passt auch nicht immer.

Meinst du Lage der Hausnummer bzg. des Hauses? Also Hausnummer im falschen Teil bei Häuserblöcken?
Oder : da wo Hausnummer ist, sollte Eingang sein ?

Mittlerweile meine ich beides. 😉
http://thumbs.picr.de/16271990dq.jpg

Das ist natürlich blöd. Jetzt haben wir endlich mal was "Vernünftiges" für Couch-Mapper wie mich und dann sowas 🙁

Meine kreativen Pausen verbringe ich in meiner alten Heimatstadt Castrop-Rauxel - aber dort hinfahren? Nee. Lieber einige leicht falsche Hausnummern. Für's Navi sollte es reichen, da man ja zumindest fast an die richtige Stelle kommt.

Es gibt dort aber auch Stellen, wo ich selbst mit der ALK nicht weiterkomme - dort lass ich es halt bleiben.

nun denn
Gruss
walter

chris66 wrote:

wambacher wrote:

chris66 wrote:

Die Position der Hausnummer im ALK innerhalb des Gebäudeumrisses passt auch nicht immer.

Meinst du Lage der Hausnummer bzg. des Hauses? Also Hausnummer im falschen Teil bei Häuserblöcken?
Oder : da wo Hausnummer ist, sollte Eingang sein ?

Mittlerweile meine ich beides. wink
http://thumbs.picr.de/16271990dq.jpg

Tja, im Kataster steht halt meist nur die Flurstück-Nr. (hängt vielleicht von Gemeinde/Land ab), die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben. Aber lieber nur 10 Meter daneben als 10 km (ohne Navi).

seichter wrote:

chris66 wrote:

wambacher wrote:

Meinst du Lage der Hausnummer bzg. des Hauses? Also Hausnummer im falschen Teil bei Häuserblöcken?
Oder : da wo Hausnummer ist, sollte Eingang sein ?

Mittlerweile meine ich beides. wink http://thumbs.picr.de/16271990dq.jpg

Tja, im Kataster steht halt meist nur die Flurstück-Nr. (hängt vielleicht von Gemeinde/Land ab), die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben. Aber lieber nur 10 Meter daneben als 10 km (ohne Navi).

In Bonn stehen in der Liegenschaftskarte die Hausnummern meistens neben dem Eingang, gut zu erkennen ist das bei Wohnblocks mit mehreren Eingängen und Nummern. Das scheint also durchaus System zu haben.

Nachtrag:
Ich halte das auch nicht für eine gewollte / zugesicherte Eigenschaft innerhalb der Liegenschaftskarte. Sonst wäre die Position des Eingangs in irgendeiner Art markiert.

Edbert (EvanE)

Weiss eigentlich jemand, wie es um die Aktualität der Waldwege in amtlichen Karten steht? Ich bin eigentlich vor allem deswegen für Radtouren von der Topo-25/50-Karte auf OSM umgestiegen, weil die Topo-Karten bei Waldwegen furchtbar unzuverlässig sind. Danach bin ich schon oft auf unpassierbare Wege geraten, oder auf solche wo schon mind. 10 Jahre lang neues Gestrüpp und neue Bäume nach einer Rodungsaktion wachsen. Bei OSM waren dagegen die unpassierbaren oder nichtexistenten Wege nicht eingezeichnet, wohl aber die vielen kleinen anderen Waldwege. Die Topo-Karte hatte ich als CD im Buchladen gekauft.

Ich dachte immer, der Waldbesitzer meldet es den Behörden, wenn Wege verschwinden oder neu angelegt werden. Offenbar passiert das nicht. Und die Landvermesser sehen wohl manche Landstriche auch 10 Jahre nicht an.

Gibt es irgendwelche Regeln, nach denen so etwas aktualisiert wird, oder läuft das rein willkürlich ab. Mittlerweile sollten die Ämter Nachhilfe von OSM holen, um ihren Datenbestand zu aktualisieren. Naja, wäre auch ein fairer Ausgleich, OSM bekommt genaue Vermessungsdaten (besser als mit Standard-GPS-Geräten) und die Behörden schauen auf OSM nach Änderungen im Wegenetz nach. So viele Landvermesser könnten die Behörden gar nicht beschäftigen wie OSM-Mapper durch die Landschaft fahren. Ich kann nur nicht verstehen, dass die Prozesse nicht automatisch laufen, dass der Waldbesitzer eine Rodung und die Enfernung eines Weges nicht melden muss. Das wäre am einfachsten, um die Karten stets aktuell zu halten.

p.s.
leider helfen die Luftbilder auch nicht im Wald, um die kleinen Wege zu erkennen.
Für mich ist es dann immer Trial and Error, ob man irgendwo durchkommt.
Notfalls musste ich schon mein Fahrrad durch über Gestrüpp durch den Wald tragen
bzw. kilomenterweit wieder den Berg rauf und einen anderen Abstieg versuchen ...

p.p.s.
Ich hatte es gerade nochmal im WMS auf der Top25 überprüft: die jahrzehntelangen Kartenfehler im Wald gibt es noch immer ...

openzzz wrote:

Gibt es irgendwelche Regeln, nach denen so etwas aktualisiert wird, oder läuft das rein willkürlich ab.

Letzteres bzw. zufällig, weil es für das Amt relativ egal ist. Waldwege prüfen ist kostenintensiv - und Geld ist <dafür> keines da (und als Steuerzahler hoffe ich auch, dass das so bleibt). Das wird aber auch von Bundesland zu Bundesland unterschiedlich gehandhabt. Früher ist soetwas zumindest hier (in Bayern ;-) ) häufig nur vom Luftbild abgemalt worden oder auf Basis von Flurstücksgrenzen (Wege) geschätzt worden, die aber in der Realität nicht unbedingt/nicht mehr vorhanden sind/waren.

Solche Fehler werden behoben, wenn zufällig ein "interessierter" Messtrupp in der Gegend zu tun hat oder da nicht durchkommt :-)
Alternativ wird das auch behoben, wenn man das LVG/den Gebietstopographen auf den Fehler hinweist (wirklich! - ist mühsam und dauert u.U. über ein halbes Jahr bis die Kachel ausgetauscht ist). War auch ein Grund, warum ich hier mappe.

openzzz wrote:

Ich kann nur nicht verstehen, dass die Prozesse nicht automatisch laufen, dass der Waldbesitzer eine Rodung und die Enfernung eines Weges nicht melden muss.

1. Eine (Ausnahme-)Genehmigung für eine Rodung hat nichts mit der Vermessungsverwaltung zu tun. Insofern läge die Optimierungslösung im Zusammenspiel der Ämter. Nur bedeutet das, dass ein Amt etwas melden müsste, was per se für dieses Amt Mehraufwand bedeutet...
2. Eine generelle Einzelverpflichtung der Besitzer hat nichts mit Prozessautomatisierung zu tun, sondern nur mit Belastung der Bürger und amtlicher Datensammelwut.
3. Eine Privatweg zu "entfernen" sollte niemanden interessieren. Das Anlegen eines "richtigen" Weges ist u.U. genehmigungspflichtig (nicht bei Vermessungsamt). Einen öffentlichen/forstwirtschaftlichen Weg darf kein Privatmensch entfernen.
4. Und bitte nicht noch mehr Bürokratie (offensichtlich bist Du nicht Waldbesitzer).

pyram wrote:

openzzz wrote:

Ich kann nur nicht verstehen, dass die Prozesse nicht automatisch laufen, dass der Waldbesitzer eine Rodung und die Enfernung eines Weges nicht melden muss.

1. Eine (Ausnahme-)Genehmigung für eine Rodung hat nichts mit der Vermessungsverwaltung zu tun. Insofern läge die Optimierungslösung im Zusammenspiel der Ämter. Nur bedeutet das, dass ein Amt etwas melden müsste, was per se für dieses Amt Mehraufwand bedeutet...
2. Eine generelle Einzelverpflichtung der Besitzer hat nichts mit Prozessautomatisierung zu tun, sondern nur mit Belastung der Bürger und amtlicher Datensammelwut.
3. Eine Privatweg zu "entfernen" sollte niemanden interessieren. Das Anlegen eines "richtigen" Weges ist u.U. genehmigungspflichtig (nicht bei Vermessungsamt). Einen öffentlichen/forstwirtschaftlichen Weg darf kein Privatmensch entfernen.
4. Und bitte nicht noch mehr Bürokratie (offensichtlich bist Du nicht Waldbesitzer).

5. Die Welt ist schlecht.

Gruß Wolf

pyram wrote:

Letzteres bzw. zufällig, weil es für das Amt relativ egal ist. Waldwege prüfen ist kostenintensiv - und Geld ist <dafür> keines da (und als Steuerzahler hoffe ich auch, dass das so bleibt).
...
wenn man das LVG/den Gebietstopographen auf den Fehler hinweist (wirklich! - ist mühsam und dauert u.U. über ein halbes Jahr bis die Kachel ausgetauscht ist). War auch ein Grund, warum ich hier mappe.

Dafür habe ich als Steuerzahler auch Verständnis, dass sie nicht ständig die Wege abfahren.
Aber bei Gebäuden ist es ja so, dass die Veränderungen sowieso amtlich werden und somit
automatisch in die Topo-Karten übertragen werden.
Für das Straßennetz gibt es sicher auch diesen Automatismus.
Und Waldwege sind i.d.R. auch öffentlich, sogar die des Privatwaldes (Waldgesetz).
Dann war für mich die logische Schlußfolgerung, dass auch geänderten Waldwege
amtlich gemeldet werden (also die echten Wege, nicht die wilden Trampelpfade).
Offenbar eine Gesetzeslücke ...

Ich meine, man kann getrost via OSM helfen, die Ämter auf dem Laufenden zu halten.
Nicht ganz uneigennützig, um als Gegenleistung deren Karten zur Genauigkeitsverbesserung
von OSM nutzen zu dürfen. Das Feedback OSM -> Topokarte könnte man vielleicht
noch besser gestalten. Ich werde sicherlich nicht jedesmal zum Amt laufen, um einen Weg
korrigieren zu lassen. Das müsste auf Knopdruck gehen, zumindest die Fehlermeldung.

Ein halbes Jahr wäre noch Ok. Laut Topokarte bin ich schon auf Wegen gelandet, die
dem Wachstum der neuen Bäume nach schon mind. 10 Jahre nicht mehr existieren.
Und selbst Jahre später noch, heute, sehe ich die gleichen Fehler immer noch in der aktuellen WMS-Karte.
Das ist schade, denn optisch wirken die alten Top50-Karten schöner als OSM, vor allem
im Gebirge mit den eingezeichneten Abhängen, Felsen etc.

openzzz wrote:

pyram wrote:

Letzteres bzw. zufällig, weil es für das Amt relativ egal ist. Waldwege prüfen ist kostenintensiv - und Geld ist <dafür> keines da (und als Steuerzahler hoffe ich auch, dass das so bleibt).
...
wenn man das LVG/den Gebietstopographen auf den Fehler hinweist (wirklich! - ist mühsam und dauert u.U. über ein halbes Jahr bis die Kachel ausgetauscht ist). War auch ein Grund, warum ich hier mappe.

Dafür habe ich als Steuerzahler auch Verständnis, dass sie nicht ständig die Wege abfahren.
Aber bei Gebäuden ist es ja so, dass die Veränderungen sowieso amtlich werden und somit
automatisch in die Topo-Karten übertragen werden.
Für das Straßennetz gibt es sicher auch diesen Automatismus.
Und Waldwege sind i.d.R. auch öffentlich, sogar die des Privatwaldes (Waldgesetz).
Dann war für mich die logische Schlußfolgerung, dass auch geänderten Waldwege
amtlich gemeldet werden (also die echten Wege, nicht die wilden Trampelpfade).
Offenbar eine Gesetzeslücke ...

Ich meine, man kann getrost via OSM helfen, die Ämter auf dem Laufenden zu halten.
Nicht ganz uneigennützig, um als Gegenleistung deren Karten zur Genauigkeitsverbesserung
von OSM nutzen zu dürfen. Das Feedback OSM -> Topokarte könnte man vielleicht
noch besser gestalten. Ich werde sicherlich nicht jedesmal zum Amt laufen, um einen Weg
korrigieren zu lassen. Das müsste auf Knopdruck gehen, zumindest die Fehlermeldung.

Ein halbes Jahr wäre noch Ok. Laut Topokarte bin ich schon auf Wegen gelandet, die
dem Wachstum der neuen Bäume nach schon mind. 10 Jahre nicht mehr existieren.
Und selbst Jahre später noch, heute, sehe ich die gleichen Fehler immer noch in der aktuellen WMS-Karte.
Das ist schade, denn optisch wirken die alten Top50-Karten schöner als OSM, vor allem
im Gebirge mit den eingezeichneten Abhängen, Felsen etc.

Die DAV-Karten waren mal schön (eben wegen der Felszeichnungen), fast so schön wie die Schweizer Karten. Solange bis sie jetzt nur anders angemalte Topo25 sind.

Die Welt ist schlecht.

Gruß Wolf

pyram wrote:

3. Eine Privatweg zu "entfernen" sollte niemanden interessieren. Das Anlegen eines "richtigen" Weges ist u.U. genehmigungspflichtig (nicht bei Vermessungsamt). Einen öffentlichen/forstwirtschaftlichen Weg darf kein Privatmensch entfernen.
4. Und bitte nicht noch mehr Bürokratie (offensichtlich bist Du nicht Waldbesitzer).

Ein Waldweg eines Privatwaldes ist kein gewöhnlicher Privatweg.
Es gibt da immer wieder Spaßvögel, die ihre Wälder komplett einzäunen und Fußgänger/Radfahrer aussperren.
Wenn die Recht hätten könnte man die halbe Eifel abriegeln.
Zum Glück gibt es das Waldgesetz, nachdem die Besitzer ihre Wege öffentlich zugänglich halten müssen

Es ist keine überflüssige Bürokratie, wenn Genehmigungsprozesse automatisch
in die Kartenverbesserung einfliessen. Z.b. Katasteramt -> Topokarte.
Die Frage ist nur, ob Waldbesitzer überhaupt Änderungen am Wegenetz anzeigen müssen.

Nahmd,

openzzz wrote:

pyram wrote:

3. Eine Privatweg zu "entfernen" sollte niemanden interessieren. Das Anlegen eines "richtigen" Weges ist u.U. genehmigungspflichtig (nicht bei Vermessungsamt). Einen öffentlichen/forstwirtschaftlichen Weg darf kein Privatmensch entfernen.
4. Und bitte nicht noch mehr Bürokratie (offensichtlich bist Du nicht Waldbesitzer).

Ein Waldweg eines Privatwaldes ist kein gewöhnlicher Privatweg.
Es gibt da immer wieder Spaßvögel, die ihre Wälder komplett einzäunen und Fußgänger/Radfahrer aussperren.
Wenn die Recht hätten könnte man die halbe Eifel abriegeln.
Zum Glück gibt es das Waldgesetz, nachdem die Besitzer ihre Wege öffentlich zugänglich halten müssen

Es ist keine überflüssige Bürokratie, wenn Genehmigungsprozesse automatisch
in die Kartenverbesserung einfliessen. Z.b. Katasteramt -> Topokarte.
Die Frage ist nur, ob Waldbesitzer überhaupt Änderungen am Wegenetz anzeigen müssen.

Spätestens wenn ich da langlaufe, sind die Wege inner Karte.

Gruß Wolf

Netzwolf wrote:

Nahmd,
Spätestens wenn ich da langlaufe, sind die Wege inner Karte.
Gruß Wolf

Läufst du im Auftrag des Vermessungsamtes?
In OSM ist ja sowieso schon fast alles drin.

Das Problem sind in amtlichen Karten vor allem Wege, die nicht mehr drin sein sollten, weil
sie schon seit Jahren nicht mehr existieren.

Praktische Konsequenz hat das, wenn du einen Berg herunterfährst und in der Mitte
hört der Weg auf zu existieren. Nochmal den Berg rauf und einen Alternativen Pfad wählen?
Ich hatte mich da für das Tragen des Fahrrades im Wald entschieden.
Auch im tiefen Matsch bin ich schon versunken. Hätte ich auf OSM gehört,
die solche Wege mit "bad" annotiert hatte (laut Garmin OSM-Karte) ...

Gut, meist hab ich OSM schon in OsmAnd auf dem Handy dabei.
Aber das Display kann noch nicht mit dem Riesenpapierdisplay der Wanderkarte mithalten.

Meine Papierkarten und die Top50-CD haben noch das schöne alte Design mit den eingezeichneten Felsen,
offensichtlich von Kartographen manuell hereingesetzt
Das neue Design ist vermutlich vollständig computergeneriert und darum nicht mehr so schön.
Schade. OSM kann es ja auch nicht. In den Bergen bekommt man so leicht einen falschen
Eindruck von der Landschaft.

openzzz wrote:

Netzwolf wrote:

Nahmd,
Spätestens wenn ich da langlaufe, sind die Wege inner Karte.
Gruß Wolf

Läufst du im Auftrag des Vermessungsamtes?

Nö.

Ich laufe im Auftrag des HErrn™.

Gruß Wolf

openzzz wrote:

Ein Waldweg eines Privatwaldes ist kein gewöhnlicher Privatweg.

Ich meinte damit eine Weg, den Du als Weg ansiehst, nur weil der Bauer hier gelegentlich langfährt. Nachdem man einen Wald im Normalfall in jeder Richtung betreten darf (zerstörungsfrei und wildschonend versteht sich), darf man auch alle Arten von Wegen betreten, die damit aber nicht zu "genehmigungspflichtigen Wegen" werden, mit der sich die Bürokratie beschäftigen müsste.

openzzz wrote:

Es gibt da immer wieder Spaßvögel, die ihre Wälder komplett einzäunen

Das ist in D schlicht und ergreifend illegal (außer es dient einer Aufforstung gegen Wildverbiss/wurde im Einzelfall genehmigt).

openzzz wrote:

Es ist keine überflüssige Bürokratie, wenn Genehmigungsprozesse automatisch
in die Kartenverbesserung einfliessen.

Doch, wenn die Datenerhebung nicht erforderlich ist. Überflüssig definiere ich als den Zustand, wenn es auch ohne Probleme Ohne geht - und das tut es seit Jahrzehnten - wie Du richtig erkannt hast ;-). Eine Genehmigung zur Rodung kann genausowenig automatisch in eine Karte einfließen, wie eine Baugenehmigung nicht "automatisch" in die Katasterkarte einfließt (sonst müsste ja kein Messtrupp mehr hinfahren). Das Melden ist Aufwand und das Erfassen in der Karte ist Aufwand.

openzzz wrote:

Die Frage ist nur, ob Waldbesitzer überhaupt Änderungen am Wegenetz anzeigen müssen.

Das kommt darauf an, was hier als Weg zu verstehen ist. Eine Rückeweg lege ich an - oder lasse es bleiben/zuwachsen. Ein Mapper denkt sich hier kann ich lang, das muss ein Weg sein - ist es aber nach Straßen- und Wegegesetz nicht.
In jedem Fall ist das nicht dem Vermessungsamt mitzuteilen.

Ich meinte damit eine Weg, den Du als Weg ansiehst, nur weil der Bauer hier gelegentlich langfährt. Nachdem man einen Wald im Normalfall in jeder Richtung betreten darf (zerstörungsfrei und wildschonend versteht sich), darf man auch alle Arten von Wegen betreten, die damit aber nicht zu "genehmigungspflichtigen Wegen" werden, mit der sich die Bürokratie beschäftigen müsste.

Was sind denn eigentlich die genehmigungspflichtigen Wege?

Mir geht es vor allem um solche Waldwege typischerweise von Radweg-Breite, meistenes nicht asphaltiert, die attraktiv durch die Landschaft führen. Oft in den Bergen hat man dann auch keine Alternativen ohne kilometerweite Umwege zu fahren.

Dumm ist dann nur, wenn so ein Weg auf der Topo-Karte noch eingezeichnet ist, aber bergabwärts irgendwo ins Nirvana führt (da wo er vor 10 Jahren vor der Rodung noch ein Verbindungsweg war).

openzzz wrote:

Es gibt da immer wieder Spaßvögel, die ihre Wälder komplett einzäunen

Das ist in D schlicht und ergreifend illegal (außer es dient einer Aufforstung gegen Wildverbiss/wurde im Einzelfall genehmigt).

Wird aber praktiziert. Der "Solarkönig", Chef der Solarworld AG, hat sich am Rhein ins Calmuther Tal eingekauft
(die alten Filmstudios und der ganze Wald drumherum). Es geht von der Eifel aus den Berg herunter
(Weg auf der Topo-Karte) und dann irgendwann steht man vor einem Zaun und kommt nicht mehr vorbei.
Als ich da langgefahren bin war zufällig noch ein Tor auf.
Wirklich schade, denn der Rheingraben ist an solchen Stellen besonders schön.
Man will doch nicht deswegen alternativ die Landstraße nach Remagen nehmen.

http://www.general-anzeiger-bonn.de/lok … 18695.html

Auch der Haribo-Chef hatte kürzlich seinen Wald eingezäunt.

Natürlich ist das alles illegal. Bei den Behörden kommen sie damit nicht durch und
müssen den Kram wieder abbauen.

Doch, wenn die Datenerhebung nicht erforderlich ist. Überflüssig definiere ich als den Zustand, wenn es auch ohne Probleme Ohne geht - und das tut es seit Jahrzehnten - wie Du richtig erkannt hast ;-). Eine Genehmigung zur Rodung kann genausowenig automatisch in eine Karte einfließen, wie eine Baugenehmigung nicht "automatisch" in die Katasterkarte einfließt (sonst müsste ja kein Messtrupp mehr hinfahren). Das Melden ist Aufwand und das Erfassen in der Karte ist Aufwand.

So oft kommt das ja auch wieder nicht vor, dass sich die Waldwege ändern. (ich meine nicht die temporären Pisten, um das Holz abzuholen). Die Sache ist einfach, dass eine Karte wie die topografische Karte keinen Sinn macht, wenn ein großer Teil der Wege falsch abgebildet ist. In der Eifel und im Rheintal ist die Fehlerquote verdammt hoch.

Wie gesagt, einer der Hauptgründe dass ich primär OSM auf dem Fahrradlenker nutze.

openzzz wrote:

Die Frage ist nur, ob Waldbesitzer überhaupt Änderungen am Wegenetz anzeigen müssen.

Das kommt darauf an, was hier als Weg zu verstehen ist. Eine Rückeweg lege ich an - oder lasse es bleiben/zuwachsen. Ein Mapper denkt sich hier kann ich lang, das muss ein Weg sein - ist es aber nach Straßen- und Wegegesetz nicht.
In jedem Fall ist das nicht dem Vermessungsamt mitzuteilen.

Mit Rückeweg meinst du vermutlich die Wege, die die Forstmaschinen (Harvester, Traktoren etc.) hinterlassen. Die sind sowieso nicht befahrbar, weil die Maschinen den Boden kaputt machen. Und sind wohl eher nicht in der Topo-Karte verzeichnet, oder?

Noch eine Frage: weiss jemand, wie genau die topografischen Karten Wege zeichnen?

Manchmal hatte ich den Eindruck, dass nur die Knotenpunkte exakt vermessen waren
und die Wald/Feldwege dazwischen in künstlerischer Freiheit "gemalt".
Für die sichtbaren Wege kann das Amt die Orthofotos benutzen, aber im Wald?
Da kann ich manche Wege noch nicht einmal im Winterfoto erkennen.

Ob sie dann mit Vermessungs-GPS-Geräten Wege abfahren?
Ich hatte mit GPS in Bergen und dichtem Laubwald oft extreme Ungenauigkeiten
durch Multipath oder Abschattungen.

Ich bin mir nicht sicher, ob ich meiner eigenen GPS-Messung mehr vertrauen
soll oder den Linienzügen aus der amtlichen Topo-Karte.

Es ist sehr praktisch, die Topo-Karten als WMS-Layer in JOSM einzublenden.
Top10/25/50, DGK5, Aerowest Luftbilder, Orthofotos ....

Hallo

Ich möchte nocheinmal darauf hinweisen, das in der Liegenschaftskarte Flächen eingetragen sind. Das schließt Wegerechte (ja Straßen / Wege brauchen eine Fläche) mit ein. Aus der ALK entsteht die DGK5 (erweitert um topographische Merkmale wie Böschungen und Gewässer) und aus der dann die Topographischen Karten diverser Maßstäbe (10k/25k/50k/...)

Nun muss nicht jedes Wegerecht auch genutzt werden. Sei es, dass sich der Bau einfach lange hinzieht (von der Genehmigung bis zur Fertigstellung vergehen gern ein paar Jahre), sei es, dass die Anlage eines Weges schlicht zuviel Aufwand / Kosten bedeutet. Ich muss nur aus meinem Fenster sehen, um eine Stelle mit genau dieser Situation (nur 2 von 5 eingetragenen Wegerechten realisiert) vor mir zu haben.

Auf der anderen Seite fließen auch Änderungen wieder in die Liegenschaftskarte ein. Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.

Edbert (EvanE)

openzzz wrote:

Mit Rückeweg meinst du vermutlich die Wege, die die Forstmaschinen (Harvester, Traktoren etc.) hinterlassen. Die sind sowieso nicht befahrbar, weil die Maschinen den Boden kaputt machen.

Das kann sein, muss aber nicht, wenn man schonend vorgeht... Im Grunde hast du natürlich recht, dass es sich dann eher in die Richtung tracktype=grade5- bewegt.

Ansonsten zur Klarstellung die Rechtslage in Bayern (kann woanders anders sein, wird sich aber im Grundsatz nicht wesentlich unterscheiden):

Art. 57 Abs. 1 BayBO: Verfahrensfrei sind

8. private Verkehrsanlagen einschließlich Brücken und Durchlässen mit einer lichten Weite bis zu 5 m und Untertunnelungen mit einem Durchmesser bis zu 3 m,

Art. 13 Abs. 1 BayWaldG: Das Betreten des Waldes zum Zweck des Genusses der Naturschönheiten und zur Erholung ist jedermann unentgeltlich gestattet...

Art. 13 Abs. 3 BayWaldG: Das Radfahren, das Fahren mit Krankenfahrstühlen und das Reiten ist im Wald nur auf Straßen und geeigneten Wegen zulässig...

Letzteres heißt, dass ich ungeeignete Wege im Wald und den Wald als solchen nicht mit dem Mountainbike beliebig durchqueren darf. Geeignet ist hier aber nicht so zu verstehen, dass man als Maßstab das eigene Können anlegen darf. Unter Anderem ist hier auch zu beachten, dass auch die Ruhe für die Wildtiere geschützt werden soll.

Zum Thema Zaun im Wald: Eine Anfrage/Beschwerde beim zuständigen Amt führt zur Beseitigung des Zaunes.

Siehe auch
http://www.nordbayern.de/region/ansbach … -1.2168987

openzzz wrote:

Noch eine Frage: weiss jemand, wie genau die topografischen Karten Wege zeichnen?

Manchmal hatte ich den Eindruck, dass nur die Knotenpunkte exakt vermessen waren und die Wald/Feldwege dazwischen in künstlerischer Freiheit "gemalt". Für die sichtbaren Wege kann das Amt die Orthofotos benutzen, aber im Wald? Da kann ich manche Wege noch nicht einmal im Winterfoto erkennen.

Ob sie dann mit Vermessungs-GPS-Geräten Wege abfahren?
Ich hatte mit GPS in Bergen und dichtem Laubwald oft extreme Ungenauigkeiten durch Multipath oder Abschattungen.

Ich bin mir nicht sicher, ob ich meiner eigenen GPS-Messung mehr vertrauen soll oder den Linienzügen aus der amtlichen Topo-Karte.

Die Vermesser verwenden keine Consumer-Geräte wie wir.
- Bei unseren Geräten hat man auf freiem Feld (= beste Sichtbarkeit) ca. 3m Genauigkeit.
- Im Wald oder Straßenschluchten sinkt das auf 10m, oft weniger.

Profigräte verwenden zwei Bänder und etliche Korektur-Dienste und kommen damit auch im Wald auf deutlich besser als 1m Genauigkeit. Sie messen übrigens wegen des Körperschattens grundsätzlich in zwei Meter Höhe.

Für die Lage von Waldwege würde ich der DGK5 deutlich mehr trauen als meinem eigenen GPS-Gerät. Die Überprüfung mit Aerowest ergab in den Wegteilen, die dort erkennbar sind, jedenfalls nur sehr geringe Abweichungen. Die Topokarten DTK10 - DTK50 sind zunehmend generalisiert (was du künstlerische Freiheit nennst) und daher als Quelle immer weniger geeignet.

Für Straßen kann man natürlich auch die ALK nehmen. Man muss dabei jedoch beachten, dass die gesamte Breite einschließlich Parkplätzen und Gehwegen in der ALK vermerkt werden. Da ist alles eingetragen, was öffentlicher Grund ist.

Bezüglich der Topokarte ist die Antwort wegen der notwendigen Generalisierung der Karten und der geringen Genauigkeit unserer GPS-Geräte unentschieden. Was auf der ALK eingetragen ist, sollte auf jeden Fall den eigenen Messungen vorgezogen werden. Auch die DGK5 ist in der Regel Lage-genauer als unsere Consumer-Geräte.

Hinweis:
Das alles bezieht sich auf meine Erfahrungen mit ALK/DGK5/DTK10 im Bereich Bonn des Kottenforst. In anderen Gegenden können sich die Verhältnisse von denen in Bonn unterscheiden.

Edbert (EvanE)

"Generalisierung" meinte ich eigentlich nicht. Da weicht man mit Absicht von der realen Linie ab. Ich hatte vermutet, dass manche Wege einfach nur so gezeichnet wurden, ohne den exakten Verlauf überhaupt gemessen zu haben. Also anhand fixer Messpunkte, z.B. an Kreuzungen, unter Mithilfe von Luftbildern. Man sieht die Vermesser öfter mal auf den Straßen mit ihren Triangulationsgeräten (natürlich auch mit GPS-Antennen). Aber ich hatte noch nie gesehen, wie sie kleine Wege gezielt abfahren.

Klar, mit Dual-Band GPS und SBAS wird es genauer, aber bei der Höhenmessung ist GPS doch grundsätzlich zu ungenau, oder? Und bei Multipath/Reflexionen in Bergen hat man auch ganz grundsätzliche Probleme, auch mit den Profigeräten. Kommt der Multipfad über einen 1km-Reflexions-Umweg zustande, so kann der Algorithmus das noch erkennen und ausblenden. Aber bei kürzeren Reflexionen, z.B. 10-100m, sind die dann nicht mehr von einem LOS unterscheidbar, wenn dieser geblockt wird.

Übrigens habe ich gerade das Freizeitkarte WMS Overlay entdeckt:
wms:http://www.wms.nrw.de/geobasis/wms_nw_fzk

In JOSM habe ich diese Transparenzlayer dem OSM Mapnik überlagert.
Sieht wirklich klasse aus, wie die echten Papier-Wanderkarten.

Da fällt auch gleich auf im Vergleich zu http://hiking.waymarkedtrails.org
dass in OSM die Wanderwege noch nicht vollständig erfasst sind.
Oder sind die gar nicht im OSM-Datenbestand, sondern ein externes Overlay?
In waymarkedtrails sind die E-Wanderwege drin, aber nicht die A-Wanderwege
aus dem NRW-Atlas. Dabei sind die kleinen verschlungen Wege gerade
die schöneren. Optisch sehr schön aufbereitet sind auch die Sehenswürdigkeiten
und Aussichtspunkte.
Das müsste man mal für OSM machen ...
(hikebikemap.de mit hiking-symbol overlay kennt auch nur die E-Wege im Wald)

openzzz wrote:

Übrigens habe ich gerade das Freizeitkarte WMS Overlay entdeckt:
wms:http://www.wms.nrw.de/geobasis/wms_nw_fzk

In JOSM habe ich diese Transparenzlayer dem OSM Mapnik überlagert.
Sieht wirklich klasse aus, wie die echten Papier-Wanderkarten.

Da fällt auch gleich auf im Vergleich zu http://hiking.waymarkedtrails.org
dass in OSM die Wanderwege noch nicht vollständig erfasst sind.
Oder sind die gar nicht im OSM-Datenbestand, sondern ein externes Overlay?
In waymarkedtrails sind die E-Wanderwege drin, aber nicht die A-Wanderwege
aus dem NRW-Atlas. Dabei sind die kleinen verschlungen Wege gerade
die schöneren. Optisch sehr schön aufbereitet sind auch die Sehenswürdigkeiten
und Aussichtspunkte.
Das müsste man mal für OSM machen ...
(hikebikemap.de mit hiking-symbol overlay kennt auch nur die E-Wege im Wald)

Nun ja eine ziemlich grobe Sache, aber für den Zweck reicht es wohl.
Wanderwege und Radrouten werden in OSM als Relationen eingetragen. Die wichtigen regionalen / nationalen / internationalen Wander- und Radwege sind in OSM bereits weitgehend vollständig als Relationen eingetragen.

Bei den lokalen Wanderwegen sieht das anders aus. Da braucht man jemand, der sich in der Gegend auskennt und für das Thema interessiert. Das ist nicht überall gegeben. Schließlich muss ein Weg auf seiner Route entsprechend markiert sein, damit man ihn in OSM eintragen kann. Du kannst dir das ja gerne als Projekt für die nächsten Monate vornehmen.

Es gilt:
Nur wenn ein Wander-/Radweg in OSM als Relation eingetragen ist, erscheint es auch bei Waymarked Trails.
Übrigens Dank und Lob an die Erstellerin dieser sehr schönen Karte.

Edbert (EvanE)

Ich habe schon 2 andere Projekte, die mich auslasten. Aber muss man die Wege wirklich nochmal vom Original abzeichnen - das wäre nur nunnötige Doppelarbeit - oder könnte man nicht die Ursprungsdaten auf Basis des Geodatenzugangsgesetzes heranziehen? In Prinzip betreibt OSM ja quasi eine ähnliche Datenbank wie die Behörden selbst. Eine Kooperation würde beiden Seiten nutzen.

Der WMS-Overlay in JOSM sieht ja schon ganz gut aus. Mit "grob" meinst du wahrscheinlich die Liniendicke, nicht? Auf einer normalen Topokarte wäre das natürlich zu fett, aber wenn man die Wanderwege hervorheben will passt das schon ganz gut.

Bei einem Import der Daten sehe ich 2 Probleme:
- die Zustimmung der Behörden
- das Matching der amtlichen Geodaten auf die OSM-Wege

Gibt es hier ein paar Leute mit gutem Draht zum Vermessungsamt (bzw. GEObasis.NRW in der Bez.reg. Köln), die die Daten herausgeben? Wer erstellt die Wanderwege überhaupt, bzw. wer ist dafür verantwortlich? Vielleicht sind sie ja auch froh, wenn jemand die Wanderwege in Karten nutzen will (Förderung des regionalen Tourismus, ...).

Bei den Radwanderwegen gibt es wieder ein eigenes Schema, mit nummerierten Knotenpunkten, die (sagte man mir) auch vor Ort ausgeschildert werden. Daran kann man sich draußen gut orientieren. Das NRW-Radnetz wird hier abgebildet:
http://www.radroutenplaner.nrw.de/

Die offiziellen Vektordaten sind zunächst natürlich nicht an OSM-Objekte gebunden. Man könnte aber sicherlich eine Matching-Funktion schreiben, die eine an OSM-ways gebundene Relation generiert, die eine geringstmögliche Abweichung zum amtlichen Pfad aufweist. Einfaches Optimierungsproblem. Solche Spielereien könnte man auch auf einer lokalen Kopie der OSM-Datenbank durchführen und die fertige Relation auf den OSM-Server aufspielen. Wenn man einmal so etwas gemacht hat, liesse sich das weltweit auf alle möglichen Wanderwege anwenden. Der anfangs höhere Aufwand rentiert sich dann schnell. Außerdem ist die Richtung die, dass Behörden und Organisationen Wanderwege vorgeben und nicht OSM.

Community-Wanderwege gibt es auch (z.B. bei http://www.gpsies.com), aber die sind natürlich draußen nicht ausgeschildert. Außerdem sind da mittlerweile so viele private Laufstrecken drin, dass man die Datenmassen nicht mehr vernünftig auf einer Karte darstellen könnte. In der Zeit wo man dort die ganzen Alternativen durchklickt könnte man schon selbst eine zeichnen (Google Earth -> KML -> GPX -> OsmAnd).

Ich halte weder ein Abzeichnen noch einen Import von Wander- oder Fahrradrouten zur Übernahme in OSM für eine gute Idee, mal abgesehen von den rechtlichen Problemen. Man sollte bei solchen Routen nur erfassen, was man selbst vor Ort überprüft hat. Ich habe es selbst bei von amtlichen Quellen (Geoportal Rheinland-Pfalz oder so ähnlich) heruntergeladenen Touren schon erlebt, dass diese über Wege liefen, die total zugewachsen waren oder gar nicht mehr existierten. Auch die Qualität der Routenführung bei einem Portal wie outdooractive.com ist sehr unterschiedlich, man kann da irgendwo mitten im Wald landen, wo es zumindest auf Wegen nicht mehr weitergeht.
Auch von mir ein Lob an die Ersteller(innen) von waymarked trails, vor allem die zeitnahe Aktualisierung im Stundenbereich ist beeindruckend, man kann so das Ergebnis seiner Eintragungen direkt überprüfen, solange man noch weiß, wo man lang gelaufen(gefahren) ist.

schiki wrote:

Ich halte weder ein Abzeichnen noch einen Import von Wander- oder Fahrradrouten zur Übernahme in OSM für eine gute Idee, mal abgesehen von den rechtlichen Problemen. Man sollte bei solchen Routen nur erfassen, was man selbst vor Ort überprüft hat.
Ich habe es selbst bei von amtlichen Quellen (Geoportal Rheinland-Pfalz oder so ähnlich) heruntergeladenen Touren schon erlebt, dass diese über Wege liefen, die total zugewachsen waren oder gar nicht mehr existierten. Auch die Qualität der Routenführung bei einem Portal wie outdooractive.com ist sehr unterschiedlich, man kann da irgendwo mitten im Wald landen, wo es zumindest auf Wegen nicht mehr weitergeht.
Auch von mir ein Lob an die Ersteller(innen) von waymarked trails, vor allem die zeitnahe Aktualisierung im Stundenbereich ist beeindruckend, man kann so das Ergebnis seiner Eintragungen direkt überprüfen, solange man noch weiß, wo man lang gelaufen(gefahren) ist.

Volle Zustimmung. Man sollte die NRW-Freizeitkarte und andere von OSM nutzbare Karten immer mit der Realität vergleichen. In diesem Fall den lokalen Wanderweg einmal erkunden (ist der z.B. in beide Richtungen ausgeschildert?). Meist lässt sich das für den größten Teil mit dem Fahrrad schnell erledigen.

Dann kann man die Freizeitkarte-NRW in zweierlei Hinsicht nutzen.
- Wo fehlt noch eine lokale Wanderroute?
- Stimmt die Route mit meinen GPS-Track(s) überein?
Wenn der zweite Punkt stimmt, ist die Freizeitkarte-NRW als Hintergrund natürlich eine gute Hervorhebung der betroffenen Wege.

Generell sollte man nichts eintragen, was man nicht selber zumindest grob kennt, oder durch mindestens zwei unabhängige Quellen bestätigt ist. In Bonn nutze ich überwiegend die Aerowest-Bilder insbesondere wegen der guten Qualität, Auflösung und Lagegenauigkeit. Da die jedoch aus dem Jahr 2003 stammen, vergleiche ich immer wieder mit den wesentlich aktuelleren Bing2012 Bildern. Die wiederum haben in Bonn eine mäßige Qualität und wären alleine kaum zu gebrauchen.

Die Karten aus dem NRW-Archiv sind keine unabhängigen Quellen, da sie aufeinander aufbauen.

@openzzz:
Ja ich meinte die Strichbreite. Die liegt natürlich am Maßstab. Ansonsten scheinen die Wanderwege recht gut zu den eingetragenen Wegen zu passen. Die liegen mittig auf den Markierungen.

Edbert (EvanE)

Bitte sauber differenzieren: ich hatte explizit das offizielle Netz von Wanderwegen angesprochen, nicht irgendwelche Routensammlungen von outdooractive, gpsies etc. von Privatleuten. Das erstere wird an den Wegen ausgeschildert und hat quasi offiziellen Charakter. Wer dafür Verantwortlich ist, weiss ich nicht. Zumindest wird es in NRW von Geobasis.NRW amtlicherseits bereitgestellt. An der Orginialquelle sollte man sich orientieren. Man kann das mit GPS-Gerät vor Ort prüfen, aber wer läuft schon die Fernwanderwege komplett lang? Ich bin da meist nur auf Teilabschnitten unterwegs, meist auch nur zufällig weil der Weg attraktiv ist. Auf die Beschilderung achte ich meist nicht. Natürlich müssen die rechtlichen Probleme geklärt werden. Für NRW gibt es eben nun die Erlaubnis, den NRW-Atlas zu nutzen. Warum sollte man es nicht nutzen? Fakt ist, dass die amtlichen Karten an den Meßpunkten eben eine hohe Genauigkeit aufweisen. Mit Consumer GPS-Gerät kannst du bei Multipath in den Bergen um hunderte Meter daneben liegen. Meine GPS-Tracks von den Alpen-Wanderungen sind einfach nur schrottig und nicht zum mappen zu gebrauchen. Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten. Btw: gibt es eigentlich Apps die das können? Ich hatte bei Samsung den Verdacht, dass so etwas gar nicht mehr über die API geliefert wird, also die App auch bei gutem Willen kein NMEA inkl. DOP mehr ausgeben könnte.

Welche Touren vom Geoportal RLP meinst du denn? Ich konnte da keine finden. Auf einer Magic-Maps DVD (amtliche Topo25-Karten) hatte ich mal eine Sammlung von Touren drauf. Das waren nicht die offiziellen Wanderwege, sondern touristische Tourenvorschläge eines Verlages.

Apropos RLP: auf waymarked trails ist der neue 11/2012 eröffnete Ahrsteig schon verzeichnet.
Ich fürchte nur, der ist nicht für Kinderwagen oder für Radfahrer geeignet, oder? Alleine zu Fuß wäre nichts für mich.

EvanE wrote:

Generell sollte man nichts eintragen, was man nicht selber zumindest grob kennt, oder durch mindestens zwei unabhängige Quellen bestätigt ist. In Bonn nutze ich überwiegend die Aerowest-Bilder insbesondere wegen der guten Qualität, Auflösung und Lagegenauigkeit. Da die jedoch aus dem Jahr 2003 stammen, vergleiche ich immer wieder mit den wesentlich aktuelleren Bing2012 Bildern. Die wiederum haben in Bonn eine mäßige Qualität und wären alleine kaum zu gebrauchen.

Ich hatte auch nur die Relation bzw. Markierung als Wanderweg gemeint, nicht die Wege selbst, die schon längst alle kartiert sind.

Und wenn ich die Wanderwege selbst alle ablaufen würde, müsste ich den Wegen auf der Karte mehr vertrauen, denn die Auszeichnung vor Ort ist oft mehr als fragwürdig. Wie oft sind Schilder zugewuchert oder ist es unklar welcher Waldpfad nun gemeint war? Ich habe bisher noch keinen Anlass gesehen, den amtlichen Wanderwegen auf Karten nicht zu trauen. Kartenfehler auf amtlichen Karten kenne ich nur außerhalb der ausgezeichneten Wanderwege. In den Alpen solltest du GPS besser nicht vertrauen. Da gehen ich und mein GPS-Gerät oft sehr getrennte Wege. Zum Glück haben die Topo-Karten auch Abhänge und Schluchten gut verzeichnet, so dass man damit gut den Weg finden kann.

openzzz wrote:

Apropos RLP: auf waymarked trails ist der neue 11/2012 eröffnete Ahrsteig schon verzeichnet.
Ich fürchte nur, der ist nicht für Kinderwagen oder für Radfahrer geeignet, oder? Alleine zu Fuß wäre nichts für mich.

Der Name Ahrsteig lässt vermuten, dass der weder für Kinderwagen noch für Radfahrer vorgesehen ist.

Aber da hängt vieles von den eigenen Fähigkeiten (auch der Leidensfähigkeit) ab.
Statt eines Kinderwagen wäre eine Kindertrage wohl die günstigere Option. Fürs Rad geht wohl nur ein ordentliches Mountainbike mit breiten Reifen und geringem Luftdruck. Zugelassen dürfte Radfahren auf den schmalen Wegen allerdings nicht sein.

Warnung: Leider bin ich den noch nicht gegangen/gefahren, es liegen mir also keine eigenen Erfahrungen vor.
PS: In OSM ist der erst zum Teil erfasst. Die Abschnitte 1 und 2 fehlen ebenso wie die vier Verbindungswege (AV1-AV4) zwischen Kreuzberg und Walporzheim.

Nachtrag: Der Ahrsteig bei Wikipedia.

Edbert (EvanE)

EvanE wrote:

Warnung: Leider bin ich den noch nicht gegangen/gefahren, es liegen mir also keine eigenen Erfahrungen vor.
PS: In OSM ist der erst zum Teil erfasst. Die Abschnitte 1 und 2 fehlen ebenso wie die vier Verbindungswege (AV1-AV4) zwischen Kreuzberg und Walporzheim.
Edbert (EvanE)

Ach, du hast Recht. Jetzt habe ich das mal mit dem GPX-Track von ahrsteig.de verglichen.
Ich dachte A steht für Ahrsteig, aber das gilt nur für das orange A, nicht für das violette.
Das ist auch ein Fußweg, also nicht der Ahrtal-Radweg, darum hatte ich das verwechselt.
Aber eben tiefer gelegen (Ahrschleife und nah am Fluss dran).
Der Ahrsteig geht ja eher ganz oben herum und da fehlt es noch in OSM.

Vom Rheinsteig und Rheinhöhenweg habe ich mal ein paar Abschnitte mit dem
Trekking-Rad gemacht. Das war zwar sehr hügelig, aber schön und machbar.
Immer nur die Täler lang ist ja auch langweilig.
Zumindest ist der Krausberg gut befahrbar, von Dernau aus bis zum Turm.
Ebenso die Weinberge auf der anderen Seite (Rotwein-Wanderweg). Die sind durchzogen
von breiten Wegen, die gut mit dem Rad befahrbar sind.

p.s.: hat schon jemand beim Ahrtal-Tourismus Bad Neuenahr-Ahrweiler e.V. gefragt, ob man deren GPX
für JOSM zum Mappen benutzen darf? Der Download erfolgt zwar über outdooractive.com,
aber als Quelle wird der e.V. genannt, der natürlich Interesse hat, den Tourismus zu fördern.
Wenn die sich stur stellen, würde ich denen erzählen, dass ich auf den teuren Ahr-Wein verzichte
und stattdessen lieber die Mosel-Tour mache. Seitens des Tourismus-Verbandes gibt es ja nur
eine einzige vernünftige Antwort zu dieser Anfrage.

EvanE wrote:

Profigräte verwenden zwei Bänder und etliche Korektur-Dienste und kommen damit auch im Wald auf deutlich besser als 1m Genauigkeit.

Ich hatte mir zuletzt noch einen GPS-Referenzpunkt einmessen lassen. Lagegenauigkeit: 1.6 cm; Höhengenauigkeit ca. 4 cm

openzzz wrote:

Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten.

Die App "GPS Status" zeigt die aktuellen DOP-Werte. Desweiteren gibt es im App-Store mehrere Programm die die NMEA-Werte aufzeichnen (mal nach NMEA suchen).

Gruß Klaus

openzzz wrote:

Weiss eigentlich jemand, wie es um die Aktualität der Waldwege in amtlichen Karten steht? Ich bin eigentlich vor allem deswegen für Radtouren von der Topo-25/50-Karte auf OSM umgestiegen, weil die Topo-Karten bei Waldwegen furchtbar unzuverlässig sind.

Das sieht schlecht aus und es ist mir als Mountainbiker genau so ergangen. Ich verwende jetzt seit Jahren die Karten auf OSM Basis und habe bisher nur wenige Fehler gefunden. Bei Wald- und Feldwegen geht nichts über eine Vor-Ort-Aufnahme hinaus, alles andere ist nur ein rumraten.
Schön das wir jetzt die amtlichen Karten verwenden dürfen, da werde ich bei schlechtem Wetter und Langeweile mal weiter die Häuser hier im Ort erfassen. Die alten Bing Bilder taugen dafür nicht.

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss? ich hab keine lust wenn die jetzt schon soweit gehen das sie die alk zur verfügung stellen, man anfängt abzuzeichnen, und die in einem jahr doch noch ein schritt weiter gehen, und man gezielt daten (gebäudeumrisse) importieren kann. das wär sehr frustrierend.

gibts eigentlich ein tool in josm womit man automatisch einen umriss erkennen lassen kann und josm zeichnen dann automatisch das gebäude? dann müsste man nur noch selber die hausnummer einfügen und fertig.

EvanE wrote:

Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.

Dort ist es als Reitweg eingetragen der kurz nach der Wegkreuzung abbiegt. So hab ich's nun in OSM eingetragen.
Der folgende Weg sollte evntl. gelöscht werden (laut "note" wurde er renaturiert) :
http://www.openstreetmap.org/browse/way/66461915

Chenshi wrote:

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss?

100% nicht.

ABER: wenn wirklich irgendwer (also "die in nrw") einen Import machen wollten, müssten "die" die Spielregeln einhalten und somit das OK der Gemeinschaft abholen. Und das werden "die" nie kriegen, da die ALK bekanntermaßen auch nicht 100% richtig ist. Mach dir mal keine Sorgen. Sowas wie Cascade kommt "uns" nicht in's Haus.

Gruss
walter

ps: bis ich kapiert hatte, was/wen du mit "die in nrw" meintest, brauchte ich einen frischen Kaffee 😉

wambacher wrote:

ps: bis ich kapiert hatte, was/wen du mit "die in nrw" meintest, brauchte ich einen frischen Kaffee 😉

(ich meinte die behörden/vermessungsämter in nrw). aber wenn das so ist wie du schreibst, dann mach ich erstmal im norden von nrw weiter, denn so hoffe ich wird niedersachsen wohl irgendwann nachfolgen. von alk abzeichnen mit luftbilder als kontrolle ist einfacher, als komplett nur von luftbildern abzuzeichnen.

toc-rox wrote:

EvanE wrote:

Profigräte verwenden zwei Bänder und etliche Korektur-Dienste und kommen damit auch im Wald auf deutlich besser als 1m Genauigkeit.

Ich hatte mir zuletzt noch einen GPS-Referenzpunkt einmessen lassen. Lagegenauigkeit: 1.6 cm; Höhengenauigkeit ca. 4 cm

openzzz wrote:

Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten.

Die App "GPS Status" zeigt die aktuellen DOP-Werte. Desweiteren gibt es im App-Store mehrere Programm die die NMEA-Werte aufzeichnen (mal nach NMEA suchen).
Gruß Klaus

Ach klar, den GPS Status hatte ich auch schon gesehen, nur wird der leider nicht mit aufgezeichnet. Um genau zu sein: der zeigt kein DOP, sondern eine metrische Fehlerangabe (keine Ahnung was das ist, vielleicht CEP?), differenziert auch nicht zwischen HDOP und VDOP (Höhen-/Horizontalfehler). Die Höhe ist ja immer das größere Problem in GPS. Ich verstehe nicht, warum DOP bzw. CEP. nicht einfach in das GPX-Log eingebettet wird. Neben der eigentlichen Koordinate ist das für mich schon eine wichtige Angabe, vor allem wenn Geodaten automatisch verarbeitet werden.

Wie war denn im obigen Fall die Laubsituation? Ich habe an den meisten Stellen im Wald auch noch relativ guten Empfang, oft aber auch extreme Abweichungen, an einigen Stellen im Vorgebirge sogar ziemlich verhexte schwarze Löcher, wo ich immer total den GPS Fix verliere (ohne Bergabschattungen, so als ob da jemand einen Störsender betreiben würde). Vielleicht war auch gerade zufällig die Sat-Konstellation ungünstig (komischer Zufall, immer wenn ich zufällig im gleichen Waldstück bin ...).

Übrigens spuckt mein Qualcomm gpsONE Chipset tatsächlich NMEA scentences aus. Ich dachte schon die hätte man wegrationalisiert, weil ich die in Android nirgendwo gesehen hatte. Aber Android hat sogar eine API dafür spendiert: "android.location.GpsStatus.NmeaListener". Ich kannte es nur von früher (zu SIRF-Zeiten), wo NMEA über einen seriellen Port ausgelesen wurde.

Gerade habe ich den "NMEA Recorder" ausprobiert. Tatsächlich ist viel NMEA drin, GPGSV, die DOP-Werte etc.

Schade nur, dass die GPS-Aufzeichnung in den Karten-Apps (OsmAnd, Orux, Locus) das nicht können. Die Multiplex wird zwar funktionieren, dass 2 Apps gleichzeitig auf GPS zugreifen (die KArten App und der Recorder), aber das geht natürlich wieder auf die Akkulaufzeit.

chris66 wrote:

EvanE wrote:

Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.

Dort ist es als Reitweg eingetragen der kurz nach der Wegkreuzung abbiegt. So hab ich's nun in OSM eingetragen.
Der folgende Weg sollte evntl. gelöscht werden (laut "note" wurde er renaturiert) :
http://www.openstreetmap.org/browse/way/66461915

Ich hatte gelesen, dass es in diesem Forst einen ziemlich radikalen Förster gibt, der haufenweise Wege mit Baumstämmen absperrt, die von den Bürgern schon jahrzehntelang genutzt wurden. Sollen die jetzt alle auf den kilomenterlangen schnurgraden asphaltierten Waldpisten laufen? Wofür geht man denn in den Wald, wenn man keinen echten Waldboden mehr unter die Füße bekommt? Für Wildtiere gibt es immer noch genügend Rückzugsgebiete, aber der Wald ist ja auch für Menschen da. Es gab große Proteste von Bürgern, die da schon seit Jahren mit ihrem Hund spazieren gehen. Das Argument dass Leute mit ihren Füßen oder Radfahrer-Rowdies den Boden kaputt machen ist doch lächerlich: derjenige der wirklich den Boden kaputt macht ist der Förster selbst mit seinem Angeber-Geländefahrzeug. Und solche SUVs machen richtig krach im Wald, nicht die Spaziergänger.

Sollten wir es dem Förster leicht machen und die Wege gleich eleminieren. Oder gehen wir mit den Bürgern und lassen die erstmal drin? Man könnte sich einen Kompromiss überlegen: man lässt die Wege drin, solange sie gut passierbar sind und mappen einfach nur die Baum-Barriere. Der resolute Bürger geht sowieso um die Baumstämme herum. An deren Stelle würde ich auch auf das Gewohnheitsrecht beharren. Irgendwie muss man doch protestieren. Wenn die Politiker-Schlappschwänze den Bürgerwillen nicht umsetzen muss man eben mit Füßen abstimmen.

Chenshi wrote:

ich meinte die behörden/vermessungsämter in nrw.

Wieso sollte "die" denn Daten nach OSM importieren? das machen schließlich im Falle eines Falles "wir" und nicht die Ämter/Behörden.

Gruss
walter

openzzz wrote:

Ach klar, den GPS Status hatte ich auch schon gesehen, nur wird der leider nicht mit aufgezeichnet. Um genau zu sein: der zeigt kein DOP, sondern eine metrische Fehlerangabe (keine Ahnung was das ist, vielleicht CEP?), differenziert auch nicht zwischen HDOP und VDOP (Höhen-/Horizontalfehler). Die Höhe ist ja immer das größere Problem in GPS.

Die Kaufversion (sogenannte "löhnware" 🙂) zeigt die aktuellen Werte für DOP/HDOP/VDOP.

Gruß Klaus

PS: Um diesen Thread nicht zu kapern, sollten wir für das Thema einen Neuen eröffnen.

toc-rox wrote:

Die Kaufversion (sogenannte "löhnware" 🙂) zeigt die aktuellen Werte für DOP/HDOP/VDOP.

Oh, dann hatte ich wohl an der falschen Stelle gespart, die Freeware kann es nicht ...

Aber nutzt nichts, wenn das nicht im Recording steht. Ich werd mir nicht auf Papier notieren, wo der Track gut oder schlecht war. Am einfachsten wäre es wohl, den OsmAnd Sourcecode zu patchen, um die Werte dem GPX-Logfile hinzuzufügen.

p.s.:
bei NMEA kann man die schlechten GPS-Punkte mit gpsbabel einfach herausfiltern.
Meist ist es zwar offensichtlich (am gezappele), aber oft hatte ich den Fall (Gebirge), dass
der Track langsam weggedriftet war, so als ob man einen anderen Weg gehen würde.
Die DOPs hatte ich daher bei den alten GPS-Geräten immer mitgeloggt (alle NMEA-sentences im Logger aktiviert).

wambacher wrote:

Wieso sollte "die" denn Daten nach OSM importieren? das machen schließlich im Falle eines Falles "wir" und nicht die Ämter/Behörden.

Gruss
walter

ne, dass die das zum import freigeben, so meinte ich das. wer das macht ist mir auch klar .... sorry ich drück mich öfters so aus das nicht alle gleich mitkommen 🤔

seichter wrote:

die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben.

Gibt es einen zentralen Emailkontakt wo man ALK Fehler melden kann? Oder legt NRW da keinen Wert drauf?
Chris

openzzz wrote:

Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten. Btw: gibt es eigentlich Apps die das können? Ich hatte bei Samsung den Verdacht, dass so etwas gar nicht mehr über die API geliefert wird, also die App auch bei gutem Willen kein NMEA inkl. DOP mehr ausgeben könnte.

Ich nutze auf meinem Smartphone GPSLogger und OSMTracker für Android. Eine der beiden Apps speichert im GPX-Track auch einen DOP-Wert. Diesen DOP-Werte kann man sich in JOSM dann als Kreise um die Trackpunkte anzeigen lassen (muss man in den Eigenschaften des GPX-Layers einschalten).

Wenn ich GPS-Tracks aufzeichnen will, nehme ich jedoch immer noch meine Garmin Dakota 20, da der mit einer Akkuladung deutlich längere Tracks aufzeichnen kann und auch einen besseren GPS-Chip als mein LG Optimus Speed P990 hat.

chris66 wrote:

seichter wrote:

die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben.

Gibt es einen zentralen Emailkontakt wo man ALK Fehler melden kann? Oder legt NRW da keinen Wert drauf?
Chris

Für die ALK sind die jeweiligen unteren Vermessungsbehörden zuständig. Das sind in NRW die Vermessungsämter der Kreise und kreisfreien Städte.

Was für Fehler willst du denn melden?

Siehe oben, z.B. vertauschte Hausnummern.

chris66 wrote:

Siehe oben, z.B. vertauschte Hausnummern.

Schreib mal einfach das zuständige Vermessungsamt an.

Done.

openzzz wrote:

Welche Touren vom Geoportal RLP meinst du denn? Ich konnte da keine finden. Auf einer Magic-Maps DVD (amtliche Topo25-Karten) hatte ich mal eine Sammlung von Touren drauf. Das waren nicht die offiziellen Wanderwege, sondern touristische Tourenvorschläge eines Verlages.

Hatte ich falsch in Erinnerung - war http://www.lvermgeo.rlp.de/index.php?id=5552 - diese Routen dürften so auch in den vom LVERM herausgegebenen Karten erscheinen.

Ich persönlich habe ein paar dieser Wanderrouten nur zum Vergleich mit den entsprechenden in OSM genutzt und die bei OSM öfter mal vorhandenen Lücken oder Verlaufsabweichungen dann vor Ort geklärt.

Chenshi wrote:

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss? ich hab keine lust wenn die jetzt schon soweit gehen das sie die alk zur verfügung stellen, man anfängt abzuzeichnen, und die in einem jahr doch noch ein schritt weiter gehen, und man gezielt daten (gebäudeumrisse) importieren kann. das wär sehr frustrierend.

gibts eigentlich ein tool in josm womit man automatisch einen umriss erkennen lassen kann und josm zeichnen dann automatisch das gebäude? dann müsste man nur noch selber die hausnummer einfügen und fertig.

Um mit Forest Gump zu antworten:
"Das Leben ist wie eine Pralinenschachtel, man weiß nie, was drin ist."
Garantien gibt es keine, aber höchst unwahrscheinlich ist es dennoch.

[Umrisse erkennen]: Microsoft hat so etwas mal für Luftbilder entwickelt, mit nur Schwarz und Weiß sollte das gut funktionieren, wenigstens für alleinstehende Gebäude. Der viel interessantere Fall "Wand an Wand" wird wohl deutlich schlechter funktionieren. Und bei dem Fall, dass das mittlere von drei Häusern auf zwei extraschmalen Grundstücken steht, wird es wohl endgültig versagen.

Viel interessanter fände ich die Möglichkeit, Nummern zu extrahieren, zum Beispiel automatisch die Höhenangaben zu finden.

Edbert (EvanE)

openzzz wrote:

bei NMEA kann man die schlechten GPS-Punkte mit gpsbabel einfach herausfiltern.
Meist ist es zwar offensichtlich (am gezappele), aber oft hatte ich den Fall (Gebirge), dass
der Track langsam weggedriftet war, so als ob man einen anderen Weg gehen würde.
Die DOPs hatte ich daher bei den alten GPS-Geräten immer mitgeloggt (alle NMEA-sentences im Logger aktiviert).

Auch wenn ich damit vom eigentlichen Thema ziemlich abweiche, ein Kommentat zu dieser Aussage:
Ich nutze mehrere GPS-Logger gleichzeitig und kann dadurch Ausreisser ziemlich gut identifizieren (es machen nie alle gleichzeitig Seitensprünge und wenn unvermeidlich (Tunnel), nie gleichartig). Nach meiner Erfahrung sind VDOP und HDOP nur bedingt als Qualitätsanzeiger geeignet. Das sind Werte, die die Firmware formal berechnet, die aber nur wenig mit tatsächlichem Fehlerbereich zu tun haben. Als besserer Indikator hat sich die Höhe herausgestellt. Es gibt keinen geometrischen Grund, weshalb die Höhe schlechter sein sollte als die horizontalen Werte. Sie wird nur längst nicht so stark durch die Firmware geglättet wie die horizontalen Koordinaten. Wenn es da unmotivierte Höhenänderungen gibt, ist fast immer auch der horizontale Track auf Abwegen.
Es lohnt sich also, einen Blick auf die Höhen zu werfen, die DOP-Werte haben bei mir ausgedient.

Chenshi wrote:

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss? ich hab keine lust wenn die jetzt schon soweit gehen das sie die alk zur verfügung stellen, man anfängt abzuzeichnen, und die in einem jahr doch noch ein schritt weiter gehen, und man gezielt daten (gebäudeumrisse) importieren kann. das wär sehr frustrierend.

gibts eigentlich ein tool in josm womit man automatisch einen umriss erkennen lassen kann und josm zeichnen dann automatisch das gebäude? dann müsste man nur noch selber die hausnummer einfügen und fertig.

Bei einem automatische Import egal ob per Datei oder per Vektorisierung fehlt gerade der Mensch als Filter. Ich bezweifle z.B. ein wenig, dass die frei verfügbaren Katasterdaten in NRW die tagesaktuellen Daten sind. Für die muss man nämlich in der Regel zahlen.
Bei Maps4W hinken die Gebäudeumrisse, da wo ich es überprüfen kann, um ein bis drei Jahre hinterher.

chris66 wrote:

EvanE wrote:

Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.

Dort ist es als Reitweg eingetragen der kurz nach der Wegkreuzung abbiegt. So hab ich's nun in OSM eingetragen.
Der folgende Weg sollte evntl. gelöscht werden (laut "note" wurde er renaturiert) :
http://www.openstreetmap.org/browse/way/66461915

Die Variante mit dem Reitweg ist mir neu. Gut, dass der Weg wenigsten weiter genutzt wird. Ich muss mir das also nochmal ansehen.
Die Reiter haben es im Kottenforst mit einem allgemeinen Reitverbot auf nicht explizit gekennzeichneten Wegen sowieso schwer.

Ich bin bei meiner Besichtigung bis zu der Stelle gegangen, wo der Einschnitt abgeht (bei der 162m Höhen-Marke). Es war mir aber zu unsicher, ob man da noch irgendwo hin kommt und so bin ich lieber umgekehrt.

Einen Punkt möchte ich noch ansprechen:
Laut Key:ele stehen in ele=* Höhenangaben nach WGS84. Das macht natürlich keiner. Deswegen habe ich mir direkt angewöhnt, alles was ich aus der DGK5 entnehme mit ele:DHHN92 [1] als Schlüssel einzutragen. Dann ist wenigstens klar, auf welches Referenz-System ich mich beziehe. Ich möchte allen Mappern empfehlen das Gleiche zu machen. Ansonsten stehen (wie bereits heute) Werte nach allen möglichen Referenz-Systemen ununterscheidbar im Tag ele. Einen Wert nach WGS84 würde ich konsequent mit ele:WGS84 erfassen.

[1]: DHHN92 bedeutet Deutsches Haupt Höhen Netzwerk 1992. (Wichtig: Zwei "H" ein "N".)

Den Bergmannspfad sollte man ruhig lassen, wie er ist. Einerseits ist die frühere Schneise noch gut zu erkennen, andererseits ist er ohne erkennbare Beschränkung in der DGK5 und auch der DTK10 enthalten und würde daher regelmäßig wieder auftauchen. Bei uns sieht man wenigstens, dass der Weg nicht mehr benutzt werden soll/kann/darf.

[OT]: Heute habe ich eine schicke Erkundungstour gemacht. Unter anderem bin ich meinen ersten Weg gegangen, der damals noch nicht eingetragen war (ich muss noch ein wenig daran feilen). Zum Schluss bin ich mit dem Rad eine schöne, enge, steile Strecke gefahren, bei dir ich früher mal wegen Begleitung das Rad runter schieben musste.

Gefühlt schon Mitternacht
Edbert (EvanE)

EvanE wrote:

Einen Punkt möchte ich noch ansprechen:
Laut Key:ele stehen in ele=* Höhenangaben nach WGS84. Das macht natürlich keiner. Deswegen habe ich mir direkt angewöhnt, alles was ich aus der DGK5 entnehme mit ele:DHHN92 [1] als Schlüssel einzutragen. Dann ist wenigstens klar, auf welches Referenz-System ich mich beziehe. Ich möchte allen Mappern empfehlen das Gleiche zu machen. Ansonsten stehen (wie bereits heute) Werte nach allen möglichen Referenz-Systemen ununterscheidbar im Tag ele. Einen Wert nach WGS84 würde ich konsequent mit ele:WGS84 erfassen.

Na, was heißt empfehlen? Das ist Pflicht, falls von WGS84 abweichende Systeme benutzt werden. Ansonsten wäre das eine Falschinformation. Bestenfalls darf man noch "ele:local=" schreiben, was sich auf das "lokale" System bezieht, bei uns eben das DHHN92. Für die automatische Auswertung ist das schon wichtig, damit die Werte entsprechend Normalisiert werden können, z.B. für 3D-Karten. Aber dafür ist vermutlich noch zu wenig Höhe getaggt, oder? Wenn das zu lückenhaft ist muss man dann doch auf externe Quellen wie STRM zurückgreifen.

schiki wrote:

Hatte ich falsch in Erinnerung - war http://www.lvermgeo.rlp.de/index.php?id=5552 - diese Routen dürften so auch in den vom LVERM herausgegebenen Karten erscheinen.

Ich persönlich habe ein paar dieser Wanderrouten nur zum Vergleich mit den entsprechenden in OSM genutzt und die bei OSM öfter mal vorhandenen Lücken oder Verlaufsabweichungen dann vor Ort geklärt.

Ok, du meinest also eine Touren-Sammlung. Das muss vom "offiziellen" Wanderwegenetz unterschieden werden, das vor Ort ausgeschildert wird. Manche Touren gehen zwar entlang dieser Wanderwege, aber es gibt eben auch viele andere Tourenvorschläge abseits dieser Wege. Die werden sicherlich auch nicht alle auf der normalen Topo-Karte erscheinen. Dazu gibt es dann redaktionell bearbeitete Spezialausgaben wie die "Traumpfade",mit Sonderkarten dafür.

Mit Übernahme in OSM hatte ich vorhin ausschließlich die offiziellen Wanderwege angesprochen. Die sind gut geeignet zur Produktion von OSM-Wanderkarten. Ich denke wenn man OSM als Tourendatenbank ausbaut wird das schnell sehr unübersichtlich mit den vielen Relations. Und bei Tourenportalen wie Gpsies.com ist auch viel Müll drin, den ich in keiner Karte sehen möchte. Da läd ja quasi jeder Freizeitjogger seine Privattouren ab. Ob die von Allgemeinem Interesse sind, naja. Natürlich gibt es da auch schöne Touren. Bei der Masse dort sind die aber schwierig zu finden.

Prinzipiell wäre es natürlich eine schöne Idee, ein Tourenportal auf OSM-Basis auf die Beine zu stellen. Ein einfacher Overlay geht natürlich immer. Aber wenn die Touren auf OSM-Objekte bauen sollen, stelle ich mir die Datenbankkopplung schwierig vor.

seichter wrote:

Auch wenn ich damit vom eigentlichen Thema ziemlich abweiche, ein Kommentat zu dieser Aussage:
Ich nutze mehrere GPS-Logger gleichzeitig und kann dadurch Ausreisser ziemlich gut identifizieren (es machen nie alle gleichzeitig Seitensprünge und wenn unvermeidlich (Tunnel), nie gleichartig). Nach meiner Erfahrung sind VDOP und HDOP nur bedingt als Qualitätsanzeiger geeignet. Das sind Werte, die die Firmware formal berechnet, die aber nur wenig mit tatsächlichem Fehlerbereich zu tun haben. Als besserer Indikator hat sich die Höhe herausgestellt. Es gibt keinen geometrischen Grund, weshalb die Höhe schlechter sein sollte als die horizontalen Werte. Sie wird nur längst nicht so stark durch die Firmware geglättet wie die horizontalen Koordinaten. Wenn es da unmotivierte Höhenänderungen gibt, ist fast immer auch der horizontale Track auf Abwegen.
Es lohnt sich also, einen Blick auf die Höhen zu werfen, die DOP-Werte haben bei mir ausgedient.

Ich haber auch noch einen kleinen GPS-Logger, mit besserem Chip. Nur AGPS hat er nicht, ist also nicht so schnell Betriebsbereit wie das Handy. Manchmal hab ich dann auch 2 Geräte mit, aber meistens ist es mir doch zu lästig.

In den Bergen korrelieren die Fehler aber doch oft. Das liegt dann einfach an der Abschattung und an Reflexionen. Davon sind dann alle GPS-Empfänger gleichermaßen betroffen. Die Kalman-Filter können u.U. bei schlechtem Empfang auch mal in verschiedene Richtungen abdriften.

Natürlich sind HDOP, VDOP, PDOP und GDOP noch keine endgültige Aussage über die Qualität. Die sagen erstmal nur etwas über den geometriebedingten Fehler aus, über die zu erwartende Varianz-Erhöhung bezüglich Varianz einer einzelnen Pseudorange-Bestimmung. So kann man dann auch wieder auf metrische Einheiten kommen. Was DOP aber nicht ausdrückt sind Fehler der Pseudorange-Messung selbst, also Multipath, schwache verrauschte Signale. Solche Fehler kann der Chip auch schlecht abschätzen. Die Meter-Angabe in GPS-Status ist daher vermutlich auch nur ein HDOP, der mit einem Default-Wert für den üblichen Pseudorange-Jitter multipliziert wurde. Was neben DOP noch hilft sind die SNR-Angaben zu den Sat-Signalen. Mehr Zuverlässigkeits-Infos wirst du da nicht herausbekommen.

Die Höhe ist meist aber doch schlechter aufgelöst. Das liegt an der Geometrie. Wenn alle Satelliten in einer Ebene liegen würden, könnte man die Höhe so gut wie überhaupt nicht mehr bestimmen. Die Matrix der Pseudoinverse in der Navigationsgleichung bekommt dann einer sehr schlechte Kondition. Die Sats verteilen sich nun auf einer Fläche einer Kugelschale auf einem 20000km-Orbit. Die ist natürlich etwas krumm, was dann eine gewisse Höhenbestimmung ermöglicht, aber doch noch eher flächig, da Satelliten niedriger Elevation nicht mehr zu empfangen sind. Das hängt aber von der momentan-Konstallation ab. Meist ist der VDOP so aus geometrischen Gründen schlechter. Die Diskrepanz zwischen HDOP und VDOP wird noch größer in hohen Breiten, weil die GPS-Orbits nur um 55° inkliniert sind, also noch weniger Sats überm Kopf fliegen, um die 3. Dimension aufzuspannen. Zum Glück sind solche Geometriefehler gut berechenbar und daher auch die DOP als solche sehr exakt. Was bei der Höhe noch dazukommt: die Beulen der Erde im Vergleich zum WGS84-Referenzellipsoiden. Der Ellipsoid ist dank dem Internationaler Erdrotationsdienst gut bestimmt. Die Beulen der Erde müssen aber separat kartiert und kompensiert werden.

openzzz wrote:

EvanE wrote:

Einen Punkt möchte ich noch ansprechen:
Laut Key:ele stehen in ele=* Höhenangaben nach WGS84. Das macht natürlich keiner. Deswegen habe ich mir direkt angewöhnt, alles was ich aus der DGK5 entnehme mit ele:DHHN92 [1] als Schlüssel einzutragen. Dann ist wenigstens klar, auf welches Referenz-System ich mich beziehe. Ich möchte allen Mappern empfehlen das Gleiche zu machen. Ansonsten stehen (wie bereits heute) Werte nach allen möglichen Referenz-Systemen ununterscheidbar im Tag ele. Einen Wert nach WGS84 würde ich konsequent mit ele:WGS84 erfassen.

Na, was heißt empfehlen? Das ist Pflicht, falls von WGS84 abweichende Systeme benutzt werden. Ansonsten wäre das eine Falschinformation. Bestenfalls darf man noch "ele:local=" schreiben, was sich auf das "lokale" System bezieht, bei uns eben das DHHN92. Für die automatische Auswertung ist das schon wichtig, damit die Werte entsprechend Normalisiert werden können, z.B. für 3D-Karten. Aber dafür ist vermutlich noch zu wenig Höhe getaggt, oder? Wenn das zu lückenhaft ist muss man dann doch auf externe Quellen wie STRM zurückgreifen.

Wie so oft, sind das auf einer Wiki-Seite beschriebene Soll und die gelebte Mapper-Praxis zwei verschiedene Dinge. Es ist nun einmal viel einfacher nur ele=* zu schreiben, als sich über das Referenz-System Gedanken zu machen.

Berge sind in der Regel nur mit ele=* erfasst. Und ich wage zu bezweifeln dass von deren Werte überhaupt welche nach WGS84 erfasst sind. Eher stammen die von lokalen Infotafeln oder aus der Wikipedia (auch nach lokalem Referenz-System).

Allgemein bin ich der Meinung, dass man die Wikiseite Key:ele an die Mapping-Praxis anpassen sollte, also das mit ele=* eine Höhenangabe nach lokaler Info und Referenz-System verstanden wird. Die Forderung die Höhenangaben nach WGS84 umzurechnen, werden nur die wenigsten erfüllen können / wollen. Höhenangaben nach WGS84 sollten dann mit ele:WGS84=* kenntlich gemacht werden.

PS-1: Trägt jemand außer mir systematisch Höhen nach der NRW-Atlas DGK5 ein?
PS-2: Nutzt denn jemand in seinen 3D-Renderer Höhenangaben in OSM für das Terrain?
PS-3: Wie groß ist der Unterschied zwischen DHHN12 (alte Bundesländer), SNN76 (neue Bundesländer) und dem gemeinsamen DHHN92 nach 1992?

Edbert (EvanE)

EvanE wrote:

PS-3: Wie groß ist der Unterschied zwischen DHHN12 (alte Bundesländer), SNN76 (neue Bundesländer) und dem gemeinsamen DHHN92 nach 1992?

Da lässt sich kein eindeutiger Wert festlegen. Vergleiche:http://de.wikipedia.org/wiki/Deutsches_ … %B6hennetz und hier den Abschnitt Vergleich der Systeme Deutschlands.

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

Ergänzung: siehe auch: http://www.bkg.bund.de/nn_175422/DE/Bun … __nnn=true

Sven

streckenkundler wrote:

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

Sven

Ein Blick in die englische Wiki http://wiki.openstreetmap.org/wiki/Key:ele macht einiges klarer:
Elevation (height above sea level) of a point in metres. This is mainly intended for mountain peaks but could also be used for elevation of airport runways and many other objects. For OpenStreetMap, please use the elevation above sea level defined by the World Geodetic System, revision WGS 84.

edit: link

hurdygurdyman wrote:

Ein Blick in die englische Wiki...

ja, ja, jetzt erinnere ich mich. Die ele-Disskussion hatten wir schon mal... Gut.
Vorausgesetzt, daß jeder Mapper, die WGS84-Höhe (über "sea level") auch verwendet, dann wäre die Angabe natürlich auch verwendbar. Ich befürchte jedoch, daß die Mapper-Realität anders aussieht: Mapper besteigt einen Berg findet eine Tafel mit dem Namen und der Höhe des Berges vor. Macht mit seinem GPS einen Wegepunkt. Mapper hat nun zwei Zahlen: die der Tafel (sicherlich keine WGS84- Höhe) und die des GPS (barometrische Höhenmessung und daher eh zu ungenau). Welche soll er verwenden? 🤔

Sven

openzzz wrote:

Die Höhe ist meist aber doch schlechter aufgelöst. Das liegt an der Geometrie. Wenn alle Satelliten in einer Ebene liegen würden, könnte man die Höhe so gut wie überhaupt nicht mehr bestimmen. Die Matrix der Pseudoinverse in der Navigationsgleichung bekommt dann einer sehr schlechte Kondition. Die Sats verteilen sich nun auf einer Fläche einer Kugelschale auf einem 20000km-Orbit. Die ist natürlich etwas krumm, was dann eine gewisse Höhenbestimmung ermöglicht, aber doch noch eher flächig, da Satelliten niedriger Elevation nicht mehr zu empfangen sind. Das hängt aber von der momentan-Konstallation ab. Meist ist der VDOP so aus geometrischen Gründen schlechter. Die Diskrepanz zwischen HDOP und VDOP wird noch größer in hohen Breiten, weil die GPS-Orbits nur um 55° inkliniert sind, also noch weniger Sats überm Kopf fliegen, um die 3. Dimension aufzuspannen.

Entscheidend für den Höhenfehler ist nicht der Radius der Kugelschalen (Fläche gleicher Entfernung), sondern der Winkel der Schalen an den Schnittflächen zueinander, sprich die Position der Satelliten zueinander. Stehen die Satelliten nahe beieinander, ist das Ergebnis in allen Dimensionen schlecht, stehen sie in einer Linie, ist das Ergebnis in Richtung dieser Linie gut, in der Fläche senkrecht dazu schlecht. Für die dritte Dimension braucht man keinen Satellit über Kopf, zwei auf 45 und -45 Grad reichen genauso. In hohen Breiten hat man zu selten (oder überhaupt nicht) Satelliten in der optimalen 90-Grad-Konstellation.
Natürlich kann es bei schlechten Bedingungen (Schluchten, Reflexionen etc) vorkommen, dass alle Logger Unfug ausrechnen. Mir ist es bei inzwischen Tausenden von Kilometern simultaner Tracks aber noch nie vorgekommen, dass diese Ausreisser bis auf wenige Meter übereinstimmten.

streckenkundler wrote:

...
Vorausgesetzt, daß jeder Mapper, die WGS84-Höhe (über "sea level") auch verwendet, dann wäre die Angabe natürlich auch verwendbar. Ich befürchte jedoch, daß die Mapper-Realität anders aussieht: Mapper besteigt einen Berg findet eine Tafel mit dem Namen und der Höhe des Berges vor. Macht mit seinem GPS einen Wegepunkt. Mapper hat nun zwei Zahlen: die der Tafel (sicherlich keine WGS84- Höhe) und die des GPS (barometrische Höhenmessung und daher eh zu ungenau). Welche soll er verwenden? 🤔

Da magst du teilweise recht haben, dass die Mapper-Realität anders aussieht. Allerdings unterstelle ich jetzt einfach mal (,da ich an das gute im Menschen glaube), dass der gewissenhafte Mapper vor Verwendung eines key/value-Paares für ihm bis dahin nicht vertraute Sachverhalte vesucht, sich in der Wiki schlau zu machen und somit für ele=* die richtige Beschreibung findet und anwendet.

hurdygurdyman wrote:

Allerdings unterstelle ich jetzt einfach mal (,da ich an das gute im Menschen glaube), dass der gewissenhafte Mapper vor Verwendung eines key/value-Paares für ihm bis dahin nicht vertraute Sachverhalte vesucht, sich in der Wiki schlau zu machen und somit für ele=* die richtige Beschreibung findet und anwendet.

Hier bietet Wiki ja eben die Möglichkeit, "ele:xyz=123" anzugeben. wiobei xyz gleich einem Kartendatum ist (korrekter wäre es Höhenreferenz-System zu sagen). Ich schlage vor im Wiki eine Liste eine dieser Höhenreferenzsysteme mit einer kurzen Angabe zur Verwedung und Verbreitung zu erstellen.
Taginfo kennt nur 48 verschiedene ele:xyz-Werte (Stand 28.10.2013 14:25 Uhr) von denen einige auf unterschiedliche Schreibweisen beruhen.

Sven

EvanE wrote:

Wie so oft, sind das auf einer Wiki-Seite beschriebene Soll und die gelebte Mapper-Praxis zwei verschiedene Dinge. Es ist nun einmal viel einfacher nur ele=* zu schreiben, als sich über das Referenz-System Gedanken zu machen.

Berge sind in der Regel nur mit ele=* erfasst. Und ich wage zu bezweifeln dass von deren Werte überhaupt welche nach WGS84 erfasst sind. Eher stammen die von lokalen Infotafeln oder aus der Wikipedia (auch nach lokalem Referenz-System).

Allgemein bin ich der Meinung, dass man die Wikiseite Key:ele an die Mapping-Praxis anpassen sollte, also das mit ele=* eine Höhenangabe nach lokaler Info und Referenz-System verstanden wird. Die Forderung die Höhenangaben nach WGS84 umzurechnen, werden nur die wenigsten erfüllen können / wollen. Höhenangaben nach WGS84 sollten dann mit ele:WGS84=* kenntlich gemacht werden.

Das finde ich aber sehr bedenklich, wenn "in der Praxis" falsche Angaben gemacht werden. Das wäre so, als würde man falsche Koordinaten eintragen, z.B. Easting-Northing statt Längen/Breitengrad. Wenn Daten automatisch verarbeitet werden geht das nicht. Wenn da keine Grad stehen kann man das noch erkennen, aber falsche Höhenangaben fallen auf der 2D-Karte eben nicht auf, obwohl die doch sehr verschieden sind, immerhin 47 Meter. In den Alpen sind das vielleicht Peanuts, aber im Flachland oder Vorgebirge ist das schon deutlich. Im Prinzip sind dann quasi alle Höhenangaben wertlos, wenn man nicht weiss nach welchem System gemappt wurde. Ich erinnere mich an ähnliche Diskrepanzen zwischen Gauß-Krüger Grad und WGS84 Grad. Das wäre auch eine Abweichung die schlimm ist (100m?), aber beim Blick auf den Zahlenwert noch nicht unmittelbar auffällt.

Man kann auch nicht für Deutschland Sonderregeln aufstellen. Das müsste für OSM weltweit einheitlich sein. Einheitlich geht nur mit WGS84. Es ist ja nicht schlimm, wenn jemand die DHHN92-Höhe einträgt, die auf amtlichen Topokarten bzw. im Alltag üblich ist. Aber das muss man wirklich kennzeichnen. Wer DHHN nicht aussprechen kann, der darf ruhig ele:local= schreiben. Bei der automatischen Verarbeitung wird das dann schon automatisch umgerechnet. Es fehlt wohl eher noch Aufklärungsarbeit, vielleicht ein Warn-Popup für JSOM-Anfänger. Oder dass JOSM und der Webeditor einfach gezielt nach dem System fragen. Dann würde der Mapper wenigstens sofort sehen, dass er eine falsche Angabe macht.

Wenn in der OSM-Datenbank so viele falsche Werte schlummern, müsste man das mal systematisch korrigieren. Wegwerfen wäre die radikale Methode. Oder man extrahiert alle Höhenwerte aus der Datenbank und vergleicht mit den STRM-Höhendaten. Dann könnte man automatisch erkennen lassen, ob der Wert näher am WGS84 oder am DHHN liegt. Da die STRM-Daten auch manchmal daneben liegen müsste man wohl nochmal prüfen ob das auch stimmt. Ich vermute es gibt noch nicht viele Höhen in OSM, weil man meist in 2D arbeitet. Außerdem vertraue ich meinem GPS-Gerät bei der Höhe sowieso nicht - aus Erfahrung.

streckenkundler wrote:

hurdygurdyman wrote:

Ein Blick in die englische Wiki...

ja, ja, jetzt erinnere ich mich. Die ele-Disskussion hatten wir schon mal... Gut.
Vorausgesetzt, daß jeder Mapper, die WGS84-Höhe (über "sea level") auch verwendet, dann wäre die Angabe natürlich auch verwendbar. Ich befürchte jedoch, daß die Mapper-Realität anders aussieht: Mapper besteigt einen Berg findet eine Tafel mit dem Namen und der Höhe des Berges vor. Macht mit seinem GPS einen Wegepunkt. Mapper hat nun zwei Zahlen: die der Tafel (sicherlich keine WGS84- Höhe) und die des GPS (barometrische Höhenmessung und daher eh zu ungenau). Welche soll er verwenden? 🤔
Sven

Ich denke die Höhe auf der Tafel sollte korrekter sein und aus der Landvermessung (Triangulation) stammen.
Andererseits ist GPS auf der Bergspitze auch realtiv gut, weil da oben mehr Satelliten zu sehen sind.

Beachte diesen Satz aus dem Wiki
"The elevation in a local datum can be tagged as ele:local=*, with elevation specified in meters."

Das ist doch einfach, oder?

streckenkundler wrote:

Vorausgesetzt, daß jeder Mapper, die WGS84-Höhe (über "sea level") auch verwendet, dann wäre die Angabe natürlich auch verwendbar. Ich befürchte jedoch, daß die Mapper-Realität anders aussieht: Mapper besteigt einen Berg findet eine Tafel mit dem Namen und der Höhe des Berges vor. Macht mit seinem GPS einen Wegepunkt. Mapper hat nun zwei Zahlen: die der Tafel (sicherlich keine WGS84- Höhe) und die des GPS (barometrische Höhenmessung und daher eh zu ungenau). Welche soll er verwenden? hmm

Hier in Mitteleuropa weicht die Höhe der lokalen "Kartoffelschale" von WGS84 um etwa 40 m ab. So etwas ist unvermeidlich, da das Referenzellisoid von WGS84 weltweit gelten muss, also überall von einer lokal optimalen Näherung abweicht (sogar die Senkrechte hat einen Fehler). Manche GPS-Geräte korrigieren diese Abweichung automatisch, bei manchen lässt es sich einstellen, bei anderen weiß man es nicht.
Die Angabe im Wiki finde ich für die Höhe etwas an der Praxis vorbei. Was in der Ebene sehr sinnvoll ist (nur ein Längen-/Breitensystem weltweit), ist in der Höhe nicht so praktikabel. Es wird mit Sicherheit noch sehr lange dauern, bis an allen Aussichtspunkten die lokale und die WGS84-Höhe aufgeführt werden. Ob sich die Deichanlieger damit anfreunden können, dass der Meeresspiegel z.B. zwischen -30 und -25 m bei Ebbe und Flut wechselt, scheint mir auch zweifelhaft. Das ist zwar für eine weltweites System unbefriedigend, da ein Grenzgipfel da zwei Höhen haben kann, aber sonst sind entweder Adria oder Nordsee (oder beide) nicht auf Höhe 0. Mit Länge und Breite hat man dieses Nullproblem nicht, außer man steht gerade in Greenwich auf dem in den Boden eingelassenen Nullmeridian.
Mit Einträgen von ele:xy=* hätte ich keine Problem.
Barometrische Höhenmessung ist übrigens so schlecht nicht, wenn zu Beginn mit einer bekannten Höhe kalibriert und der meteorologische Luftdruck (Sturmtief) sich nicht zu schnell verändert. Das läuft auf eine Differenzmessung hinaus und über WGS84-Höhen braucht man sich nicht den Kopf zu zerbrechen.

openzzz wrote:

Wer DHHN nicht aussprechen kann, der darf ruhig ele:local= schreiben.

Das wäre genau so falsch. ele:local=... sagt nur noch aus, daß es eine lokale Höhenangabe ist, aber nicht nach welchem System. Da müsstest du mit local=... den lokalen Bezugspunkt mit angeben. Angaben mit ele:local=... sollten weitesgehend vermieden werden, da die ohne Angabe des lokalen Bezugspunktes wertlos.

Taginfo (28.10.2013, 14:45Uhr):
ele:local=1348 mal
local=... 15 mal
Das sind 1333 nicht definierbare lokale Höhenangaben.

Wenn, dann ele:DHHN92=... oder ele:NHN=... ich würde ersteres bevorzugen.

openzzz wrote:

Außerdem vertraue ich meinem GPS-Gerät bei der Höhe sowieso nicht - aus Erfahrung.

+1

Sven

seichter wrote:

Entscheidend für den Höhenfehler ist nicht der Radius der Kugelschalen (Fläche gleicher Entfernung), sondern der Winkel der Schalen an den Schnittflächen zueinander, sprich die Position der Satelliten zueinander. Stehen die Satelliten nahe beieinander, ist das Ergebnis in allen Dimensionen schlecht, stehen sie in einer Linie, ist das Ergebnis in Richtung dieser Linie gut, in der Fläche senkrecht dazu schlecht. Für die dritte Dimension braucht man keinen Satellit über Kopf, zwei auf 45 und -45 Grad reichen genauso. In hohen Breiten hat man zu selten (oder überhaupt nicht) Satelliten in der optimalen 90-Grad-Konstellation.
Natürlich kann es bei schlechten Bedingungen (Schluchten, Reflexionen etc) vorkommen, dass alle Logger Unfug ausrechnen. Mir ist es bei inzwischen Tausenden von Kilometern simultaner Tracks aber noch nie vorgekommen, dass diese Ausreisser bis auf wenige Meter übereinstimmten.

Mit 2 Satelliten bekommst du schon mal gar keine Ortung hin. Für die 2D-Ortung sind mindestens 3, für die 3D-Ortung mindestens 4 Satelliten notwendig. Ich gehe davon aus, dass du keine Atomuhr mitschleppst. Aber selbst die (tragbaren) Rubidium-Atomuhren driften dir relativ schnell weg. Darum werden die selbst nochmal über GPS stabilisiert. Es gibt eben 4 Unbekannte in der Navigationsgleichung (incl. dem unbekannten Zeitoffset zur Receiver-Uhr).

Natürlich muss es nicht ein Satellit überm Kopf sein, aber in hohen Breiten fliegen die einfach tendenziell zu tief und darum ist die Diskrepanz zwischen HDOP und VDOP dort größer.

Hier wird die GPS-Genauigkeit gut erklärt:
http://wiki.openstreetmap.org/wiki/DE:G … _GPS-Daten

Die HDOP vs. VDOP-Thematik wurde mal in einem Artikel in der GPS World erklärt:
http://gauss.gge.unb.ca/papers.pdf/gpsworld.may99.pdf
(Seite 56 rechts unten)

streckenkundler wrote:

openzzz wrote:

Wer DHHN nicht aussprechen kann, der darf ruhig ele:local= schreiben.

Das wäre genau so falsch. ele:local=... sagt nur noch aus, daß es eine lokale Höhenangabe ist, aber nicht nach welchem System. Da müsstest du mit local=... den lokalen Bezugspunkt mit angeben. Angaben mit ele:local=... sollten weitesgehend vermieden werden, da die ohne Angabe des lokalen Bezugspunktes wertlos.

So steht es zumindest in der Wiki-Hilfe. Aber ich denke eindeutig ist es schon.
Anhand der Koordinate ist klar in welchem Land der Punkt liegt.
Und jedes Land hat ein nationales amtliches Referenzsystem, bei uns eben das DHHN92.

Gut, für die automatische Verarbeitung ist es vielleicht aufwendiger, wenn das
erstmal intern aufgelöst werden muss. Mit einer Angabe des Systems wäre die Sache sofort klar.
Auf jeden Fall sollten die OSM-Editoren hier Unterstüztung bieten (Auswahlbox der Bezugssysteme
oder Default-Setting), damit die Leute nicht so viele falsche Werte eintragen.

seichter wrote:

Die Angabe im Wiki finde ich für die Höhe etwas an der Praxis vorbei. Was in der Ebene sehr sinnvoll ist (nur ein Längen-/Breitensystem weltweit), ist in der Höhe nicht so praktikabel.

Das Wiki ist an einer Stelle auch fachlich falsch:

Wiki (DE) wrote:

Um ein anderes System als WGS84 zu verwenden, besteht die Möglichkeit das "Systemdatum" im Schlüssel mit anzugeben: ele:xyz=*. xyz entspricht dabei dem Kartendatum und ele der Höhe in Meter (Höhe:Datum).

Wki (EN) wrote:

A proposal for map datums other than WGS84 is to store them in keys such as ele:xyz=*, where xyz is the map datum and elevation is specified in meters.

Es wird das Kartendatum (XY-Ebene) mit dem Höhendatum (Z-Richtung) vermengt. Es sind aber zwei unterschiedliche Angaben.

Wenn ich in XY-Ebene Bessel 1841 nehme, hab ich nicht automatisch DHHN12.

Sven

openzzz wrote:

So steht es zumindest in der Wiki-Hilfe. Aber ich denke eindeutig ist es schon.
Anhand der Koordinate ist klar in welchem Land der Punkt liegt.

Anhand der XY-Koordinate des Punktes im jeweiligen Land weißt du aber immer noch nicht, ob auch das im Land gültige Höhenreferenzsystem gemeint ist... oder nicht etwa in älteres...

Sven

1. Was hat die ganze ele-Diskussion mit dem NRW-Atlas für OSM-Zwecke zu tun?
2. Kann man die elends-Diskussion nicht hier http://forum.openstreetmap.org/viewtopi … 84#p335084 oder sonstwo weiterführen?

hurdygurdyman wrote:

Elevation (height above sea level) of a point in metres. This is mainly intended for mountain peaks but could also be used for elevation of airport runways and many other objects. For OpenStreetMap, please use the elevation above sea level defined by the World Geodetic System, revision WGS 84.

Das Wiki geht hier völlig an der Realität vorbei - ich bin auch der Meinung es sollte korrigiert werden. Aus der Historie des Wiki ist zu erkennen, daß es die nachträgliche Änderung eines einzelnen Users war. Eine Diskussion bzw. Entscheidung dafür scheint es nie gegeben zu haben.

bye, Nop

streckenkundler wrote:

Anhand der XY-Koordinate des Punktes im jeweiligen Land weißt du aber immer noch nicht, ob auch das im Land gültige Höhenreferenzsystem gemeint ist... oder nicht etwa in älteres...
Sven

Mit ele:local ist das derzeit gültige System gemeint. Unser Aktuelles gilt schon seit 20 Jahren. Das preußische Vorgängersystem ist schon über 100 Jahre alt, unterscheidet sich davon aber auch nur um ein paar cm. In dem Sinne ist "local" eindeutig genug. Sicherlich, zur langfristigen und weltweiten Speicherung wäre es sinnvoll, die Systemkennung automatisch umzuschreiben (also wenn hier einer was mappt dann local -> DHHN92). Da die wenigsten Normalbürger die Systeme kennen, ist ein "local" dann doch für das Erfassen praktisch. Auf den Schildern steht auch kein System drauf.

Prinzipiell ist die amtliche Höhe schon eine wichtige Größe. Die steht ja auch im NRW-Atlas drin. Der Referenzellipsoid von WGS84 wurde von den Amerikanern an die Erde approximiert. In Europa passt der nicht so gut zum Schwerefeld. Für die exakte Landvermessung braucht man hier in Europa ein eigenes System. Für OSM-Zwecke ist das nicht so wichtig. Auf Zentimetergenauigkeit ist das OSM-Projekt sowieso nicht ausgelegt. Da kann man bei Bedarf jederzeit die WGS84/Lokalen Größen konvertieren. In der Datenbank würde ich eher alles auf WGS84-Höhen vereinheitlichen, damit auch eine schnelle automatische Verarbeitung möglich ist, z.B. in Fahrrad-Routing-Anwendungen.

seichter wrote:

Die Angabe im Wiki finde ich für die Höhe etwas an der Praxis vorbei. Was in der Ebene sehr sinnvoll ist (nur ein Längen-/Breitensystem weltweit), ist in der Höhe nicht so praktikabel. Es wird mit Sicherheit noch sehr lange dauern, bis an allen Aussichtspunkten die lokale und die WGS84-Höhe aufgeführt werden. ...
...
Mit Länge und Breite hat man dieses Nullproblem nicht, außer man steht gerade in Greenwich auf dem in den Boden eingelassenen Nullmeridian.

Ein weltweites Einheitssystem kann es für die Landvermesser ohnehin nicht geben. Die Kontinente driften in der Größenordnung ca. 2-20 cm pro Jahr. Da braucht man einfach eine stabile Basis für die Triangulation, also ein an die Kontinente gebundenes Bezugssystem. In Europa das ETRS89.

Kein Nullproblem, aber doch ein Durcheinander verschiedener Systeme. Die amtlichen Karten waren früher ein Gauß-Krüger georeferenziert (hatte ich auf einer älteren DVD-Version des NRW-Atlas gesehen: "Magic Maps" topografische Karten). Wenn man die nicht richtig in WGS84 umrechnet liegt man leicht mal 100m daneben. Das war damals gar nicht so einfach, die richtigen Parameter für die 7-Parameter-Helmert-Transformation zu finden.

Für eine weltweite Karte wie OSM mit eingeschränkten Genauigkeitsanforderungen ist WGS84 eine gute Wahl, ebenso wie ETRS89 eine gute Wahl für den NRW-Atlas ist (oder läuft der noch unter ED50?).

streckenkundler wrote:

EvanE wrote:

PS-3: Wie groß ist der Unterschied zwischen DHHN12 (alte Bundesländer), SNN76 (neue Bundesländer) und dem gemeinsamen DHHN92 nach 1992?

Da lässt sich kein eindeutiger Wert festlegen. Vergleiche:http://de.wikipedia.org/wiki/Deutsches_ … %B6hennetz und hier den Abschnitt Vergleich der Systeme Deutschlands.

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

Ergänzung: siehe auch: http://www.bkg.bund.de/nn_175422/DE/Bun … __nnn=true

Hallo Sven

Vielen Dank für die wertvollen Links zu den Hintergrund-Infos. Auf die Wikipedia-Seite hätte ich auch selber kommen können.

Wer nicht selber nachsehen will, hier ein Zitat aus dem Wikipedia-Artikel (Umbrüche von mir):
"DHHN92 ist das aktuell gültige Höhensystem in Deutschland.
Entsprechende Höhenangaben sind mit "NHN" gekennzeichnet,
Beispiel: "500 m ü. NHN". Die Unterschiede zu den bisherigen Systemen
liegen im Flachland bei wenigen Millimetern, in den Alpen bei knapp 20 cm."
und
"Die Differenz zwischen Höhen nach DHHN92 (NHN) und DHHN12 (NN)
liegt zwischen –80 mm und +42 mm, durchschnittlich sind es 4 mm.
Sie ist in den Alpen größer als im flachen Norddeutschland. Deshalb sind in
diesen Gebieten DHHN12 (NN) und DHHN92 (NHN) näherungsweise gleich. "

Fazit: In den alten Bundesländer (außerhalb der Alpen) kann man bei Angaben mit 0.1 Meter Genauigkeit diesen Unterschied vernachlässigen. In den neuen Bundesländern und den Alpen kann es auch mal um einen Zehntel Meter daneben liegen.

Edbert (EvanE)

openzzz wrote:

Mit 2 Satelliten bekommst du schon mal gar keine Ortung hin.

Es hat sich schon jemand über die GPS- bzw. Höhendiskussion hier beschwert, aber doch noch eine Klarstellung:
Dass man mindestens 4 Satelliten braucht, ist mir bekannt, ich hätte unmissverständlicher schreiben müssen " zwei von vier".
Vielen Dank aber für den Artikel in gpsworld, da sind ein paar schöne Beispiele zu sehen. In Bild 5 stehen fünf Satelliten fast in einer Linie, daher ist der HDOP-Wert sehr schlecht, der VDOP-Wert ist aber ordentlich, da die Satelliten auf unterschiedlichen Höhenwinkeln stehen. In höheren Breiten ist der VDOP-Wert tendenziell schlechter, da die Satelliten für einen guten Höhenwert nicht hoch genug über den Horizont kommen. In unseren Breiten ist dieser Effekt aber noch nicht dominierend.
Eine letzte Anmerkung (mein Vorsatz): Nach meiner Erfahrung sind die DOP-Werte (Geometrie-Fehler) meist deutlich geringer als der tatsächliche Fehler. Der Einfluss der übrigen Faktoren (Belaubung, Reflexionen, Abschattung) ist in der Regel größer, auch EGNOS kann nur einen Teil dieser Fehler (Laufzeit in Ionosphäre) verringern.

hurdygurdyman wrote:

1. Was hat die ganze ele-Diskussion mit dem NRW-Atlas für OSM-Zwecke zu tun?
2. Kann man die elends-Diskussion nicht hier http://forum.openstreetmap.org/viewtopi … 84#p335084 oder sonstwo weiterführen?

Wenig und viel zugleich.

Ich erwähnte das Problem in Post #117 weil mir ein Eintrag mit ele=* aufgefallen war. Das führte zu diesem Diskussionsteil.

Der NRW-Atlas hat viel mit der Problematik von ele=* und ele:*=* zu tun, da mit der Nutzung des NRW-Atlas uns erstmals Höhenangaben mit bekanntem Bezugssystem in großem Umfang zur Verfügung stehen.

Zu 2: Wenn da wäre es sinnvoller einen eigenen Thread dafür zu starten. Es geht hier um die Frage, was in ele=* real eingetragen wird und was laut Wiki dort eingetragen werden sollte und nicht um mögliche Abweichungen zwischen SRTM, ASTER und OpenDEM.

@Nop: Ja das hat einer mal 2009 eingetragen.
Die Diskussion darum wurde aber von Anfang an (ca. 2007 = OSM-Frühzeit) geführt.

@openzzz: Die SRTM Daten sind völlig ungeeignet auch nur Kandidaten für fehlerhafte Höhenangaben zu finden.
Einerseits liegen die nur in einem 90x90m Raster vor (damit könnte man noch leben). Andererseits wurden bei der Shuttle Radar Topography Mission nicht die Höhe der Erdoberfläche gemessen sondern das, was sich da so drauf befindet: Baumwipfel, Hausdächer, Ballone, Flugzeuge usw.

Edbert (EvanE)

Aber Achtung mit dem Vergleich: DOPs sind noch keine Fehler. Das sind Fehlerverstärkungsfaktoren. Du kannst denn Jitter der Pseudorange-Messung (so ca. 3m) damit multiplizieren. Solange das schön gaußförmig bleibt hat der Kalman-Filter im Receiver damit weniger Probleme. Nur wenn ein Range wegdriftet, z.B. durch ionosphärische Turbulenzen, dann kann man schlecht zurückrechnen, aber mit EGNOS kompensieren. Die Sats in Linie sind natürlich ein Worst-Case Fall. Passiert aber öfter mal in einer Straße, wo hohe Nachbargebäude die Seiten abschatten.

EvanE wrote:

@openzzz: Die SRTM Daten sind völlig ungeeignet auch nur Kandidaten für fehlerhafte Höhenangaben zu finden.
Einerseits liegen die nur in einem 90x90m Raster vor (damit könnte man noch leben). Andererseits wurden bei der Shuttle Radar Topography Mission nicht die Höhe der Erdoberfläche gemessen sondern das, was sich da so drauf befindet: Baumwipfel, Hausdächer, Ballone, Flugzeuge usw.
Edbert (EvanE)

Den Höhenfehler der STRM kenne ich nicht. Aber hast Recht, als Radar sieht man natürlich nicht immer nur den Boden. Wenn man die Erlaubnis dazu hätte, wären die Höhendaten der amtlichen Karte ganz nett. Ob die auch zwischen den Meßpunkten noch genau genug sind?

Aber wenn wirklich so viele falsche Angaben in den ele-Tags gemacht wurden, dann muss man das mal bereinigen. Eine automatische Lösung dazu wäre natürlich praktisch. Die Alternativen wären nur alles zu löschen oder mit dem Murks irgendwie auszukommen, d.h. fürs Fahrrad-Routing oder 3D-Karten auf OSM-Angaben zu verzichten.

EvanE wrote:

@openzzz: Die SRTM Daten sind völlig ungeeignet auch nur Kandidaten für fehlerhafte Höhenangaben zu finden.
Einerseits liegen die nur in einem 90x90m Raster vor (damit könnte man noch leben). Andererseits wurden bei der Shuttle Radar Topography Mission nicht die Höhe der Erdoberfläche gemessen sondern das, was sich da so drauf befindet: Baumwipfel, Hausdächer, Ballone, Flugzeuge usw.

Ballone und Flugzeuge kann man getrost vergessen, aber nicht die Bodenbedeckung. Da kommt es auch noch auf den Sensor an: C-Band reicht bis auf den Boden, stellenweise sogar in den Boden hinein, hat aber geringere Auflösung, X-Band wird von Bäumen und Bodenbewuchs reflektiert, hat aber höhere Auflösung. Größte Einschränkung ist aber ganz klar das Raster. In bergigen Gegenden hat man schnell Höhenfehler von zig Metern an manchen Positionen. Bei 90x90 liege ich halt im ungünstigsten Fall (Ecke) mehr als 50 m vom nächsten Stützpunkt entfernt und dieser hat selbst bei X-Band nur eine absolute Genauigkeit von 16 m.

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

Viele Grüße

Dietmar

openzzz wrote:

Für eine weltweite Karte wie OSM mit eingeschränkten Genauigkeitsanforderungen ist WGS84 eine gute Wahl, ebenso wie ETRS89 eine gute Wahl für den NRW-Atlas ist (oder läuft der noch unter ED50?).

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 😉

openzzz wrote:

EvanE wrote:

@openzzz: Die SRTM Daten sind völlig ungeeignet auch nur Kandidaten für fehlerhafte Höhenangaben zu finden.
Einerseits liegen die nur in einem 90x90m Raster vor (damit könnte man noch leben). Andererseits wurden bei der Shuttle Radar Topography Mission nicht die Höhe der Erdoberfläche gemessen sondern das, was sich da so drauf befindet: Baumwipfel, Hausdächer, Ballone, Flugzeuge usw.

...
Aber wenn wirklich so viele falsche Angaben in den ele-Tags gemacht wurden, dann muss man das mal bereinigen. Eine automatische Lösung dazu wäre natürlich praktisch. Die Alternativen wären nur alles zu löschen oder mit dem Murks irgendwie auszukommen, d.h. fürs Fahrrad-Routing oder 3D-Karten auf OSM-Angaben zu verzichten.

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)

seichter wrote:

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

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.

Nach Transformation insbesondere zusammen mit der Feinkorrektur BeTA2007 stimmen die Stützpunkte der Grenzen bis auf Zentimeter überein. Das sollte für OSM reichen.

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 ( 😄 ) schon gemacht habe. Mail oder PN reicht. (http://forum.openstreetmap.org/viewtopi … =19130&p=1.

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

Hallo Sven,

streckenkundler wrote:

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.

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

streckenkundler wrote:

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.

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 🙂

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

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.

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

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

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.

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

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

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)

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)

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.

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.

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?

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

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)

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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?

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

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)

Netzwolf wrote:

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

Hallo Wolf

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

Und jetzt will ich endlich Mappen!
Edbert (EvanE)

Netzwolf wrote:

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.

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.

EvanE wrote:

20 Jahre nach der Umstellung solten alle aktuellen Kartenwerke auf dem 'neuen' System beruhen.

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.

EvanE wrote:

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

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.

openzzz wrote:

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.

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

Nop wrote:

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

maxbe wrote:

Da ich in dieser Diskussion einen Trend hin zu wgs84 als Standardhöhe sehe ...

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

toc-rox wrote:

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.

+1

Edit: wegen off topic gelöscht.

toc-rox wrote:

maxbe wrote:

Da ich in dieser Diskussion einen Trend hin zu wgs84 als Standardhöhe sehe ...

Den Trend sehe ich so nicht ...

+1

Netzwolf wrote:

Moins,
Fällt was auf? "ele=" ist näher an "name" als an den Koordinaten. Und das ist kein Zufall. “ele=*” wird an Objekte drangeschrieben, damit es
...
Und jetzt kommst Du daher und willst zuerst das alte, bewährte System zerschlagen, bevor Du etwas besseres neues bereitgestellt hast?
..
Ich bin nicht mit dem einverstanden, was im Wiki zu “ele” steht. Das ist hier kaum jemand. Die allermeisten haben noch nicht einmal reingeschaut.
...
Hast Du bereits einen Renderer konfiguriert, der Berghöhen einzeichnet? Nicht? Ooops!
...
verhandle mit den Betreibern der OSM-Datenbank, dass die Node-Tabelle um ein Feld "ele" erweitert wird. Da kannst Du ele benutzen, weil es neu ist und Du keine bereits erfassten Felder zerstörst. Und kannst es sauber und perfekt und Mikrometer genau definieren.
...
PS: ich habe Ötztaler Alpen, Allgäuer Alpen, Wetterstein, Karwendel und Berchtesgadener Alpen mit Bergen erstmöbliert. Das sind über 2000 “ele=*”-Tags. Zur Zeit bin ich bei 1893 Objekten mit ”ele”-Information der letzte Bearbeiter. Wieviele “ele=” hast Du erfasst?

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.

Netzwolf wrote:

Das sind über 2000 “ele=*”-Tags. Zur Zeit bin ich bei 1893 Objekten mit ”ele”-Information der letzte Bearbeiter. Wieviele “ele=” hast Du erfasst?

Es wäre schlimm, wenn andere dann nach den OSM-Wiki-Leitlinien in WGS84 erfasst hätten
und wir einen ununterscheidbaren Mischmasch verschiedener Systeme hätten
(so wie 50% ü. N.N und 50% WGS-Höhe). Dann müsste man jeden Eintrag einzeln überprüfen,
wenn die Karten noch stimmen sollen.

Wenn aber sagen wir 99% der Einträge der Definition widersprechen ist die Lage hoffnungsvoller.
Dann könnte man entweder die Definition ändern oder alle bisherigen Einträger per
Datenbankscript auf ele:local umschreiben. Je nachdem wie man sich entscheidet.
Aber eine Entscheidung sollte her, bevor wirklich dieser Mischmasch entsteht.
Ich nehme normalerweise meine Definitionen zur Datenstruktur sehr ernst.

hurdygurdyman wrote:

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)

Ich bin der Meinung, dass wer Höhen nach WGS84 eintragen will, dies ausschließlich in ein Tagg ele:WGS84 (von mir aus auch ele:wgs84) tun sollte. Nur dann ist klar was real gemeint ist.

Ansonsten sollten wir die Diskussion wirklich im eigenen Thread weiterführen, wie es maxbe im Post #183 vorgeschlagen hat.

Edbert (EvanE)

Edit: wg. off topic gelöscht.

Netzwolf wrote:

Vielleicht solltest Du Dich mit den Abläufen bei OSM ein wenig vertraut machen: im Normalfall wird der Wiki-Eintrag zu einem Key erst erstellt, nachdem der Key bereits länger in Benutzung war. Der Eintrag beschreibt die vorwiegende Benutzung, oder sollte sie beschreiben. OSM wird nicht top-down verwaltet, sondern es wächst (und wuchert auch manchmal).
...
Verabschiede Dich von der Vorstellung, dass Du etwas DEFINIERST. und dann ALLE diese Definition lesen MÜSSEN und beachten MÜSSEN. Das ist der Wunschtraum eines Technokraten, entspricht aber nicht der Realität bei OSM.

So einen lässigen Umgang mit Tags kannst du machen, wenn die nicht automatisiert verarbeitet werden.

Bei den Höhen ist es so, dass die auf der Karte angezeigt werden.
Da ist einfach eine klare Definition wichtig. Wenn ich die N.N.-Höhen darstellen will muss ich genau wissen in welchem Tag die wie formatiert drinstehen.

Wer das vernachlässt hinterlässt einfach einen großen Datenmüll.

Das kannst du jetzt schon beobachten: in Irland wird im ele= Tag die ellipsoide Höhe eingetragen. Der Renderer kann damit dann nicht anders umgehen als in Deutschland und schreibt die einfach auf den Berg. Irische Bergspitzen sind also WGS84-ell. ind er Karte und deutsche mehrheitlich als N.N.

Ist das nicht Murks? Soll der Renderer jetzt entscheiden, ach der Berg liegt in Deutschland und die Mapper dort haben ein anderes Verständnis als in Irland, also rechne ich nur fallweise um? Ich finde es einfach nur schlampig, wenn man nicht in der Lage ist, dafür klare Regeln aufzustellen und sich daran zu halten.

Der Schaden ist schon da. Entweder die Iren oder die Deutschen müssten die Daten umrechen, um konsistent zu bleiben. Ich will nicht sagen wer jetzt Recht hat, der Stärkere (wir Deutschen sind sowieso größer und stärker)? Solche Schäden werden mit deiner Einstellung verursacht, nach der man keine Regeln braucht oder das Regelbrechen Spaß macht. Sicherlich ist es erstmal mühsam, Datenstrukturen zu definieren. Aber sicherlich auch weniger Arbeit wenn man es anfangs gründlich macht und später nicht mehr ändern muss.

Wenn du unbedingt in N.N. mappen willst, kannst du das nicht international in der OSM-Community abstimmen, um Regeln entsprechend anzupassen?

Wir haben jetzt gleichzeitig zwei Threads zum selben Thema hier im Forum. Wie maxbe heute morgen möchte ich euch bitten, doch in folgendem Thread weiter zu diskutieren und euch dort einzubringen: http://forum.openstreetmap.org/viewtopi … =21009&p=2

Netzwolf wrote:

Mach das System komplizierter, und schon wird nur noch eine kleine Minderheit von Experten erfassen. Schau Dir an, wie viele Mitstreiter Höchstgeschwindigkeiten erfassen? Das ist nämlich trivial. Und wieviele erfassen Fahrstreifen? Dämmert es jetzt?

Und mappen die auch schön alle international in km/h. Oder die Amis vielleich doch in miles-per-hour?

Wäre es nicht mega-schlampig, wenn man das nicht per Definition klarstellt, bevor man munter drauflos-mappt?
Ich finde das Beispiel eigentlich ganz gut, warum Definitionen wichtig sind.

• )
  

Amis haben da oft eine andere Einstellung. In NMEA ist die speed beispielsweise als Knoten definiert.
Das muss immer umgerechnet werden. Und ich bin heilfroh, dass nicht irgendwelche Deutschen Spinner
da auf einmal die Definition brechen und km/h im seriellen Protokoll übermitteln.

In Google-KML-Code habe ich schon Sourcecode-comments wie "these European communist bastards"
gelesen, weil einer mit der km/h Definition nicht einverstanden war.
Da muss man einfach drüberstehen. Definition ist Definition.

Bei der NASA gab es Spassvögel, die das missachtet haben.
... und veranwortlich für mindestens einen Raketenabsturz sind

Zum Glück wird OSM nicht Grundlage für Flugzeugkarten, sonst würden sie wohl
beim Landeanflug Crashen. Da sind 40 m Unterschied relativ viel.

Aber ich finde es nicht fair, dass entweder die Iren oder die Deutschen ihre Berg-Höhenangaben
ändern müssen, nur weil manche oder alle sich nicht an Definitionen halten.

• ) p.s. die einheitliche Definition ist für OsmAnd wichtig, weil es bei Geschwindigkeitsübertretungen warnen kann.
  

Wäre ziemlich nervig wenn es dauernd falschen Alarm gibt, nur weil die Einheiten nicht stimmen.

openzzz wrote:

Und mappen die auch schön alle international in km/h. Oder die Amis vielleich doch in miles-per-hour?

Und was hat das nun schon wieder mit dem NRW-Atlas zu tun?
Kopfschüttelnd, Chris

chris66 wrote:

openzzz wrote:

Und mappen die auch schön alle international in km/h. Oder die Amis vielleich doch in miles-per-hour?

Und was hat das nun schon wieder mit dem NRW-Atlas zu tun?
Kopfschüttelnd, Chris

Nichts. Aber die Einsicht sollte bei allen reifen, dass wir ein sauberes Datenmodell brauchen.
Mit dem NRW-Atlas kommen wieder neue Koordinatensysteme. In Gauß-Krüger hat man
leicht mal einen Horizontalversatz von 100m, wenn man mit der Umrechnung nicht korrekt umgeht.
Und bevor jemand aus dem NRW-Altas die Höhen abpinnt sollte er sich auch über das Höhenmodell klar sein.

Nochmal als Moderatorhinweis:

Bitte alle Diskussionen zu Höhenangaben und deren Codierung im dafür vorgesehenen Thread weiterführen:
http://forum.openstreetmap.org/viewtopic.php?id=21009

Hier bitte nur noch sachdienliches zum NRW-Atlas.

bye, Nop

Um noch einmal auf die ursprüngliche Freigabe zurückzukommen:

DD1GJ wrote:

GDI Bezirksregierung Köln wrote:

...
Gegen die von Ihren "OSM-Mappern" mittels GIS-Editoren beabsichtigten Nutzungen der WMS-Darstellungsdienste des NRW-Atlas zur Lagekontrolle, Qualitätssicherung und zur Ableitung von Geodaten kann ich keine Einwände erkennen. Lediglich das Kopieren meiner Datenbankinhalte - also ein direktes Speichern der aufgerufenen WMS-Darstellungsdienste zur Anlage von Sekundärdatenbeständen - ist bereits urheberrechtlich untersagt.
...

Ich frage mich, wie in diesem Zusammenhang das "automatische Abmalen" per Tracer2-Plugin zu sehen ist. Für mich sieht dies eher nach einem "Kopieren von Datenbankinhalten" aus: die per WMS erhaltenen Daten werden in ein anderes Format überführt und gespeichert, die Inhalte bleiben dieselben im wesentlichen unverändert. Oder wird es noch als "Ableitung von Geodaten" angesehen, weil ja nicht der gesamte Inhalt des WMS-Layers automatisch gespeichert wird?

Ich bin ehrlich gesagt immer noch irritiert über die großherzige Freigabe, die in so diametralem Kontrast zur vorherigen jahrelangen Totalverweigerung steht.
Insbesondere weil die "Ableitung von Geodaten" (d.h. nach unserem Verständnis das Abzeichnen von Objekten, nun ggf. sogar automatisiert) ganz lapidar nach "Lagekontrolle, Qualitätssicherung" erwähnt wird, frage ich mich, ob der Ansprechpartner bei der Bezirksregierung Köln damit vielleicht mehr erlaubt hat, als ihm bewußt war, bzw. keine Vorstellung davon hatte, wie wir die Formulierung auslegen (und nutzen). Faktisch können wir mit den neuen Mitteln des Tracer2-Plugins die komplette ALK (mit für unsere Zwecke verkraftbaren Verlusten bei der Genauigkeit) duplizieren. Das halte ich schon aus OSM-Sicht nicht für wünschenswert; aber ich kann mir auch nur schwer vorstellen, daß es seitens der Landesregierung so gewollt war.

Oli-Wan wrote:

Das halte ich schon aus OSM-Sicht nicht für wünschenswert; aber ich kann mir auch nur schwer vorstellen, daß es seitens der Landesregierung so gewollt war.

Ich hab da auch ein sehr, sehr ungutes Gefühl.

Gruss
walter

Oli-Wan wrote:

Das halte ich schon aus OSM-Sicht nicht für wünschenswert ...

Mir ist auch etwas unwohl bei dem automatisierten und gedankenlosen Umgang mit dem Tool. Die Auswirkungen werden wohl nicht so schlimm werden wie in Frankreich.

Ich vermute, dass die Bezirksregierung Köln nicht so ganz glücklich über die Entwickung sein dürfte und dies auch Auswirkungen auf die Bemühungen zur Datenfreigabe von WMS-Diensten (außer Luftbildern) in anderen Bundesländern haben dürften, da der schwammige Begiff "abmalen" jetzt eigentlich durch "kopieren" zu ersetzen wäre.

Persönlich halte ich den Informationsgehalt reiner Hausumringe für OSM-Zwecke eher für gering, solange sie nicht durch die Adresse nach dem Karlsruher Schema veredelt sind. Hierzu ist noch immer einiges an Handarbeit erforderlich verknüpft mit einer Kontrolle vor Ort bei Unklarheiten oder Zweifeln.

Auch bei Maps4BW gab es schon Probleme, weil "Quantitäts-Mapper" in Wirklichkeit nicht existierende Waldwege großflächig nachgezeichnet haben.

OSM profitierte in Deutschland bisher vorallem von der aktuellen Ortskenntnis seiner Mapper und dem daraus resultierenden Datenbestand. Es war zwar nicht alles in der Karte, aber was drin war, darauf konnte man sich verlassen. Wir sollten uns allmählich Gedanken machen, wie wir einen schleichendem Qualitätsverlust entgegenwirken.

Grüße
Joachim

DD1GJ wrote:

Ich vermute, dass die Bezirksregierung Köln nicht so ganz glücklich über die Entwickung sein dürfte und dies auch Auswirkungen auf die Bemühungen zur Datenfreigabe von WMS-Diensten (außer Luftbildern) in anderen Bundesländern haben dürften, da der schwammige Begiff "abmalen" jetzt eigentlich durch "kopieren" zu ersetzen wäre.

Könntest Du da vielleicht noch einmal nachhaken? Wenn man bloß "nicht ganz so glücklich" wäre, aber keinen Verstoß gegen die Nutzungsbedingungen sähe, wäre es ja halb so schlimm: Bei allzu großer Betrübnis könnte die Behörde die Nutzungsbedingungen ändern und ab dem Zeitpunkt des Inkrafttretens dürfte nicht mehr abgezeichnet werden.
Mehr Sorgen macht mir (abgesehen von den qualitativen Auswirkungen auf OSM, wo ich Deine Bedenken teile) aber die oben angedeutete Möglichkeit, daß das (automatisierte) Abzeichnen schon jetzt gegen die Nutzungsbedingungen verstößt. Es wäre unschön, wenn nach einigen Monaten hunderttausende hereingeklickte Gebäude gelöscht werden müßten, weil sich herausstellt, daß deren Übernahme unzulässig war. Das geschähe dann sowieso wieder nur halbherzig bzw. scheitert auch daran, daß die entsprechenden Beiträge nur teilweise identifziert werden können, und wir hätten jede Menge illegitime Daten in der Datenbank.

Oli-Wan wrote:

Ich frage mich, wie in diesem Zusammenhang das "automatische Abmalen" per Tracer2-Plugin zu sehen ist. Für mich sieht dies eher nach einem "Kopieren von Datenbankinhalten" aus: die per WMS erhaltenen Daten werden in ein anderes Format überführt und gespeichert, die Inhalte bleiben dieselben im wesentlichen unverändert.

Stimmt, das sollte möglichst schnell geklärt werden. 🙂

Ich hatte bereits vor meinem obigen Beitrag mit der Behörde telefoniert und ausführlich über das Thema diskutiert, allerdings auf privater Basis, so dass es derzeit keine offiziellen Aussagen gibt. Es ist zwar sehr unwahrscheinlich, dass wir nachträglich etwas löschen müssen, aber dennoch bitte ich die Power-Mapper um etwas Zurückhaltung. Gegen "haushaltsübliche Mengen" in der Umgebung des Wohn- odert Urlaubsortes dürfte nichts einzuwenden sein. Die durch das Tool gewonnene Zeit sollte für Luftbildvergleiche, Kontrollen vor Ort und sonstige Qualitäts-/Aktualitätskontrollen genutzt werden.

Grüße
Joachim

Wo finden sich die Definitionen der in der ALK verwendeten Flächen?

Im Bild zu sehen sind fünf verschieden gezeichnete Gebäude:
- Gebäude lachsfarben, Rand als durchgezogene Linie
- Gebäude dunkelgrau, Rand als durchgezogene Linie
- Gebäude hellgrau, Rand als durchgezogene Linie
- Gebäude dunkelgrau, Rand als strichpunktierte Linie
- Gebäude hellgrau, Rand als strichpunktierte Linie

Gruß Klaus

toc-rox wrote:

Wo finden sich die Definitionen der in der ALK verwendeten Flächen?
http://i.imgur.com/J2dTRrG.png

Im Bild zu sehen sind fünf verschieden gezeichnete Gebäude:
- Gebäude lachsfarben, Rand als durchgezogene Linie
- Gebäude dunkelgrau, Rand als durchgezogene Linie
- Gebäude hellgrau, Rand als durchgezogene Linie
- Gebäude dunkelgrau, Rand als strichpunktierte Linie
- Gebäude hellgrau, Rand als strichpunktierte Linie

Hallo Klaus

Generell findet man Informationen zu den einzelnen Karten unter Produkte und Dienste. Zur ALK gibt es da leider nichts. Zur DGK5 gibt es eine Zeichenerklärung als PDF.

Dennoch ist einigermaßen klar, was die verschiedenen Signaturen bedeuten:
- Rosa Fläche: Öffentliches Gebäude (Schule, Kirche, Sporthalle, ...)
- Dunkelgraue Fläche: Ein Hauptgebäude (z.B. Wohnhaus)
- Hellgraue Fläche: Ein Nebengebäude (z.B. Garage, Schuppen, ...)
- Gestrichelter Umriss: Geht nicht bis zum Boden (oft nur Dach, Balkone, ...)

Bei der ALK im Rasterformat werden statt Farben unterschiedliche Schraffierungen genutzt, die Umrisslinien sind gleich.

HTH
Edbert (EvanE)

Genau genommen sind das Wohngebäude, Wirtschaftsgebäude und Gebäude für öffentliche Zwecke.

Und die Linien sind zum einen eine geschlossene Genäudelinie und eine eines offenen Gebäudes.

Googelt mal nach dem ALKIS Signaturenkstalog da sind dann auch weitere Spezifikationen beschrieben.

MbG
nicht die Göre

Die Daten des NRW-Atlas und die Möglichkeiten der Tracer2-PlugIns scheinen die Mapper motiviert zu haben.
Innerhalb von 10 Tagen sind die Daten für den Reg.-Bez. Münster um knapp ein Drittel angewachsen:

geofabrik-pbf-File vom 23.11.2013 = 32.5 MB
geofabrik-pbf-File vom 04.12.2013 = 42.3 MB

Gruß Klaus

toc-rox wrote:

Die Daten des NRW-Atlas und die Möglichkeiten der Tracer2-PlugIns scheinen die Mapper motiviert zu haben.
Innerhalb von 10 Tagen sind die Daten für den Reg.-Bez. Münster um knapp ein Drittel angewachsen:

geofabrik-pbf-File vom 23.11.2013 = 32.5 MB
geofabrik-pbf-File vom 04.12.2013 = 42.3 MB

Gruß Klaus

mit Adressen oder nur rötlich-braune Kästchen?

Gruss
walter

edit: rötlich added. http://www.color-hex.com/color/beadad

wambacher wrote:

mit Adressen oder nur braune Kästchen?

Bitte, Walter. #beadad ist... naja, jedenfalls nicht braun.

😉

wambacher wrote:

mit Adressen oder nur rötlich-braune Kästchen?

Auf der Flughöhe (Größe der PBF-Datei) sehe ich weder Häuser noch Hausnummern. Aber als DB-Betreiber kannst du bestimmt entsprechende Statistiken liefern oder ?

Gruß Klaus

toc-rox wrote:

wambacher wrote:

mit Adressen oder nur rötlich-braune Kästchen?

Aber als DB-Betreiber kannst du bestimmt entsprechende Statistiken liefern oder ?

Bin ich schon dran, aber da ich die History nicht online habe, wird es ein wenig schwierig.
mal sehen, ob ich das hinkriege.

Gruss
walter

Hallo zusammen,

ich beobachte auch seit der Freigabe verstärkte Aktivitaten bei den Häusern.

Ich schaue mit http://simon04.dev.openstreetmap.org/whodidit/ ob sich was ändert und wenn sich viele Ways ändern schaue ich auch mal in die Changesets und meistens werden die Gebäude mit Hausnummern usw eingepflegt oder Adressen werden ergänzt.
Ich nehme mir auch bei mir in der Ungebung bereiche vor bei denen Adressen fehlen. Jetzt bei dem Wetter kann man sich so schön beschäftigen.

Gruß
Michael

toc-rox wrote:

geofabrik-pbf-File vom 23.11.2013 = 32.5 MB
geofabrik-pbf-File vom 04.12.2013 = 42.3 MB

Ich habe jetzt keinen Extrakt vom 23.11. zur Hand, aber der vom 01.11. war 42395134 Byte (42.4 MB/40.4 MiB) groß und der vom 04.12. 44381402 Byte (44.4 MB/42.3 MiB). Sollte es dazwischen einen mit 32.5 MB (oder eher MiB) gegeben haben, war er mit hoher Wahrscheinlichkeit kaputt.

PS. Gebäude (building=*) und Hausnummern (addr:housenumber=*) im genannten Regierungsbezirk (die Bewertung sei jedem selbst überlassen).

PPS. Für NRW:

Goggelt mal nach geoportal Sachsen und sucht da nach Adressen :-)

Da könnt ihr den ganzen Tag Hausnummern abschreiben 😎

1. Edit
source bei Kumpel von Onkel 🙂

Oli-Wan wrote:

PS. Gebäude (building=*) und Hausnummern (addr:housenumber=*) im genannten Regierungsbezirk (die Bewertung sei jedem selbst überlassen).

Coole Grafik, danke!

Nunja, dass die Moral der Eintagung von Hausnummern zurückgeht kann man noch nicht bewerten.

Erstens klickt man eben auch Nebengebäude an, die nicht unbedingt eine Hausnummer bekommen (weil die meisten dann doch den NRW-Atlas abzeichnen, ohne Nebengebäude in ein großes Gebäude zu verschmelzen).

Zweitens zeichne ich persönlich erst alle Häuschen ab und reiche irgendwann, wenn ich Lust habe, die Hausnummern nach.

Von daher abwarten 😎

FGOSM22 wrote:

Goggelt mal nach geoportal Sachsen und sucht da nach Adressen :-)
Da könnt ihr den ganzen Tag Hausnummern abschreiben 😎

Ich nehme an, du hast die lizenzrechtlichen Belange so nebenbei geklärt und gibst uns die Freigabe für die Übernahme der Daten.
Als nächstes wäre der hessenviewer auch ganz nett; da warte ich nämlich schon lange drauf.

gruss
walter

Nö,
Was steht denn da drin?
Das wir in anpinseln dürfen ?

1. Edit
Und gifte mich ni immer so voll

2.Edit
Das will hier niemand lesen. So

FGOSM22 wrote:

Nö,
Was steht denn da drin?

Eine der wichtigsten Grundregeln bei OSM ist daß Du nur Dinge eintragen darfst, die frei von Copyrightbeschränkungen sind. D.h. Dinge die Du selbst erfaßt hast (bei denen hast Du selbst das Copyright) oder Abmalen/Abschreiben aus Quellen bei denen der Rechteinhaber es ausdrücklich und mit einer zu OSM passenden Lizenz erlaubt hat.

Was Du vorschlägst, einfach irgendwo abzuschreiben, wäre höchstwahrscheinlich ein Copyrightverstoß. Das ist 1. illegal und 2. müßten alle Deine so eingetragenen Daten dann wieder aus OSM rausgelöscht werden. Die Datenbank darf keine illegal abgeschriebenen Elemente enthalten.

@Wambacher: Bitte gegenüber einem planlosen Neuling nicht ausschließlich Ironie verwenden sondern auch einen konkreten Hinweis worin das Problem besteht.

bye, Nop

poppei82 wrote:

Nunja, dass die Moral der Eintagung von Hausnummern zurückgeht kann man noch nicht bewerten.
...
Von daher abwarten 😎

Richtig, für eine eindeutige Beurteilung ist es zu früh, wenn sie auf Basis eines solchen Diagramms überhaupt möglich sein sollte. Dafür spielen zu viele gegenläufige Effekte eine Rolle, deren jeweilige Stärke sich nur schwer abschätzen läßt.

Ohnehin sehe ich selbst, wie früher schon erläutert, die Gefahren des Klickimportes gar nicht so sehr in Gebäuden ohne Hausnummern.

Allerdings fällt schon auf, daß der relative Zuwachs bei den Hausnummern bisher (d.h. seit Beginn der Geofabrik-Archiv-Extrakte) stets größer war als bei den Gebäuden. Mit der Verfügbarkeit von Tracer2 scheint sich die Hierarchie umzukehren. (Die dünne matschgraue Linie liegt bisher stets unterhalb der dünnen roten Linie, holt aber neuerdings stark auf.) Ob dies nun gut oder schlecht ist (d.h. folgerichtig aufgrund anderer/besserer Daten oder eine Konsequenz schnellen Importgeklickes ganz ohne Hausnummern), läßt sich dagegen allein aus den nackten Zahlen nicht beurteilen.

Falls übrigens jemand zufällig noch einen NRW-Extrakt aus dem Intervall zwischen dem 20. und 28. November herumliegen hat: dieser könnte helfen, den Knick in den Graphen noch besser aufzulösen.

toc-rox wrote:

geofabrik-pbf-File vom 23.11.2013 = 32.5 MB
geofabrik-pbf-File vom 04.12.2013 = 42.3 MB

Da hatte sich ein Fehler eingeschlichen ... die korrekten Zahlen lauten:
- geofabrik-pbf-File vom 23.11.2013 = 41.3 MB
- geofabrik-pbf-File vom 07.12.2013 = 42.7 MB

Das wäre innerhalb von 14 Tagen ein Zuwachs von 1,4 MB oder 3,4 Prozent.
M.E. immer noch beachtlich ...

Gruß Klaus

@Oli-Wan: Ich hätte einen NRW-Extrakt vom 09.11.2013 verfügbar.

toc-rox wrote:

@Oli-Wan: Ich hätte einen NRW-Extrakt vom 09.11.2013 verfügbar.

Du kannst natürlich gerne ein

osmconvert␣nordrhein-westfalen-131109.osm.pbf␣--out-o5m␣|␣osmfilter␣/dev/stdin␣--out-key␣|␣egrep␣'[[:blank:]](building|addr:housenumber)$'

(Dateiname ggf. anpassen) drüber laufen lassen und mir das Ergebnis mitteilen, aber wie gesagt wären die Tage zwischen dem 20. und 28. interessanter.

Ergibt für die Daten des NRW-Extraktes vom 9.11.2013:

1174840 addr:housenumber
2477283 building

Gruß Klaus

Danke, ist drin.

FGOSM22 wrote:

Nö,
Was steht denn da drin?
Das wir in anpinseln dürfen ?

habe was gefunden

http://geoportal.sachsen.de/cps/361.html

https://www.geomis.sachsen.de/terraCata … logHistory

dürft ihr dann vielleicht doch nicht nehmen 😎

FGOSM22 wrote:

FGOSM22 wrote:

Nö,
Was steht denn da drin?
Das wir in anpinseln dürfen ?

habe was gefunden
http://geoportal.sachsen.de/cps/361.html
dürft ihr dann vielleicht doch nicht nehmen 😎

Hi, ich hab vor einigen Tagen versucht, durch die wirklich komplizierten "Lizenzbedingungen" vom Geoportal Sachsen durchzublicken.

In dem von dir zitierten Passus steht ja drin "Art und mögliche Beschränkung eines Nutzungsrechts werden grundsätzlich von der geodatenhaltenden Stelle und nicht durch das Geoportal bestimmt". Dadurch schieben die "netten" Betreiber des Portals alle Informationen über die Nutzungsbedingungen an den "Datenlieferanten" (geodatenhaltende Stelle) weiter.

Deshalb hab ich dann mal versucht, dort diese Bedingungen herauszufinden. Es ging wohl um den WMS-Server für die Liegenschaftskarte - da wo man die Hausnummern erwarten sollte.
Bei denen stand dann sinngemäß "Nutzungsinformationen stehen in den Metadaten des Layers". Ok, dann halt da rein geschaut.

Und da stand dann drin "Kontakt xyz, Herr xxx, Telf nnn - und das war es dann.
Danach hatte ich wirklich keine Lust mehr weiterzusuchen.

Ehrlich gesagt, fühle ich mich durch diese "Schiebetaktik" mehr oder weniger vera......

Trotz dieser absoluten Fehlinformation (wenn man von Information überhaupt sprechen kann), bin ich dennoch der Meinung, dass wir die Daten nicht nutzen dürfen, solange die nicht explizit freigegeben worden sind. Leider.

Gruss
walter

ps: das geht jetzt nicht gegen dich. Du hast dich ebenfalls bemüht, verlässliche Infos zu bekommen aber ich glaube dort rennt man gegen Drehtüren. Alles ist offen aber keiner kommt rein 🙁

FGOSM22 wrote:

FGOSM22 wrote:

Nö,
Was steht denn da drin?
Das wir in anpinseln dürfen ?

https://www.geomis.sachsen.de/terraCata … logHistory

dürft ihr dann vielleicht doch nicht nehmen 😎

ich sehe gerade das der eine Link nicht funktioniert
dann müsst ihr hier die Adressen mal selbst anklicksen
http://www.geomis.sachsen.de/terraCatal … CAE67516E5

1. Edit
das geht auch wieder nicht 🙄
dann kann man das eben nicht verlinken
irgendwie ist das blöd

2. Edit
funktioniert das über google
http://www.geomis.sachsen.de/terraCatal … efc88e74f2

3. Edit
geht ja, nicht ganz einfach aber es funktioniert

Waldwege

Ich habe anhand des NRW-Atlas divere Waldwege lagmässig angepasst. Bei einer Pobe mit einer Garmin-Karte passen die Wanderwege jetzt genau.
Ich rege an, generell alle durch Wälder gehenden Straßen und Wege mit dem ALK-Hintergrund in JOSM zu prüfen.

WoGraSo wrote:

Ich habe anhand des NRW-Atlas diverse Waldwege lagmässig angepasst. Bei einer Pobe mit einer Garmin-Karte passen die Wanderwege jetzt genau.
Ich rege an, generell alle durch Wälder gehenden Straßen und Wege mit dem ALK-Hintergrund in JOSM zu prüfen.

Man sollte mit Waldwegen insgesamt vorsichtig sein. Ich habe durchaus schon in ALK eingetragene Wege-Flächen gefunden, die bis heute nicht realisiert wurden (oder heute nicht mehr genutzt werden).

Auch scheint die reale Lage von Wegen mitunter eher neben der in ALK eingetragenen Fläche zu liegen, als innerhalb dieser Fläche. Ein Vergleich mit den DOP40 ist da durchaus aufschlussreich.

Man sollte also Vorsicht walten lassen und insbesondere Wege nur dann neu eintragen, wenn sie durch andere Quellen bestätigt werden. Die anderen Quellen können durchaus bestehende OSM-Wege sein (dann nur Lagekorektur) oder diverse von uns nutzbare Luftbilder (wenigstens Abschnitte des Weges sollten erkennbar sein). Eine eigene Begehung ist natürlich das Optimum.

Für Wege im Wald bevorzuge ich die DGK5, da die auch kleinere Wege enthält, für die in ALK keine Fläche ausgewiesen ist. Auch dafür gilt das oben gesagte, Bestätigung durch weitere Quellen oder eigene Erkundung ist sinnvoll.

Insgesamt muss man wie bei allen Quellen außer der eigenen Besichtigung immer davon ausgehen, dass Teile entweder veraltet sind oder noch nicht enthalten sind. Selbst die Infomationen in der ALK und der DGK5 haben unterschiedliche Ausgabestände.

Trotz dem zuvor gesagten ist die Lagegenauigkeit von DGK5 und ALK eine Verbesserung, insbesondere da die GPS-Daten im Wald doch einer recht großen Streuung unterliegen und viel Wege nur stückweise im Luftbild sichtbar sind.

Edbert (EvanE)

WoGraSo wrote:

Ich habe anhand des NRW-Atlas diverse Waldwege lagemäßig angepasst. Bei einer Probe mit einer Garmin-Karte passen die Wanderwege jetzt genau.

Ja das ist ja toll! Jetzt stimmen also "deine" per ALK angepassten Wege genau mit den bei Garmin angezeigten Wegen überein.

Hast du dich schon mal gefragt, woher Garnim die Daten der Wege hat? Habe die alle Wege selber abgelaufen/abgefahren oder haben die eventuell - genau wie Google - diese Daten für teures Geld beim Land NRW gekauft?

Gruss
walter

ps: Typos im Zitat korrigiert.

wambacher wrote:

ps: zwei Typo im Zitat korrigiert.

Das war immerhin schon mal die Hälfte. 😉

Oli-Wan wrote:

wambacher wrote:

ps: zwei Typo im Zitat korrigiert.

Das war immerhin schon mal die Hälfte. 😉

besser so?

wambacher wrote:

besser so?

Perfekt.

ZI: Garmin verwendet (auch) die Daten der Deutschen Grundkarte ... die Übereinstimmung ist somit nicht verwunderlich. Besser wäre ein Abgleich mit qualitativ geeigneten GPS-Spuren.

Gruß Klaus

toc-rox wrote:

ZI: Garmin verwendet (auch) die Daten der Deutschen Grundkarte ... die Übereinstimmung ist somit nicht verwunderlich. Besser wäre ein Abgleich mit qualitativ geeigneten GPS-Spuren.

Hallo Klaus

Dort wo viele GPS-Spuren existieren kann man recht deutlich sehen, dass beim Übergang in einen Wald diese Spuren deutlich schlechter werden. Insoweit sind GPS-Spuren für Straßen / Wege im Wald leider nicht qualitativ gut und daher nur ein zweitrangiges Indiz für die genaue Lage.

Edbert (EvanE)

Mit "geeigneten" GPS-Spuren meinte ich insbesondere auch deren Vorhandensein.

Gruß Klaus

toc-rox wrote:

Mit "geeigneten" GPS-Spuren meinte ich insbesondere auch deren Vorhandensein.

Das ist idR in bewaldetem Gebiet genau das Problem.
Nach meiner Erfahrung mit Maps4BW stimmen die eingezeichneten Wege im Wald (sofern sie tatsächlich vorhandenen sind) ziemlich gut mit gemittelten Tracks überein, ebenso mit kurzen aus der Luft sichtbaren Abschnitten. In NRW dürfte das nicht anders sein.

Die Wege aus der ALK eignen sich also gut zur Verbesserung von vorhanden Wegen, auch wenn keine geeigneten Tracks gespeichert sind. Bei noch nicht in OSM gemappten Wegen möchte ich aber allermindestens Anfang und Ende gesehen haben, bevor ich da etwas übernehme.

Gerade im RSS-Feed reinbekommen. Einige URLs werden sich am 24.3. ändern:

Abschaltung alter Dienste und URLs
Die in der Tabelle aufgeführten WMS wurden durch neue Dienste ersetzt. Daher erfolgt zum 24.03.2014 eine Abschaltung der veralteten Dienste. Die URLs zum Einbinden der Nachfolgedienste in Ihre Systeme finden Sie in der Spalte URL NEU.

ALK
[...]
DTK10
[...]

Quelle: http://www.wms.nrw.de/rssfeeds/content/ … l/011.html

poppei82 wrote:

Gerade im RSS-Feed reinbekommen. Einige URLs werden sich am 24.3. ändern.

Danke für die Info. Bin gerade ein wenig knapp mit der Zeit: Laufen die neuen URLs schon oder wird das ein "Harter Umstieg"?

Gruss
walter

Auf der Seite zum NRW-Atlas stehen schon seit längerer Zeit (ca. mind. 2 Monate) die "neuen" URLs, so dass die jeder von uns schon in JOSM drin haben sollte.

Hallo zusammen und besten Dank für den Hinweis auf die neuen URL´s.

Jetzt zu meiner Frage:

Ist euch schon etwas eingefallen, wie man verhindern kann, dass Waldwege ungeprüft nach nrw atlas (vermutlich DTK10) eingezeichnet werden ? Bei uns im Sauerland ist jetzt ein User (Ratz41) aufgetreten, der exakt dieses plant. Ich konnte ihn leider nicht davon abringen. Er vertritt die Meinung, dass man erstmal jede Menge Wege erfassen soll, diese könnten dann später ja wieder gelöscht werden, wenn festgestellt wird, dass diese in der Realität nicht existieren. Meine Meinung ist da leider etwas anders, ich habe Wege (insbesondere im Wald) immer mit GPS kontrolliert und erst dann eingetragen. Wenn jetzt ungeprüft Wege aus veralteten Luftbildern oder von Karten eingetragen werden, die real häufig nicht existieren verschlimmbessert das m.E. die OSM Karte und User werden sich überlegen, ob sie die Karte noch nutzen, wenn das Routing über nicht vorhandene Wege verläuft. Meine Nutzung oder Bereitschaft, OSM weiter zu verwenden, würde damit jedenfalls gegen Null tendieren.

Wie ist eure Meinung dazu ?

P.S.: Ich hoffe, das Thema gehört noch in diesen Thread, sh. #229.

Gruß
Hubertus

Hallo Hubertus,

palimpadum wrote:

Jetzt zu meiner Frage:

Ist euch schon etwas eingefallen, wie man verhindern kann, dass Waldwege ungeprüft nach nrw atlas (vermutlich DTK10) eingezeichnet werden ? Bei uns im Sauerland ist jetzt ein User (Ratz41) aufgetreten, der exakt dieses plant. Ich konnte ihn leider nicht davon abringen. Er vertritt die Meinung, dass man erstmal jede Menge Wege erfassen soll, diese könnten dann später ja wieder gelöscht werden, wenn festgestellt wird, dass diese in der Realität nicht existieren. Meine Meinung ist da leider etwas anders, ich habe Wege (insbesondere im Wald) immer mit GPS kontrolliert und erst dann eingetragen. Wenn jetzt ungeprüft Wege aus veralteten Luftbildern oder von Karten eingetragen werden, die real häufig nicht existieren verschlimmbessert das m.E. die OSM Karte und User werden sich überlegen, ob sie die Karte noch nutzen, wenn das Routing über nicht vorhandene Wege verläuft. Meine Nutzung oder Bereitschaft, OSM weiter zu verwenden, würde damit jedenfalls gegen Null tendieren.

Wie ist eure Meinung dazu ?

Nicht schon wieder! Wir hatten so einen Spezialisten schon einmal in Baden-Württemberg (weiter unten im Thread findet man seine User-ID).

Solche abgepinselten Waldwege, die unüberprüft sind, sind in OSM eigentlich unerwünscht und verwässern nur das hohe Qualitätsniveau von OSM. Wenn er unbedingt eine Karte mit allen nicht existenten Waldwegen braucht, soll er sich doch bei der Bezirksregierung Köln die ATKIS-Vektordaten kaufen (Telefon-Nr. 0221-147-4994).

In meinen Augen ist das ein Import und der muss vorher mit der Community abgesprochen werden.

Wenn sich User Joachim (User DD1GJ) hier nicht meldet, würde ich an deiner Stelle mal mit der Data Working Group Kontakt aufnehmen (dort sitzen auch ein paar Deutsche). Vielleicht kann ihn das ja überzeugen.

Ist das einer dieser Edits? Bitte halte uns auf dem Laufenden.

palimpadum wrote:

P.S.: Ich hoffe, das Thema gehört noch in diesen Thread, sh. #229.

Dort ging es, so habe ich den Eindruck, um die Lagekorrektur von Wegen. Die Wege wurden von Mappern vor Ort überprüft und die amtlichen Daten dienen nur der besseren Lagegenauigkeit (ob die jetzt wirklich genauer sind, lasse ich mal außen vor).

Ganz falsch bist in diesem Thread nicht. 🙂

Viele Grüße

Michael

Nakaner wrote:

Ist das einer dieser Edits? Bitte halte uns auf dem Laufenden.

Ist ja offensichtlich ein "alter Hase".

@Hubertus: Ich würde ihn mal nett auf den Beitrag hinweisen (das Forum kennt er bestimmt) und ihm klarmachen, dass er es jetzt nicht "nur" mit dir zu tun hat. Ansonsten in einigen Tagen Eskalation über die DWG (kann ruhig in deutsch geschrieben werden)
Bitte nichts ändern, damit ein eventueller Revert reibungslos klappt.

Gruss
walter

@Michael und Walter

Danke für die Auswertung. Mir war er bisher nur in einem anderen Bereich aufgefallen, in dem er nur ein paar Wege eingezeichnet hat. Aber anscheinend hat er ja schon großflächig Wege hinzugefügt. Die von ihm eingetragenen Wege in dem o.g. Bereich enthalten lt. JOSM keine GPS Spuren, daher dürften die Wege tatsächlich nur auf Karten bzw. veralteten Luftbildern beruhen. Ich werde ihn noch einmal anschreiben und auf eure Antworten hinweisen.

Bis dahin
Hubertus

palimpadum wrote:

@Michael und Walter
Danke für die Auswertung. Mir war er bisher nur in einem anderen Bereich aufgefallen, in dem er nur ein paar Wege eingezeichnet hat. Aber anscheinend hat er ja schon großflächig Wege hinzugefügt. Die von ihm eingetragenen Wege in dem o.g. Bereich enthalten lt. JOSM keine GPS Spuren, daher dürften die Wege tatsächlich nur auf Karten bzw. veralteten Luftbildern beruhen. Ich werde ihn noch einmal anschreiben und auf eure Antworten hinweisen.

Hallo Hubertus und herzlich willkommen im Forum

Bei Maps4BW stammen die Forstwege von den Forstämtern. Insoweit sind dort auch Wege enthalten, die nur alle paar Jahre genutzt werden (sogenannte Rückewege). Diese Wege sind zudem oft recht alt.
Beim NRW-Atlas stammen die Wege jedoch von den Vermessungsämtern, daher sind die deutlich besser als in BaWü und in der Regel auch aktueller.

Unabhängig von obigen Unterschieden ist bei Katasterdaten zu beachten, dass Flächen erfasst werden. Das können auch Flächen sein, die für Wege reserviert sind (aber noch nicht realisiert) oder Flächen die immer noch reserviert sind, obwohl der betreffende Weg inzwischen aufgegeben wurde.

In Summe sollten Wege aus ALK, DGK5 und DTK10 möglichst nur dann neu eingetragen werden, wenn sie aus einer weiteren Quelle bestätigt werden können. Das kann natürlich auch die eigene Besichtigung / Kenntnis sein. In letzterem Fall wäre ein source=survey am Weg hilfreich.

PS: Lagekorrekturen sind hingegen wesentlich weniger kritisch zu sehen.

Edbert (EvanE)

@edbert
Danke, sehe ich genauso. Die Lagekorrekturen sind für mich nicht das Problem. Wege, die ich 2009 nach gps erfasst habe und durch tiefen Wald führen, korrigiere ich auch anhand des nrw atlas. Nach meiner Erfahrung vor Ort sind aber auch im nrwatlas etliche Rückewege eingezeichnet und exakt diese möchte ich in OSM nicht sehen. Weiterhin sind dort auch viele Wege ausgewiesen, die heute zugewachsen sind. Daher halte ich bei Waldwegen das Couchmapping für nicht weiterführend und nicht dem ursprünglichen Ansatz von OSM entsprechend.

Gruss
Hubertus

Guten Morgen,
Ohne die Verhältnissse vor Ort zu kennen, trotzdem ein paar Anmerkungen.

palimpadum wrote:

Nach meiner Erfahrung vor Ort sind aber auch im nrwatlas etliche Rückewege eingezeichnet und exakt diese möchte ich in OSM nicht sehen.

Grundsätzlich muß man Rückewege von Waldwegen und Waldschneisen unterscheiden.
Rückewege sind temporäre Wege, die im Zuge der Walddurchforstung entstehen und danach wieder verschwinden. Das gehört definitiv nicht nach OSM.
Waldwege als solches sind klar und deren Umgang damit.
Waldschneisen, das ist sicher das, was gemeint ist, dienen neben vielen Waldwegen, zur Unterscheidung von Forstabteilungen. Auch diese werden im Falle einer Durchfostung durch Harvester ect. genutzt. Waldschneisen sind aber keine Wege. OSM bietet aber auch hier eine Lösung: man_made=cutline. Sofern man solche Waldschneisen sowohl im Luftbild, als auch bei der Begängnis im Wald vorfindet, kann man diese eintragen. (Wobei ich ein Vorhandensein eines stimmigen Waldwegenetzes für wichtiger erachte.)

Sven

Ich habe bei den erwähnten Edits eindeutige Beweise für das Abmalen falscher Waldwege gefunden und den User um Stellungnahme gebeten. Aufgrund den leidvollen Erfahrungen aus Baden-Württemberg plädiere ich für eine rasche Bestandaufnahme verdächtiger Wege, d.h. alle Tracks in Version 1.

Verändert bitte diese Woche nichts, denn um so schwieriger wird die Überprüfung.

Joachim

streckenkundler wrote:

Waldschneisen, das ist sicher das, was gemeint ist, dienen neben vielen Waldwegen, zur Unterscheidung von Forstabteilungen. Auch diese werden im Falle einer Durchfostung durch Harvester ect. genutzt. Waldschneisen sind aber keine Wege. OSM bietet aber auch hier eine Lösung: man_made=cutline. Sofern man solche Waldschneisen sowohl im Luftbild, als auch bei der Begängnis im Wald vorfindet, kann man diese eintragen. (Wobei ich ein Vorhandensein eines stimmigen Waldwegenetzes für wichtiger erachte.)

Hier https://www.openstreetmap.org/?mlat=50. … 5626/6.052 sieht man ein schönes Beispiel wie wichtig korrektes taggen sein kann. Links ein Gebiet mit durchgehendem "Rechteck"-Muster aus "track", vom Lufbild abgemalt. Rechts sah früher auch so aus, wurde dann aber von einem Mapper begangen und nun erst sieht man das tatsächliche Wegenetz. Man muß dazusagen das in Belgien die Schneisen oft expilzit als Betreten verboten ausgeschildert sind und daher für die Bewegung im Gelände also nur in Ausnahmen zu gebrauchen sind. Wichtig ist aber trotzdem dass sie eingetragen sind: sie geben der Landschaft Struktur - und beugen vor dass irgendwann jemand wieder vom Luftbild oder anderen ungeeigneten Quellen Wege einträgt.

Eine weitere Möglichkeit, die es in NL oft gibt, ist die Landschaftstruktur durch landuse nachzubilden. Ein Beispiel https://www.openstreetmap.org/?mlat=50. … 42/6.00551. Das ist zwar dort durch einen reinen landuse-Import entstanden (der eine ganze Reihe Probleme mitbrachte), aber immerhin wird nicht behauptet das da tatsächlich ein Weg ist. Als Nutzer kann man hier erkennen das hier etwas vorhanden sein könnte, verlässt sich aber nicht drauf das es tatsächlich einen Weg ist.

Ich nutze auch Waldschneise und Sektionsnummern (früher Hagen) wie hier. Ich finde es dient auch der Orientierung. Früher waren diese Nummern sogar aus Blech, heute meist Holztäfelchen oder nur noch an den "Eckbaum" gemalt.

nahundfern wrote:

Hier https://www.openstreetmap.org/?mlat=50. … 626/6.0520 sieht man ein schönes Beispiel wie wichtig korrektes taggen sein kann. Links ein Gebiet mit durchgehendem "Rechteck"-Muster aus "track", vom Lufbild abgemalt.

Danke für das Beispiel. Ich selbst habe man_made=cutline bisher nicht eingesetzt, da real existierende Waldwege (auch wenn sie für den öffentlichen Verkehr gesperrt sind) für mich wichtiger sind.

Sven

geri-oc wrote:

Früher waren diese Nummern sogar aus Blech, heute meist Holztäfelchen oder nur noch an den "Eckbaum" gemalt.

bei uns öfters noch als Stein "Jagenstein") anzutreffen, ganz früher waren es auch Holzpfähle mit aufgemalter Nummer, hab noch so einen Pfahl in meiner Sammlung.

Sven

Hallo,

Nakaner wrote:

Wenn sich User Joachim (User DD1GJ) hier nicht meldet, würde ich an deiner Stelle mal mit der Data Working Group Kontakt aufnehmen (dort sitzen auch ein paar Deutsche). Vielleicht kann ihn das ja überzeugen.

Ich habe den Benutzer freundlich gebeten, sich hier mal an der Diskussion zu beteiligen, bevor er weiterarbeitet.

Bye
Frederik

Hallo,
ich hatte die Diskussion hier nicht verfolgt und bin grad etwas zu faul um alle 252 Posts zu lesen. Daher die Frage, wie ich am besten zum Eintragen von Hausumrissen und Adressen in NRW vorgehe. Im Wiki habe ich nichts gefunden. Da steht der NRW-Atlas auch nicht bei den verfügbaren Luftbildern. Soviel habe ich bisher herausbekommen: WMS "ALK Vektor" zusammen mit JOSM Tracer2 zum Abpausen der Hausumrisse. WMS "ALK Raster" für die Hausnummern (sind etwas schwer zu erkennen). WMS "DOP40" zur Korrektur der Hausumrisse. DOP40 sieht Bing sehr ähnlich, Bing ist von 2012. Straßenname und PLZ muss ich schätzen. Alles ist lizenzkonform nutzbar. Gibt es noch eine andere Quelle für die Adressen? Sonst was vergessen?
Danke, Holger

Hallo Holger,

holgermappt wrote:

WMS "DOP40" zur Korrektur der Hausumrisse. DOP40 sieht Bing sehr ähnlich, Bing ist von 2012.

Auf dem DOP40 (Orthophoto mit 40 cm Auflösung) kannst (besser: solltest du nachschauen), ob das Kataster (ALK-Layer) an dieser Stelle noch aktuell sind. Wie in den vorherigen Post erwähnt, werden Gebäude für das Liegenschaftskataster (also die ALK) eingemessen. Bei manchen geschieht das nicht (z.B. weil "verjährt" oder weil die Gebühren zu niedrig wären oder weil das Gebäude nicht einmessungspflichtig ist, Näheres regelt das Vermessungsgesetz NRW).

Irgendwo auf den Webseiten der Vermessungsverwaltung von NRW dürfte sich bestimmt auch eine Übersicht finden, wann das Luftbild aufgenommen wurde. Normalerweise geschieht das alle drei bis vier Jahre. Tipp: Versuch mal in JOSM einen Rechtsklick auf das DOP40-Hintergrundbild und klick dann auf "Kachelinformationen anzeigen". Wird dir dann das Aufnahmedatum angegeben? Bei Bing (TMS, nicht WMS) funktioniert es.

Viele Grüße

Michael

holgermappt wrote:

Hallo,
ich hatte die Diskussion hier nicht verfolgt und bin grad etwas zu faul um alle 252 Posts zu lesen. Daher die Frage, wie ich am besten zum Eintragen von Hausumrissen und Adressen in NRW vorgehe. Im Wiki habe ich nichts gefunden. Da steht der NRW-Atlas auch nicht bei den verfügbaren Luftbildern. Soviel habe ich bisher herausbekommen: WMS "ALK Vektor" zusammen mit JOSM Tracer2 zum Abpausen der Hausumrisse. WMS "ALK Raster" für die Hausnummern (sind etwas schwer zu erkennen). WMS "DOP40" zur Korrektur der Hausumrisse. DOP40 sieht Bing sehr ähnlich, Bing ist von 2012. Straßenname und PLZ muss ich schätzen. Alles ist lizenzkonform nutzbar. Gibt es noch eine andere Quelle für die Adressen? Sonst was vergessen?
Danke, Holger

Genau, mit ALK Vektor und Tracer2 bekommt man die Hausumrisse. Die Hausnummer steht auch im ALK Vektor drin, und auch die Straßennamen! Besser ist es die PLZ wegzulassen anstatt zu schätzen. Im Normalfall brauchen die Hausumrisst nicht korrigiert werden, man kann höchstens DOP40/Bing verwenden um zu überprüfen ob das Haus noch steht.
Hausnummern (incl. Adressen) kann man mit dem HouseNumberTaggingTool-Plugin ganz schnell erfassen. Taste: K

(Bei mir tritt manchmal der Fehler auf, dass in der Hausnummer plötzlich "k" steht. Anscheinend bin ich nicht der einzige: http://overpass-turbo.eu/s/2KX Weiß jemand woran es liegt? Hab grad mal ein Ticket gesetzt.)

MasiMaster wrote:

Die Hausnummer steht auch im ALK Vektor drin, und auch die Straßennamen! Besser ist es die PLZ wegzulassen anstatt zu schätzen. ... Hausnummern (incl. Adressen) kann man mit dem HouseNumberTaggingTool-Plugin ganz schnell erfassen. Taste: K

Danke für die Tips. Ich hatte bei Vektor scheinbar nur die Hausumrisse ausgewählt um den Tracer2 zu testen. http://www.wms.nrw.de/ scheint gerade tot zu sein, ich bekomme nur Timeouts. Werde morgen noch mal nachsehen.

MasiMaster wrote:

man kann höchstens DOP40/Bing verwenden um zu überprüfen ob das Haus noch steht.

Streiche "höchstens". Der Abgleich mit möglichst aktuellen Luftbildern sollte wirklich das absolute Minimum sein, sonst können wir den Import auch gleich komplett automatisieren.

Oli-Wan wrote:

MasiMaster wrote:

man kann höchstens DOP40/Bing verwenden um zu überprüfen ob das Haus noch steht.

Streiche "höchstens". Der Abgleich mit möglichst aktuellen Luftbildern sollte wirklich das absolute Minimum sein, sonst können wir den Import auch gleich komplett automatisieren.

Damit war gemeint, dass man nicht den Gebäudegrundriss mit den Luftbilder "korrigieren" soll, also anhand der Dachfläche ausrichten. Das building=* soll das Gebäude, nicht das Dach darstellen.

MasiMaster wrote:

Damit war gemeint, dass man nicht den Gebäudegrundriss mit den Luftbilder "korrigieren" soll, also anhand der Dachfläche ausrichten. Das building=* soll das Gebäude, nicht das Dach darstellen.

Alles klar. Ich bin im eher ländlichen Bereich unterwegs, und da würde ich einfach mal unterstellen, dass es hier und da einen Anbau gibt, der nicht eingemessen/gemeldet ist. Da versuche ich dann die Realität möglichst gut zu schätzen. Inklusive Dachüberstand.

Ist jedenfalls ein eigentümliches Gefühl, wenn man Abmalen vom Luftbild gewohnt ist und manchmal über die Kreativität der Bauherren flucht, weil ein Haus eine komplizierte Form hat mit Anbau hier und Vorsprung da. Also viel geklicke. Und jetzt macht man einen Klick und das Haus steht.

Durch die Übernahme von Gebäudeumrissen mittels JOSM-Plugin aus dem NRW-Atlas bekommen wir in unsere Datenbank auch Gebäude mit über 100 Knoten, wo vier gereicht hätten. Ein Beispiel mit 146 Knoten.

Heute und auch vor vielleicht zwei Monaten hatte ich schon Überflüssige Knoten an solchen Gebäuden entfernt, die ich zufällig in NRW fand.

Wie können wir verhindern, dass Mapper, die den NRW-Atlas als Grundlage verwenden, weiterhin diese unnötigen Knoten mit dem Plugin eintragen.

Franz

Hilfreich wäre eine Wikiseite NRW-Atlas, welche die wichtigsten Informationen enthält. Fehlende und verstreut liegende Informationen sorgen für diese Probleme.

Ich habe die Seite gerade angelegt. Der Inhalt ist derzeit noch dürftig aber das wird sich ja schnell ändern. 😄 Meine Gedanken zur Grundstruktur sind dort ersichtlich.

Zyras wrote:

Ich habe die Seite gerade angelegt. Der Inhalt ist derzeit noch dürftig aber das wird sich ja schnell ändern.

http://forum.openstreetmap.org/viewtopi … 90#p372090

Danke für den Link. 🙂

Ich kann mich gerne darum kümmern einiges zu erstellen - jedoch wäre es hilfreich, wenn mich jemand unterstützt. Ich selber verwende den Atlas erst seit kurzer Zeit und kenne noch nicht das ganze Potential. 🙂

Edit: Heute Abend kümmere ich mich um die Tabellen und ein paar Ergänzungen im Artikel.

FvGordon wrote:

Ein Beispiel mit 146 Knoten.

Fixed.

FvGordon wrote:

Wie können wir verhindern, dass Mapper, die den NRW-Atlas als Grundlage verwenden, weiterhin diese unnötigen Knoten mit dem Plugin eintragen.

Indem man solche Mapper freundlich anschreibt.

Hallo zusammen,

einen User, der am Niederrhein über gaze Dörfer hergefallen ist, hatte ich mal freundlich angeschrieben ob es nicht zielführenderwäre nur kleine beriche zu bearbeiten und das dann nachhaltig.
Ich hatte Ihn auch auf diesen Thred und die Diskussion zu Tracer2 beim Masseneinsatz hingewiesen.

In seiner Statistik bei hdyc sind ca.700.000 Biuldings

Seine reaktion.

"Hallo,

OK, stelle meine Arbeit ab sofort ein.

Gruß"

Gruß
Michael

Na ja, die einen wollen Qualität, die anderen Quantität. 😉

Na ja, die einen wollen Qualität, die anderen Quantität.

Naja - das eine schließt das andere ja nicht unbedingt aus. Sofern Ortschaften nur rudimentär erfaßt sind husche ich auch drüber. Selbst wenn ich nicht vor Ort sein kann. Klar gibt es Fehler, da Gebäude abgerissen worden sind, manches noch nicht gebaut wurde, das Material vom Atlas nicht stimmt... Fehler gibt es auch bei der Verwendung von Bing - hier habe ich schon Parkplätze als Gebäudeeintrag vorgefunden oder sehr interessante Interpretationen des Luftbildes. Selbst wenn ich letzte Woche in Ort XY war und die Lage vor Ort geprüft habe kann Gebäude X schon abgerissen worden sein. Bin ich also ein "schlechter" Mapper, wenn ich Orte in der Art abzeichne und erst später kontrolliere oder darauf baue, dass andere Mapper aktiv werden und die Korrekturen vornehmen? Nein - ich beteilige mich aktiv am Projekt. Es lebt von ergänzenden Einträgen, Korrekturen... Ansonsten müßte man sich nur auf ein kleines Gebiet beschränken und alles bisher gesammelte Datenmaterial immer wieder checken. Gibt es die Kneipe noch, welche ich vor 2 Jahren eingetragen habe? Hatte ich damals alle Daten hinterlegt?... Von da an sehe ich die Sache entspannt. Ich ändere und ergänze Daten, meine Daten werden verändert... Ich korrigiere Straßenverläufe - welche damals bestimmt auch mit großer Sorgfalt aber mit anderen Technikgrundlagen hinterlegt worden sind. Navis haben bessere Chipsätze, zusätzliche Quellen wie der NRW-Atlas stehen zur Verfügung... Ich sehe das ganze positiv.

Das Projekt lebt - das ist für mich der wichtige Punkt.

Edit: Der grobe Entwurf steht - bitte einmal checken und dort Ergänzungen vornehmen. Danke. 🙂

Die wichtigsten Karten sollten jetzt auch in JOSM vorkonfiguriert sein, d.h. die Einträge erscheinen automatisch im Hintergrund-Menü, sobald die Hauptkarte einen Bereich in NRW geladen hat. (Siehe auch wiki)

Generell gibt es viele Ebenen auch in der transparenten Variante. (In der WMS-URL muss man dazu den Parameter &TRANSPARENT=TRUE anfügen.) Da diese dann aber auf der schwarzen Standardkarte nicht gut zu erkennen sind, habe ich die Version mit weißem Hintergrund gewählt.

Verbesserungen/Ergänzungen kann übrigens jeder selbst eintragen: http://josm.openstreetmap.de/wiki/Maps/Germany

Hallo,
ich suche schon eine Weile nach einer Möglichkeit mit den WMS Layern in JOSM komplett OFFLINE zu arbeiten.
Also nur Lokal auf einem PC von einem USB-Stick. JOSM kann ich schon mit JAVA so benutzen. 🙂

Wie kann ich die Hintergrundkacheln speichern oder wo werden die zwischengespeichert um sie offline nutzen zu können?

Danke!

In Westfalen gibt es wohl schon neuste Luftbildchen: http://www.wms.nrw.de/rssfeeds/content/ … l/018.html. Bin mir allerdings nicht schlüssig, ob es auch schon im NRW-Atlas drin ist.

In einer Ecke, hier in NRW, ist mir aufgefalen, dass neues Material vorliegt. Dieses wird circa ein Jahr alt sein. Auf den alten Bildern war das ursprünglich an der Stelle stehende Gebäude zu sehen. Nun sieht man den Baubeginn der neuen Häuser - diese sind aber schon fertiggestellt.

In Nienberge (Münster) und Lüdinghausen/Seppenrade (Kreis Coesfeld) sind es definitiv noch die alten Bilder.

Gruß
Simon

Oh Mann... wie viele Stunden ich heute schon wieder verbracht habe, die automatisch getracted Gebäude zu korrigieren... Ganz bescheuert ist auch, wenn Gebäude 8 oder 9 Mal übereinander gestapelt sind. Da sieht man, dass das wohl alles ohne Gegenkontrolle ablief 🙁

TobWen wrote:

Oh Mann... wie viele Stunden ich heute schon wieder verbracht habe, die automatisch getracted Gebäude zu korrigieren... Ganz bescheuert ist auch, wenn Gebäude 8 oder 9 Mal übereinander gestapelt sind. Da sieht man, dass das wohl alles ohne Gegenkontrolle ablief 🙁

Dafür gibt's jetzt die Änderungssatzdiskussionen. Einfach die schuldigen Änderungssätze andiskutieren und den Urheber um Reparatur bitten. Durch den Diskussionsbeitrag bekommt der User eine Benachrichtigungsmail, er kann deine "Ermahnung" also nicht verpassen. Wenn er eine Wegwerfadresse benutzt oder nicht reagiert, dann kann man sich überlegen, ob die Daten wirklich so wichtig sind und einen (Teil-)Revert erwägen. *duckundweg*

DD1GJ wrote:

Ich hatte bereits vor meinem obigen Beitrag mit der Behörde telefoniert und ausführlich über das Thema diskutiert, allerdings auf privater Basis, so dass es derzeit keine offiziellen Aussagen gibt.

Also ähnlich wie beim RVR damals, das Schreiben war so allgemein formuliert, dass keiner wusste, ob wir die Daten nutzen dürfen oder nicht 🙂
Ich weiß noch, wie ich damals mit mehreren Datenhaltern gesprochen habe: "Klar wollen wir OSM unterstützen und überlassen Ihnen den Datensatz - aber bitte nicht für die kommerzielle Nutzung" - mööp 🙂

Nakaner wrote:

• duckundweg*
  

Das denke ich immer, wenn ich die doppelten Daten lösche - natürlich versuche ich, immer die Nodes des gleichen Elements weiterzunutzen, soweit es geht. Ich habe keine Lust, ewig mit Mappern zu diskutieren, ob es jetzt ein 87° oder 90° Winkel ist, das habe ich damals mal gemacht und es ist echt destruktiv.

Das Problem bei den Änderungssätzen ist, dass sie oft recht groß ausfallen und eigentlich nur ein Teil eines Changesets schlecht ist. Wenn ich das ganze Ding "melde", geht das über's Ziel hinaus.

TobWen wrote:

Das Problem bei den Änderungssätzen ist, dass sie oft recht groß ausfallen und eigentlich nur ein Teil eines Changesets schlecht ist. Wenn ich das ganze Ding "melde", geht das über's Ziel hinaus.

Wenn es bloß ein paar Gebäude sind und das noch als "Versehen" oder "übersehen" durchgeht, dann würde ich es einfach stillschweigend korrigieren. Wenn es aber ein paar Dutzend Häuser sind, dann hätte ich keine Angst vor einer Changeset-Diskussion (ich vermeide das Wort "Kommentar"). Wie soll sonst der Mapper von seinem Fehler erfahren? Es ist ja keine Anklage oder Pranger.

Doppelungen kommen leider zwischendurch vor. Ich habe auch ein großes Gebiet abgegrast und mir sind später 2 Fehler aufgefallen. Dies aber auch erst in einem weiteren Arbeitsschritt. Ich habe die Vermutung, dass es da teilweise beim bearbeiten hakt. Mitunter kommt es vor, dass ich in bestimmten Zoomstufen den Umriss nicht nachzeichnen kann und eine Fehlermeldung in JOSM erhalte. Auch wird mir kein Gebäude angezeigt. Später hatte ich dann 2 Gebäude übereinander liegen - was seltsam ist, da Tracer2 alte Strukturen löscht. Ob dies mit einer bestimmten Version von JOSM auftrat oder auch ein Flüchtigkeitsfehler meinerseits gewesen ist kann ich aber nicht sagen, da es schon länger her ist. Es kann natürlich auch sein, dass man ein Gebäude auf einer Zoomstufe nachgezeichnet und sich das Bild leicht verschoben hat. Klickt man dann auf den freien Bereich kann es auch passieren, dass ein Gebäude doppelt eingezeichnet wird. Das ist der Nachteil an stupiden Arbeiten - trotz Kontrolle. 😉 Ich würde bei der o.g. Sache eventuell einen netten Hinweis geben, dass da versehentlich ein Gebäude mehrfach übereinander gezeichnet worden ist.

DD1GJ wrote:

ich wurde vor einem Monat von Gregor angeschrieben, der eine Frage zur Nutzung der WMS-Dienste des neuen NRW-Atlas als Mapping-Vorlage hatte. Aufgrund der üblichen, von uns nicht erfüllbaren Formulierungen mit der Namensnennung im optischen Zusammenhang habe ich eine entsprechende Anfrage an die zuständige Bezirksregierung Köln gestellt.

Bei der Bezirksregierung Köln hat sich serverseitig einiges geändert. Der Link zur Infoseite ist mittlerweile http://www.bezreg-koeln.nrw.de/brk_inte … index.html

Bei einer Verwendung der Darstellungsdienste des NRW-Atlas sind lediglich Nutzungsrechte einzuhalten, die sich im Wesentlichen auf die Kenntnisnahme von Nutzungsbedingungen und die Beigabe von Quellenvermerken reduzieren.

Mööp... das war's dann mal wieder. War ja eigentlich von Anfang an klar, das ist die übliche Krux von OpenData.

Die␣Nutzer␣haben␣sicherzustellen,␣dass
1.␣dem␣Dienst␣sowie␣aus␣diesem␣abgeleitete␣Präsentationen␣der␣Quellenvermerk␣©␣Geobasis␣NRW␣<Jahr>␣beigegeben␣und
erkennbar␣in␣optischem␣Zusammenhang␣eingebunden␣wird;

2.␣neue␣Gestaltungen␣oder␣sonstige␣Abwandlungen␣durch␣Kombination␣mit␣anderen␣Diensten␣mit␣einem
Veränderungshinweis␣im␣beigegebenen␣Quellenvermerk␣versehen␣werden␣oder,␣sofern␣der␣Lizenzgeber␣dies␣verlangt,␣der
beigegebene␣Quellenvermerk␣gelöscht␣wird;

3.␣die␣Bereitstellung␣durch␣den␣Dienst␣nicht␣die␣Merkmale␣einer␣amtlichen␣Standardausgabe␣enthält.
Mit␣der␣Nutzung␣des␣Dienstes␣gelten␣diese␣Bedingungen␣als␣anerkannt.

Es ist daher höchst fragwürdig, ob der Dienst für OSM genutzt werden darf.

TobWen wrote:

Bei einer Verwendung der Darstellungsdienste des NRW-Atlas sind lediglich Nutzungsrechte einzuhalten, die sich im Wesentlichen auf die Kenntnisnahme von Nutzungsbedingungen und die Beigabe von Quellenvermerken reduzieren.

Mööp... das war's dann mal wieder. War ja eigentlich von Anfang an klar, das ist die übliche Krux von OpenData.

Die␣Nutzer␣haben␣sicherzustellen,␣dass
1.␣dem␣Dienst␣sowie␣aus␣diesem␣abgeleitete␣Präsentationen␣der␣Quellenvermerk␣©␣Geobasis␣NRW␣<Jahr>␣beigegeben␣und
erkennbar␣in␣optischem␣Zusammenhang␣eingebunden␣wird;

2.␣neue␣Gestaltungen␣oder␣sonstige␣Abwandlungen␣durch␣Kombination␣mit␣anderen␣Diensten␣mit␣einem
Veränderungshinweis␣im␣beigegebenen␣Quellenvermerk␣versehen␣werden␣oder,␣sofern␣der␣Lizenzgeber␣dies␣verlangt,␣der
beigegebene␣Quellenvermerk␣gelöscht␣wird;

3.␣die␣Bereitstellung␣durch␣den␣Dienst␣nicht␣die␣Merkmale␣einer␣amtlichen␣Standardausgabe␣enthält.
Mit␣der␣Nutzung␣des␣Dienstes␣gelten␣diese␣Bedingungen␣als␣anerkannt.

Es ist daher höchst fragwürdig, ob der Dienst für OSM genutzt werden darf.

Jetzt verzapf mal keinen Scheiß! Hast du dir den Thread und insbesondere die Postings von Joachim Kast durchgelesen? Die Dienste dürfen zum Mappen genutzt werden.

Ich habe die neue URL der Übersichtsdeite nur gepostet, damit jemand, der den Thread über eine Suchfunktion findet, auch die aktuelle Übersichtsseite der Bezirksregierung findet.

Viele Grüße

Michael

Hast du dir den Thread und insbesondere die Postings von Joachim Kast durchgelesen? Die Dienste dürfen zum Mappen genutzt werden.

Yop, habe ich. Und ich muss doch meine starke Verwunderung aussprechen, wie solche Ausnahmegenehmigungen möglich sind und die offiziellen Nutzungsbedingungen nicht dementsprechend ergänzt wurden, damit wir Sicherheit haben.

Bislang galt für alle Sachen mit der gleichen Formulierung (GDI-DE), dass abgeleitete Daten bei der Darstellung ebenfalls mit dem Urheberrechtsvermerkt versehen werden müssten. Bestes Beispiel ist das Land Bayern: die Luftbilder darfst du angucken und einbinden, sobald du sie aber anders nutzt (Abdigitalisieren), musst du ein Entgelt leisten.

TobWen wrote:

Hast du dir den Thread und insbesondere die Postings von Joachim Kast durchgelesen? Die Dienste dürfen zum Mappen genutzt werden.

Yop, habe ich. Und ich muss doch meine starke Verwunderung aussprechen, wie solche Ausnahmegenehmigungen möglich sind und die offiziellen Nutzungsbedingungen nicht dementsprechend ergänzt wurden, damit wir Sicherheit haben.

Bislang galt für alle Sachen mit der gleichen Formulierung (GDI-DE), dass abgeleitete Daten bei der Darstellung ebenfalls mit dem Urheberrechtsvermerkt versehen werden müssten. Bestes Beispiel ist das Land Bayern: die Luftbilder darfst du angucken und einbinden, sobald du sie aber anders nutzt (Abdigitalisieren), musst du ein Entgelt leisten.

Es sei denn, der Lizenzgeber verlangt die Löschung des Namens/Herkunfthinweises. Über die Schiene sind m.E. einige Nutzungen in dem Bereich erlaubt. Ich meine, das das im OpenSeaMap-Vortrag auf der letzten FOSSGIS so gesagt wurde. https://www.youtube.com/watch?v=iVL5LZs_JCE ab ca. 14:00; konkret ab 21:00

ja: http://www.fossgis.de/konferenz/2014/pr … endata.pdf, Folie 12f.

gormo wrote:

Es sei denn, der Lizenzgeber verlangt die Löschung des Namens/Herkunfthinweises.

In NRW ist das übrigens im GeoZG NRW nicht vorgesehen, dafür aber in den Nutzungsbedingungen vom NRW-Atlas. Ich denke auch, dass Quellvermerk auf diese Seite aufgehoben wird, die erste Mail, die gepostet wurde, impliziert das ja indirekt, auch wenn ich mir eine konkrete Nennung der Ausnahme gewünscht hätte.

Bleibt zu hoffen, dass andere Länder und Kommen dies mit ihren OpenData-Datensätzen ähnlich machen.

Im NRW-Atlas (http://www.bezreg-koeln.nrw.de/brk_inte … index.html) steht jetzt auch eine aktuelle Version der DTK-25 (Topografische Karte 1:25.000 für das Land Nordrhein-Westfalen) via WMS zur Verfügung.

Gruß Klaus

PS: Der Hinweis darauf stammt von der OSM-Wochennotiz.

Seit 01.06.2015 hat sich ja anscheinend der WMS-Layer für "NRW Building" geändert --->http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Tracer2#Unterst.C3.BCtzte_WMS-Layer

Ich habe jetzt versucht, diesen Layer in JOSM (Version 8491) einzubinden, aber dieser Layer zeigt nichts an, entsprechend gibt es mit Tracer2 natürlich eine Fehlermeldung. Muss man immer noch eine alte JOSM (Version 7666) laufen lassen, damit Tracer2 noch funktioniert (aber damit funktioniert es auch nicht!) oder wo steckt mein Fehler? (Bitte nicht zu technisch antworten, sonst verstehe ich nur Bahnhof....)

Danke und Gruß
Andreas

https://lists.openstreetmap.org/piperma … 11293.html und die Antworten darauf

Wobei man mit den Einstellungen für tile size (Kachelgröße), resolution (Auflösung) und boundary (Schwellwert) durchaus experimentieren sollte, wenn die Ergebnisse nicht passen. Die wenigstens Ausreißer haben sich bei mir mit 0.0004, 512 und 80 ergeben. boundary=1 (wie auf talk-de empfohlen) lieferte z. B. vollkommen unbrauchbare Resultate.

Danke, funzt.

yzemaze wrote:

Wobei man mit den Einstellungen für tile size (Kachelgröße), resolution (Auflösung) und boundary (Schwellwert) durchaus experimentieren sollte, wenn die Ergebnisse nicht passen. Die wenigstens Ausreißer haben sich bei mir mit 0.0004, 512 und 80 ergeben. boundary=1 (wie auf talk-de empfohlen) lieferte z. B. vollkommen unbrauchbare Resultate.

Ich habe mittlerweile von boundary auf match color umgestellt und damit viel weniger Ausreisser bei ALKIS.
Schwellenwert hab ich auf 20.

Chris

chris66 wrote:

Ich habe mittlerweile von boundary auf match color umgestellt und damit viel weniger Ausreisser bei ALKIS.

Ich hatte auch (Anfang Juli schon?) auf match color umgestellt. Ausreißer waren danach extrem selten geworden.

Ich nutze ebenfalls diese Einstellung. Ich habe jedoch das Problem, dass meistens zu viele Nodes erzeugt werden. Diese muss ich dann immer von Hand löschen..

Gibt es hier einem Trick?

Man kann die Auflösung runtersetzen zB. auf 512, dies verringert aber generell die Genauigkeit der Erfassung.

Zu viele nodes kenne ich. Ich weiß nicht mehr genau, woran ich gedreht habe, aber mittlerweile hat sich das Problem erledigt. Meine Einstellungen sind wie folgt: 0.0004 1024 match color 127

yzemaze wrote:

Zu viele nodes kenne ich. Ich weiß nicht mehr genau, woran ich gedreht habe, aber mittlerweile hat sich das Problem erledigt. Meine Einstellungen sind wie folgt: 0.0004 1024 match color 127

Danke. 🙂 Ich hatte den ersten Wert auf 0.0002 stehen - ich teste es nun mit den neuen Einstellungen.

Hi,
nach JOSM Update (8855) bekomme ich beim Aufruf des ALKIS Layers die Warnungsbox:

Die Ebene NRW-ATLAS unterstützt die neue Projektion EPSG:3857 nicht.

Danach funktioniert es, allerdings mit leicht unscharfen Bildern.

Was muss man da machen?

chris66 wrote:

Hi,
nach JOSM Update (8855) bekomme ich beim Aufruf des ALKIS Layers die Warnungsbox:

Die Ebene NRW-ATLAS unterstützt die neue Projektion EPSG:3857 nicht.

Danach funktioniert es, allerdings mit leicht unscharfen Bildern.

Das Problem tritt bestimmt nicht nur mit 8855 auf, ich bekomme es auch bei JOSM-Rev. 8800.

Das heißt, dass der ALKIS-Layer nicht mehr in der Projektion EPSG:3857 bereitgestellt wird. Wer einen WMS-Dienst bereitstellt, legt fest, welche Projektionen er anbietet. Bei TMS-Diensten (also Tiles/Kartenkacheln) ist das meist EPSG:3857 (aka Google Web Mercator), eine winkeltreue Abbildung der Erde in die Ebene. JOSM arbeitet standardmäßig seit einigen Jahren mit EPSG:3857, weil wir zum Kartieren eine winkeltreue Projektion (das sind auch UTM, Gauß-Krüger und Soldner) benötigen. Sonst ist das Rechtwinkligmachen von Gebäuden für die Katz (das war früher ein Problem, als JOSM als Default EPSG:4326 (WGS84) hatte).

Die Fehlermeldung gibt jedoch aus, welche Projektionen der WMS-Dienst unterstützt. EPSG wird in der Wikipedia erklärt.

Meine Herangehensweise an das Problem war, von Hand einen GetCapabilities-Aufruf an den WMS-Dienst auszuführen (diese URL), man erhält ein XML-Dokument. In diesem stehen die unterstützten Projektionen. Hier ein Auszug:

	<Layer␣queryable="0">
<Title>WMS␣NW␣ALKIS</Title>
<Abstract/>
<SRS>EPSG:3034</SRS>
<SRS>EPSG:3035</SRS>
<SRS>EPSG:3043</SRS>
<SRS>EPSG:3044</SRS>
<SRS>EPSG:3045</SRS>
<SRS>EPSG:3857</SRS>
<SRS>EPSG:4258</SRS>
<SRS>EPSG:4326</SRS>
<SRS>EPSG:4647</SRS>
<SRS>EPSG:25831</SRS>
<SRS>EPSG:25832</SRS>
<SRS>EPSG:25833</SRS>
<SRS>EPSG:31466</SRS>
<SRS>EPSG:31467</SRS>
<LatLonBoundingBox␣minx="5.61272621360749"␣miny="50.2373512077239"␣maxx="9.58963433710139"␣maxy="52.5286304537795"/>
<BoundingBox␣SRS="EPSG:3034"␣minx="3709049.76521442"␣miny="2615389.86936955"␣maxx="3973095.82565026"␣maxy="2860306.8910878"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:3035"␣minx="4019710.31540201"␣miny="3018832.09529137"␣maxx="4293149.67372795"␣maxy="3272570.37933783"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:3043"␣minx="677418.087113981"␣miny="5568704.62708948"␣maxx="967304.789064305"␣maxy="5840266.68522106"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:3044"␣minx="269999.999998267"␣miny="5569999.99998812"␣maxx="540000"␣maxy="5820000"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:3045"␣minx="-157378.31788632"␣miny="5584010.57190092"␣maxx="133108.359988293"␣maxy="5856140.49886465"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:3857"␣minx="624805.824060843"␣miny="6487482.80837539"␣maxx="1067513.21129982"␣maxy="6896278.85886835"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:4258"␣minx="5.61272621360749"␣miny="50.2373512077239"␣maxx="9.58963433710139"␣maxy="52.5286304537795"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:4326"␣minx="5.61272621360749"␣miny="50.2373512077239"␣maxx="9.58963433710139"␣maxy="52.5286304537795"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:4647"␣minx="32269999.9999983"␣miny="5569999.99998812"␣maxx="32540000"␣maxy="5820000"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:25831"␣minx="677418.087113981"␣miny="5568704.62708948"␣maxx="967304.789064305"␣maxy="5840266.68522106"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:25832"␣minx="270000"␣miny="5570000"␣maxx="540000"␣maxy="5820000"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:25833"␣minx="-157378.31788632"␣miny="5584010.57190092"␣maxx="133108.359988293"␣maxy="5856140.49886465"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:31466"␣minx="2473731.14896592"␣miny="5566833.57364755"␣maxx="2753861.56283141"␣maxy="5827787.27262967"␣resx="1"␣resy="1"/>
<BoundingBox␣SRS="EPSG:31467"␣minx="3269981.38932302"␣miny="5571787.85498066"␣maxx="3540090.68662743"␣maxy="5821889.13382027"␣resx="1"␣resy="1"/>

Laut GetCapabilities liefert der WMS-Dienst Bilder auch in EPSG:3857 aus. Ich habe daraufhin testweise mit cURL mir ein Bildchen heruntergeladen:

URL: www.wms.nrw.de/geobasis/wms_nw_alkis?FORMAT=image/png&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=adv_alkis_siedlung,adv_alkis_gewaesser,adv_alkis_verkehr,adv_alkis_oeff_rechtl_sonst_festl,adv_alkis_bauw_einricht,adv_alkis_vegetation,adv_alkis_gebaeude,adv_alkis_flurstuecke&STYLES=&SRS=EPSG:3857&WIDTH=512&HEIGHT=512&BBOX=796492.943989,6732835.854562,796592.943989,6732935.854562

Für diese URL gibt der Server ein 200 OK und das gewünschte PNG-Bild zurück. Warum JOSM jetzt behauptet, dass der Server EPSG:3857 nicht unterstütze, weiß ich nicht. Ich werde gleich mal testweise einen anderen WMS-Client (QGIS) ausprobieren, ob der Fehler dort auch auftritt.

Was muss man da machen?

Nicht mit eingestelltem EPSG:3857 den WMS nutzen. Stattdessen die Projektion umstellen, ich empfehle hier für NRW westlich des 7,5-ten Längengrads den Gauß-Krüger Streifen 2, östlich davon den Streifen 3 zu wählen. (Bitte Gauß-Krüger auswählen und nicht die EPSG-Nummer eingeben.) Das geht unter F12 -> Koordinatengitter-Symbol -> Projektionsmethode -> Projektionsmethode. Dann funktioniert halt Bing nicht.

Noch besser ist es abzuwarten, bis der Fehler behoben ist.

Ok danke, also ein Bug in Josm.

Mit QGIS 2.0.1 tritt der Fehler nicht auf. Wie ich weiter oben schrieb, scheint es ein JOSM-Problem zu sein.

Nakaner wrote:

Mit QGIS 2.0.1 tritt der Fehler nicht auf. Wie ich weiter oben schrieb, scheint es ein JOSM-Problem zu sein.

Mit meinem QGis 2.12 auch kein Fehler, auch egal ob ich WMS 1.1.0 oder 1.3.0 anfrage.