Dorfupdate Hessen

[lkw]

Ich möchte einige Dörfer in meiner Gegend in Mittelhessen verbessern, die aktuell nur mittelmäßig gemappt sind. Insbesondere fehlt es an Adressdaten und Hausumringen. Die Hausumringe, die da sind, wurden vor Jahren von Bing abgemalt und sind manchmal mehr geraten als gewusst. Ich bin aus der Gegend, kenne die dörfliche Architektur und habe Erfahrung mit JOSM.

*Beispiele für solche Dörfer
**https://www.openstreetmap.org/#map=17/50.62724/8.82164
**https://www.openstreetmap.org/#map=17/50.45246/8.77669
*Beispiel, das kein Update braucht, da weitgehend vollständig gemappt
**https://www.openstreetmap.org/#map=17/50.61834/8.85282

Daten
Hessen hat seine Daten insbsondere shapefiles der Hausumringe, Orthophoto DOP20 (alle 2 Jahre aktualisiert) und Liegenschaftskarte mit Adressen für alle Anwendungen ohne Namensnennungspflicht veröffentlicht.
Das shapefile von HVBG möchte ich nutzen.
https://gds.hessen.de/downloadcenter/20220211/Liegenschaftskataster/Hausumringe%20(shape)/Hausumringe%20Hessen.zip Stand vom 08.11.2021
Lizenz https://hvbg.hessen.de/open-data (unten auf der Seite)

Vorgehen:
Schritt 1 vorhandene Geometrien präzisieren
*Shapefile auf 1 Dorf zurechtschneiden (siehe Datenvorbereitung)
*Shapefile in JOSM laden muit OpenData-Plugin (shape-Ebene)
*Tags an shapefile löschen
*OSM-Daten runterladen (Daten-Ebene)
*Verschiebe (Strg-X, dann Strg-Alt-V) die shapes von Häusern, die schon in der Datenbank sind, von der shape-Ebene in die Daten-Ebene
*Präzisiere Geometrie der vorhandenen Gebäude (Strg-Umschalt-G in JOSM), so bleiben bestehende Attribute (z.B Läden) und die History bestehen.
*Changeset schließen und hochladen, dabei auf Validator achten, insbesondere überlappende Gebäude, ungetaggte ways, doppelte Adressen, Fehler unter Verwendung von DOP und Liegenschaftskarte korrigieren.
*Nun haben die schon vorhandenen Gebäude die korrekte Geometrie und sind im zweiten Schrit nicht im Weg.

Schritt 2 Gebäude vervollständigen
*Verschiebe die shapes von Häusern, die noch nicht in der Datenbank sind, von der shape-Ebene in die Daten-Ebene
*Mit building=yes taggen and Adressen aus Liegenschaftskarte übernehmen
*Vergleich mit HESSEN DOP20 und bei Bedarf Häuser ergänzen oder löschen
*Die shape-Ebene sollte jetzt leer sein.
*Eventuell vorhandene addr:interpolation löschen
*Changeset schließen und hochladen, dabei auf Validator achten, insbesondere überlappende Gebäude, ungetaggte ways, doppelte Adressen, Fehler unter Verwendung von DOP und Liegenschaftskarte korrigieren.

Datenvorbereitung
Transformiere Daten von EPSG:4647 nach PSG:25832 (entfernt das Zone-32-Präfix, das beim Import in JOSM Probleme macht)
$ogr2ogr -f “ESRI Shapefile” -f “ESRI Shapefile” -s_srs EPSG:4647 -t_srs EPSG:25832 gebaeude-he_EPSG_25832.shp gebaeude-he.shp -progress
Finden der Koordinaten einer Box um das Dorf (auf https://www.geoplaner.de/, UTM 32U) und Zuschneiden der Daten:
$ogr2ogr -clipsrc gebaeude-he_EPSG_25832_.shp gebaeude-he_EPSG_25832.shp -progress

Warum nicht vom Luftbild abmalen?
Die Ortskerne sind oft eng bebaut und Schatten machen ein gutes Abmalen schwer.

Warum nicht von der Liegenschaftskarte abmalen?
Die shapefiles sind die selben Daten wie aus der Liegenschaftskarte und mit shapefile ist es einfacher und präziser.

Warum Adressen von Liegenschaftskarte abschreiben und nicht importieren?
Das manuelle Vorgehen (Adressen und building=yes taggen) zwingt dazu jedes Gebäude einzeln anzufassen und eventuelle Probleme zu erkennen. Da Adressen teilweise schon vorhanden sind, müsste man prüfen, welche schon da sind: Zu aufwendig und fehleranfällig.

Umgang mit schon getaggten Adressen, die von der Liegenschaftskarte abweichen:
Wenn die aktuellen Daten in OSM offensichtlich falsch sind (z.B. Zahlendreher, weit entfernte Straße, doppelte Adresse) werde ich das korrigieren. Im Zweifel werde ich die OSM Daten so lassen wie sie sind und ein fixme ergänzen.

Ich plane es alleine. Wer sich in der Gegend auskennt, kann sich gerne beteiligen.
Was habe ich noch nicht bedacht?

Ich beabsichtige keinen flächendeckenden Import auf Knopfdruck, sondern kleinräumige Änderungen, mit viel manueller Kontrolle.

[SafetyIng (Robin)]

@lkw

Warum nicht vom Luftbild abmalen?
Die Ortskerne sind oft eng bebaut und Schatten machen ein gutes Abmalen schwer.

Warum nicht von der Liegenschaftskarte abmalen?
Die shapefiles sind die selben Daten wie aus der Liegenschaftskarte und mit shapefile ist es einfacher und präziser.

Hier kann ich mit der Erfahrung aus Sachsen-Anhalt sagen, dass die Shapes machmal aktueller sind, aber auch manchmal tauchen Gebäude auf, die es teilweise seit 10 Jahren nicht mehr gibt. Also hier muss auf jeden Fall ein Abgleich mit den Luftbildern und ggf. OTG-Wissen passieren

[Jo_Cassel]

@lkw

[…]
Was habe ich noch nicht bedacht?

Ich beabsichtige keinen flächendeckenden Import auf Knopfdruck, sondern kleinräumige Änderungen, mit viel manueller Kontrolle.

Liest sich für mich gut durchdacht…

Ein Markieren der Objekte ist wohl nicht geplant,
möchte mal ein Tagging wie
source[:shape]=HVBG - Hausumringe [oder so, aber möglichst HE-einheitlich]
vorschlagen.

Grundsätzlich würde ich dich aber motivieren wollen, das einfach mal in einem kleinen village (oder in einem Teilbereich) probehalber durchzuziehen.
Sehr interessieren würde mich ein Erfahrungsbericht!

[woodpeck (Frederik Ramm)]

@Jo Cassel

source[:shape]=HVBG - Hausumringe [oder so, aber möglichst HE-einheitlich]

Find ich nicht so gut, ich würde sagen, ein Source-Tag am Changeset reicht. Das ist zwar nicht so präzise, aber OSM ist ja kein wissenschaftliches Werk, da reicht es mir, wenn ich später die History des Objekts durchschaue und sehe, aha, da hat einer mit HVBG-Hausumringen gearbeitet. Ich brauch das nicht an jedem einzelnen Objekt.

[Jo_Cassel]

… Naja, bin gerade an Grenzrelationen hessischer Dörfer (al=9) auf Basis “Digitale Verwaltungsgrenzen”
und kann den Fortschritt der boundary-Segmente ohne wissenschaftlichen Anspruch aber gut per OSM-source-Tag + overpass auswerten.
Und für Andere könnte eine derartige Info - direkt am OSM-Objekt - perspektivisch auch hilfreich sein.

[smootheFiets]

Ich bin aktiv im niederländischen BAG-Import-Team, in dem wir Gebäude und Adressen aus dem nationalen Kataster importieren. Das geschieht seit 2014, der work flow ist mittlerweile recht ausgereift. Was du vorhast, klingt im großen und ganzen ganz ähnlich. Insofern: Daumen hoch!
Ein Praxis-Tipp: die Dreifinger-Shortcuts für Kopieren von Layer auf Layer und für Geometrie verschmelzen (“merge geometry”) kann man in den JOSM-Einstellungen umdefinieren auf was einfacheres. Das spart viel Zeit und Fingerverknoten. Bei mir liegen die auf “v” und “b” (v hat, glaube ich, erst was anderes bedeutet, das musste ich erst umdefinieren. Weiß nicht mal mehr, was das war).

[surveyor54]

@lkw
Hi,
ich muss immer gleich alles ausprobieren.
Die Transformation hat funktioniert, aber bei Zuschneiden bekomme ich leere Dateien.

$ogr2ogr -clipsrc 9.148 50.235 9.160 50.237  gebaeude-he_EPSG_25832_Gettenbach.shp gebaeude-he_EPSG_25832.shp -progress
0...10...20...30...40...50...60...70...80...90...100 - done.

Was mache ich falsch?

Fragende Grüße

[lkw]

Nimm die UTM Koordinaten aus der grünen Box hier: https://www.geoplaner.de/

Ich habe die nordwestliche Ecke von Ober-Hörgern mal testweise bearbeitet:
https://www.openstreetmap.org/user/lkw/history#map=17/50.46429/8.75036

Dabei ist mir aufgefallen:
Die Gebäude im shapefile sind manchmal kleinteilig aufgeteilt. Das können Vordächer, Carports, Garagen oder Anbauten sein. Wenn aus dem Luftbild erkennbar ist, dass es fest verbundene Gebäudeteile sind, werde ich die Teile verbinden (Umschalt-J). Im Zweifel lasse ich es getrennt, weil es einfacher ist, bei Bedarf die ways zu verbinden als wieder auseinanderzubauen.

Das Bing-Bild ist zwar nicht so hochwertig wie das hessische Orthofoto aber etwas aktueller. Es lohnt sich also zu vergleichen.

Deshalb denke ich auch, dass es nicht so sinnvoll ist source an den Gebäuden zu setzen, weil mehrere Quellen zusammengeführt sind. Das ist bei den Grenzen anders, da gibt es genau eine Quelle.

Strg-X, dann Strg-Alt-V scheint nicht zu funktionieren, sondern nur Strg-C, dann Strg-Alt-V, wenn man in eine andere Ebene einfügt.

[surveyor54]

@lkw

Transformiere Daten von EPSG:4647 nach PSG:25832 (entfernt das Zone-32-Präfix, das beim Import in JOSM Probleme macht)

Wer lesen kann ist klar im Vorteil. Hier steht ja, dass man mit UTM-Koordinaten arbeitet und nicht mit WSG 84.

Danke für die gelungene Anleitung, funktioniert einwandfrei.

Edit:typo

[Map_HeRo (Mikke)]

@lkw

Die Hausumringe, die da sind, wurden vor Jahren von Bing abgemalt und sind manchmal mehr geraten als gewusst.

Dem kann ich nur voll und ganz zustimmen …

Dein Vorhaben hört sich für mich sehr gut an … leider fehlt mir noch jegliche JOSM Erfahrung, so dass ich da erst mal passen muss. Ich benutze den Layer mit der Liegenschaftskarte aber bereits permanent dazu, die Luftbilder (hier Bing besser als DOP20) zu interpretieren. Meine Erfahrung bisher:

Die Gebäude sind sehr kleinteilig erfasst (-> lkw #8).
Es sind Gebäude enthalten, die teilweise schon vor Jahren abgerissen wurden (-> SafetyIng #2).
Die Gebäude haben ähnlich den Luftbildern teilweise einen kleinen Versatz in unterschiedliche Richtung (~ 1-2 Meter).

Daumen hoch für Deine Aktion. Gibst Du uns mal ein Beispiel, wenn Du einen Ort fertig bearbeitet hast?

[seichter]

Anmerkung: Wenn die Gegend zunächst mit noch ungenau positionierten Bildern erfasst wurde, was man an den Umrissen von HVBG und OSM abschätzen kann, sind auch alle sonstigen Flächen und insbesondere Straßen verschoben.
Da empfiehlt es sich, genutzte Luftbilder gebietsweise auf die shape-Hausumringe zu korrigieren, das geht am besten mit niedrigen, isolierten Gebäuden wie Garagen. Damit kann man dann vorhandene Straßen etc. (am besten nach filtern) auf die neue Lage verschieben. Sonst bekommt u.U. massenweise Überschneidungen von Straßen und Gebäuden.

[Map_HeRo (Mikke)]

@seichter

Anmerkung: Wenn die Gegend zunächst mit noch ungenau positionierten Bildern erfasst wurde, was man an den Umrissen von HVBG und OSM abschätzen kann, sind auch alle sonstigen Flächen und insbesondere Straßen verschoben.

Nach dem, was ich hier in Nordhessen bisher gesehen habe, ist das eher nicht der Fall. Das Straßennetz ist deutlich besser erfasst als die Gebäudeumrisse. Siehe als Beispiel hier:

https://www.openstreetmap.org/edit#map=19/50.95688/9.78426

Das Straßennetz deckt sich weitgehend mit Hessen DOP20 und der Liegenschaftskarte, Bing ist minimal nach Nordwest versetzt, aber die Gebäudeumrisse entfliehen dem Bildmaterial in alle Richtungen … eher geraten als gewusst.

[skyper]

Oh, habt Ihr es gut in Hessen. In BW bin ich die ganze Zeit am Abzeichnen der Liegenschaftskarte, allerdings ist das hier ein Mix aus allem möglichen und Gebäude werden gerne auch mal überdeckt.

@woodpeck

@Jo Cassel

source[:shape]=HVBG - Hausumringe [oder so, aber möglichst HE-einheitlich]

Find ich nicht so gut, ich würde sagen, ein Source-Tag am Changeset reicht. Das ist zwar nicht so präzise, aber OSM ist ja kein wissenschaftliches Werk, da reicht es mir, wenn ich später die History des Objekts durchschaue und sehe, aha, da hat einer mit HVBG-Hausumringen gearbeitet. Ich brauch das nicht an jedem einzelnen Objekt.

+1

Als Tipp noch die Erweiterung “conflation”, welche beim Ersetzten einige Arbeit abnehmen kann. Bei aneinander anstoßende Gebäuden macht "Geometrie Ersetzen (Replace Geometry) allerdings nicht mit, da nur Knoten mit ausschließlich einer Linie ersetzt werden. Da habe ich auch noch keine Lösung für.

@lkw

Die Gebäude im shapefile sind manchmal kleinteilig aufgeteilt. Das können Vordächer, Carports, Garagen oder Anbauten sein. Wenn aus dem Luftbild erkennbar ist, dass es fest verbundene Gebäudeteile sind, werde ich die Teile verbinden (Umschalt-J). Im Zweifel lasse ich es getrennt, weil es einfacher ist, bei Bedarf die ways zu verbinden als wieder auseinanderzubauen.

Je nach dem. Gerade Dächer oder Garagen sind für mich eigene Gebäude, ansonsten gibt es ja auch noch building:part=*. Wenn ich auch noch die Dachform angeben will, brauche ich sie eh häufiger.

[lkw]

@skyper

Als Tipp noch die Erweiterung “conflation”, welche beim Ersetzten einige Arbeit abnehmen kann. Bei aneinander anstoßende Gebäuden macht "Geometrie Ersetzen (Replace Geometry) allerdings nicht mit, da nur Knoten mit ausschließlich einer Linie ersetzt werden. Da habe ich auch noch keine Lösung für.

In Neubaugebieten mit freistehenden Häusern geht das gut, aber in den Ortskernen wählt conflation nicht immer die richtigen Gebäude.

@skyper

Je nach dem. Gerade Dächer oder Garagen sind für mich eigene Gebäude, ansonsten gibt es ja auch noch building:part=*. Wenn ich auch noch die Dachform angeben will, brauche ich sie eh häufiger.

Ich würde es jetzt so ausdrücken:
Die Gebäude sind sehr kleinteilig erfasst. Zum Teil sollte man das so lassen, weil die Teile Garagen, Carports oder Vordächer darstellen. Auch Gebäudeteile, die zwar direkt zum Haus gehören, aber eigene Dächer haben, sollten getrennt gelassen werden, um ein späteres Erfassen der Dachform mit building:part zu erleichtern. Auch Reihenhäuser werden getrennt gemappt. Wenn aber kein Grund erkennbar ist, warum das shapefile das Gebäude trennt (kommt vor z.B. nachträgliche Verlängerung des Hauses in gleicher Form, ohne ein Reihenhaus zu bilden), können die Teile mit Umschalt-J verbunden werden. Eine sichere Entscheidung kann ohne Erkundung vor Ort nicht getroffen werden. Es ist einfacher nachträglich Gebäudeteile zu verbinden, als wieder auseinander zu bauen.

[Karthoo]

@skyper

Als Tipp noch die Erweiterung “conflation”, welche beim Ersetzten einige Arbeit abnehmen kann. Bei aneinander anstoßende Gebäuden macht "Geometrie Ersetzen (Replace Geometry) allerdings nicht mit, da nur Knoten mit ausschließlich einer Linie ersetzt werden. Da habe ich auch noch keine Lösung für.

Ich verwende dafür immer die Erweiterung ‘auto_tools’, da gibt es dieses Problem nicht. Einfach ein neues und ein altes Gebäude auswählen (wenn sich wie im Dorfkern mehrere überschneiden, ansonsten reicht es eins auszuwählen), Strg+Shift+A und der alte Umriss wurde durch den neuen ersetzt.

@skyper

Die Gebäude sind sehr kleinteilig erfasst. Zum Teil sollte man das so lassen, weil die Teile Garagen, Carports oder Vordächer darstellen. Auch Gebäudeteile, die zwar direkt zum Haus gehören, aber eigene Dächer haben, sollten getrennt gelassen werden, um ein späteres Erfassen der Dachform mit building:part zu erleichtern.

Ich habe vor ein paar Tagen auch mal mit einem Dorf-Update in Südhessen angefangen und dabei ist mir auch aufgefallen, wie kleinteilig die Gebäude erfasst sind. Ich habe die kleinen Anbauten so gut es ging aber mit den Gebäuden gemerget (Shift+J) - außer Überdachungen, die habe ich als building=roof oder teilweise direkt als building:part getaggt. Die restlichen building:parts kann man auch später noch über den LiKa-Hintergrundlayer erfassen. Vor allem auch da building:parts von den building-Ways umschlossen sein müssen, finde ich dass man die Anbauten, die jetzt nicht was komplett anderes wie Garagen oder Scheunen sind und wohnlich genutzt werden, direkt mit dem Haupthaus gemerget werden können.

[skyper]

@lkw

@skyper

Als Tipp noch die Erweiterung “conflation”, welche beim Ersetzten einige Arbeit abnehmen kann. Bei aneinander anstoßende Gebäuden macht "Geometrie Ersetzen (Replace Geometry) allerdings nicht mit, da nur Knoten mit ausschließlich einer Linie ersetzt werden. Da habe ich auch noch keine Lösung für.

In Neubaugebieten mit freistehenden Häusern geht das gut, aber in den Ortskernen wählt conflation nicht immer die richtigen Gebäude.

Stimmt, da braucht es zum Teil dann manuelle Zuordnung oder ein bisschen Spielerei mit dem Algorithmus der Zuordnung.

@Karthoo

Ich verwende dafür immer die Erweiterung ‘auto_tools’, da gibt es dieses Problem nicht. Einfach ein neues und ein altes Gebäude auswählen (wenn sich wie im Dorfkern mehrere überschneiden, ansonsten reicht es eins auszuwählen), Strg+Shift+A und der alte Umriss wurde durch den neuen ersetzt.

Oh, danke, muss ich mal testen. Heißt dann aber auch, dass Hoffnung besteht, dass “Geometrie Ersetzen” (Replace Geometry) das in Zukunft auch hinkriegt.

[skyper]

@skyper

@Karthoo

Ich verwende dafür immer die Erweiterung ‘auto_tools’, da gibt es dieses Problem nicht. Einfach ein neues und ein altes Gebäude auswählen (wenn sich wie im Dorfkern mehrere überschneiden, ansonsten reicht es eins auszuwählen), Strg+Shift+A und der alte Umriss wurde durch den neuen ersetzt.

Oh, danke, muss ich mal testen. Heißt dann aber auch, dass Hoffnung besteht, dass “Geometrie Ersetzen” (Replace Geometry) das in Zukunft auch hinkriegt.

Mmh, als erstes gleich mal eine NPE, https://josm.openstreetmap.de/ticket/21864 bzw https://github.com/JOSM/auto-tools/issues/16.
Mit building=yes an der neuen Linie wird die Aktion zwar ausgeführt, aber es besteht exakt das gleiche Problem wie mit dem Original “Geometrie Ersetzen”(Replace Geometry) von utilsplugin2: Knoten welche mehr als eine Linie als Eltern haben werden nicht ersetzt. Bringt mich leider nicht weiter. Schade

[surveyor54]

@skyper

… Knoten welche mehr als eine Linie als Eltern haben werden nicht ersetzt. …

Das ist mir auch schon aufgefallen.

Ich habe leider von tickets keine Ahnung.

Wird sich hier in geraumer Zeit etwas tun, oder müssen wir damit leben?

Fragende Grüße

[skyper]

@surveyor54

@skyper

… Knoten welche mehr als eine Linie als Eltern haben werden nicht ersetzt. …

Das ist mir auch schon aufgefallen.

Ich habe leider von tickets keine Ahnung.

Wenn Du einigermaßen der englischen Sprache mächtig bist, sollte es nicht so kompliziert sein. Ansonsten sind andere Sprachen auch OK allerdings ist die Anleitung nur auf Englisch. Ich verwende eigentlich immer die Option direkt in JOSM “Fehler berichten” unter dem Hauptmenü “Hilfe”. Bei Wünschen ist das dann halt ein “enhancement” und kein “defect” als Typ (Type).
Wichtig ist eine möglichst genaue Beschreibung mit allen Schritten zum besseren Nachzuvollziehen.

@surveyor54

Wird sich hier in geraumer Zeit etwas tun, oder müssen wir damit leben?

Habe gerade #9929 gefunden. Weiß jetzt nicht was für ein Zeitgefühl Du hast und was “geraume Zeit” im Verhältnis zu acht Jahren ist. Was helfen könnte, ist sich an der “Abstimmung” zu beteiligen, indem Du Dir einen Account auf dem JOSM server einrichtest und dann oben direkt unter der Querleiste Deine Stimme abgibst. Im Moment sind wir bei “+2” und ich denke ab “+10” wäre die Priorität um einiges höher.

[surveyor54]

Danke für die Info.
Ich habe erst einmal meine Stimme abgegeben.