Straßenbaumkataster Hamburg importieren

Ich möchte das Straßenbaumkataster Hamburg kontinuierlich (alle 1-2 Jahre) importieren. Schon vor einer Woche auf der Hamburger Mailingliste gepostet, aber leider keine Antwort erhalten.

Lizenzfragen sind abschließend geklärt.

Alle Informationen finden sich hier:
https://wiki.openstreetmap.org/wiki/Import/DE:Straßenbaumkataster_Hamburg

Gibt es da Fragen und Kommentare zu? Hat jemand Lust, beim Review zu helfen?

3 Likes

Ohne Bezug zu Hamburg und ohne Arbeitslust finde ich das als langfristiges OSM-Projekt interessant/unterstütenswert.

Ausdrücklich auf die Schnelle, ohne alle Quellen/deine Links erfasst zu haben:
Mein Hauptbedenken ist der Umgang mit dem bestehenden OSM-Baumbestand vor Ort
und spontan nebenbei:
Wenn species (amtlich)bekannt ist Erfassung von genus (in OSM)überflüssig
Würde dir grundsätzlich raten kleinräumig auszutesten und erst danach auszudehnen.

1 Like

Finde ich grundsätzlich begrüßenswert, insbesondere, da dadurch sehr viele genus- und Größen-Informationen (und sicherlich auch viele neue Bäume an sich) in die Datenbank kommen, die von zunehmendem Interesse sind.

Habt ihr/hast du dir mal einen “empirischen” Überblick über die Qualität der Daten verschafft? Vermutlich wird die sehr hoch sein, aber es könnte nicht schaden, das mal genauer anzusehen. (Ich hab das vor vielen Jahren mal für einen Stadtteil in Berlin gemacht.) Oder über das Verhältnis bereits vorhandener/neu hinzukommender Bäume?

Was ich für lokale Datenauswertungen nützlich finden würde, wäre noch ein Tag wie object:street für den Straßennamen (strasse im Originaldatensatz) sowie einen denotation und/oder owner/ownership-Tag. Je nach dem, wer/warum mit den Daten arbeiten will, kann so ganz einfach und geometrisch “sicher” straßenzugsweise Auswertungen machen oder beispielsweise Straßenbäume von anderen, z.B. Anlagen-, Garten- oder anderen privaten Bäumen machen.

1 Like

Einen empirischen Überblick über den Datensatz kann man sich auf der Seite des Geoportals Hamburg verschaffen:

https://geoportal-hamburg.de/geo-online/?mdid=C1C61928-C602-4E37-AF31-2D23901E2540


genus mag zwar überflüssig sein wenn species angegeben ist, aber wenn die Daten schonmal vorhanden sind, wieso nicht auch eintragen, würde ich sagen. Es mag Datennutzer geben, für die nur das gröbere genus von Interesse ist.


Was ist denotation? Wozu würde man straßenzugsweise Auswertungen machen? Und wieso sollte man dann nur die Straßenbäume darin haben wollen, statt auch die Bäume auf Privatgrundstücken, auf Spielplätzen und Parks?

We sich nur für genus interessiert, kann diese info ganz einfach aus species auslesen. Beides zusammen ergibt m.E. überflüssige redundante Daten.

Aber grundsätzlich natürlich :+1:

Hoffentlich wirst Du die Daten nur sinnvoll importieren und nicht so pseudogenau, wie die Kollegen in Strassburg, die den Stammumfang auf ganze Millimeter angeben :wink:
Oder auch mit “0.0:face_with_monocle:
Die Schwierigkeit wird sein, bei nächsten Aktualisieren alle berechtigten manuellen Änderungen (“den Baum gibt es vor Ort nicht”) zu berücksichtigen.

Man sollte dabei bedenken, dass sonst die Bereitschaft vor Ort für OSM irgendetwas zu kontrollieren sinken wird. Es gibt dafür dann immer weniger Gründe, weil es quasi ständig wieder “automatisiert” überschrieben werden würde. Wenn sich OSM in diese Richtung entwickelt, dann ist das OK. (Aber irgendwann nicht mehr meine Welt.)

Analog: In letzter Zeit wurden bei uns die Bushaltestellen so “aktualisiert”. Inklusive der Datenbankfehler. Bin mir nicht sicher, wie oft ich dann noch Fehler verbessere, wenn das wieder auf “amtlichen Stand” gebracht wird.

4 Likes

Naja, ein Maßband hat eben auch Millimeter drauf. Wer weiß, vielleicht sind in Straßburg ebenso detailversessene Kollegen im Baumkatasteramt unterwegs, wie in OSM für andere Bereiche :slight_smile:

Die Stammumfänge in Hamburg werden im Kataster jeweils in Zentimetern angegeben.

Die Schwierigkeit wird sein, bei nächsten Aktualisieren alle berechtigten manuellen Änderungen (“den Baum gibt es vor Ort nicht”) zu berücksichtigen.

Ja, das ist schwierig. Ich sehe auch nicht wie man das abschließend lösen kann, denn es gibt keinen sinnvollen Weg in OSM, gelöschte Objekte (eines bestimmten Typs) innerhalb einer Bounding Box abzufragen. Daher gibt es wohl das tag was:natural=tree (oder auch natural=tree_stump). Mapper in Hamburg könnten also statt den Node zu entfernen, diesen so umtaggen und die Baumnummer in ref:bukea=* weiterhin erhalten.

Ich habe das Import-Script schon so geschrieben, dass bei Neu-Import wenn das Bearbeitungsdatum des Baumes neuer ist als das Veröffentlichungsdatum des Baumkatasters, der Baum aus dem Kataster nicht das Objekt aus OSM überschreibt, sondern verworfen wird.
Das heißt auch, wenn jemand den Stammdurchmesser in der Zwischenzeit aktualisiert, und die Baumkatasterdaten beim Import älter sind, dass der aktualisierte Stammdurchmesser in OSM erhalten bleibt.

Du siehst, ich habe mir schon Mühe gegeben… ist alles auf der anfangs verlinkten Wiki-Seite beschrieben. Und selbst wenn doch ein solcher Fehler passiert, sollte er dann ja beim nächsten Import des Katasters im nächsten Jahr behoben sein. Wir haben ja ähnliche resultierende Probleme mit jeglichen Luftbildern mit denen man in JOSM und iD mappt: Es kann sein, dass ein Baum (ein Haus, ein XYZ, …) noch auf diesen Bilder zu sehen ist, aber tatsächlich ist er nicht mehr da.

Für Straßenbäume wäre für mich genus die bessere Angabe…

Beispiele: unsere geliebe Linde ist ein gerne genommener Straßenbaum… Hier gibt es aber häufig Verwendungen, die Kreuzungen aus Winter- und Sommerlinde bestehen. Vergleichbar ist es mit Stiel-Eiche vs. Trauben-Eiche… Hier sind selbst in der Natur Hybriden nicht selten.

So zieht es sich durch die ganze Welt kultivierter Pflanzen (incl. Gehölze). Hinzu kommen noch Kultivare, spezielle Züchtungen…

Selbst ich oder sogar gestandenene Botaniker mit ihren ganz speziellen Artkenntnissen haben mitunter da so ihre Probleme in der AdHoc-Ansprache vor Ort…

Es ist nett, species zu haben, Ich halte es überwiegend für verzichtbar, da es eh kaum Leute gibt, die OSM-aktiv sind und zugleich Deailkenntnisse haben, die nur zu 100% am Objekt vor Ort recherchierbar sind und wo es selbst dann zu Unklarheiten kommen kann…

Sven,

…berufsbedingt tiefere Artkenntnisse bei Pflanzen habend…

Mit empirisch meinte ich eher eine Einschätzung der Fehlerquote durch Stichprobenvergleich, z. B. Standortabweichungen, fehlerhafte Attribute etc… Wäre vielleicht sogar ne gute Sache für den Import, offensichtlich falsche Werte nicht zu übernehmen (100m Durchmesser und solche Späße - wird es sicherlich geben, zumindest in Berlin kommen unplausible Werte regelmäßig vor).

Ich habe viel mit OSM-Daten im (kommunal-)politischen Kontext zu tun und da sind fast immer nur öffentliche Infrastrukturen von Relevanz, weil man über diese öffentlich bestimmen kann. Wer solche Daten aus einer Stadtentwicklungsperspektive nutzt (und dazu gehört auch Zivilgesellschaft, für die OSM-Daten erfahrungsgemäß leichter zu handhaben sind als Primärquellen wie hier das Baumkataster), freut sich vielleicht, sie klar “filtern” zu können. Konkretes Beispiel aus eigener Erfahrung: Im OSM-Parkraumprojekt würden wir gern ein Verhältnis von Straßenparkplätzen zu Straßenbäumen visualisieren (beide Variablen sind öffentlich/politisch verhandelbar), aber Straßenbäume sind in OSM nur selten als solche identifizierbar (z. B. über einen der genannten Tags).

P. S. Falls sich das Import-Verfahren bewährt, haben bestimmt auch andere Local Communities Interesse dran :blush:

1 Like

wiki/DE:Key:denotation

Wie gehst du mit bereits in OSM erfassten Baumreihen um?

Wenn du schon dabei bist, sollte imho auch gleich leaf_type=* und leaf_cycle=* mit getaggt werden.

Interessant finde ich das die Baumhöhe beim Kataster anscheinend gar keine Rolle spielt.

Alle neuen Straßenbäume aus dem Kataster deren Mittelpunkte weniger als 2 Meter vom Mittelpunkt eines in OSM bereits vorhandenen Baumes entfernt sind, werden automatisch mit dem Baum in OSM zusammengeführt .

Zwei Bäume können ja durchaus sehr nah zueinander (< 2m) stehen. Eine automatische Zusammenführung halte ich daher für problematisch. Oder kann das für die Bäume im Kataster Hamburg ausgeschlossen werden?

Ich denke auch, dass man da stark manuell nacharbeiten muss.
Die Daten OSM vs. Kataster sehen in Hamburg ungefähr so aus:

Natürlich ist das theoretisch möglich. Aber erstens geht es um die Mittelpunkte der Stämme (d.h. tatsächliche Distanz ist geringer) und zweitens ist das nicht üblich bei Straßenbäumen. In Parks, auf Spielplätzen usw. sehe ich das häufiger, aber diese Bäume sind nicht Teil des Straßenbaumkatasters.

Was viel häufiger der Fall ist, eigentlich immer, ist, dass die Bäume in OSM um 1-3 Meter ungenau gemappt wurden. Wieso so ungenau? Weil sie von Satellitenbildern gemappt wurden, und da sieht man den Stamm nicht so gut, insbesondere in Bildern mit belaubten Bäumen. Also wurde die genaue Position des Stammes oft geschätzt - oder auch dem Versatz den alle Objekte dank leicht misalignten Satellitenbildern haben, angepasst.

Aber wie dem auch sei, der Fall dass zwei Bäume sehr dicht aneinander stehen, ist in dem Programm berücksichtigt. Im Zweifelsfall kippt das Programm diese Bäume dann in die manuell zu überprüfenden Datensatz. Wo ich @milet s Screenshot sehe, insbesondere die Ecke da ganz links unten, sollte ich noch vorsichtshalber einbauen, dass wenn mehr als ein Baum unter 2 Metern von einem Straßenbaum entfernt ist, diese dann nicht automatisch zusammengeführt werden sondern manuell reviewt werden müssen. Ich mache mir dazu eine Notiz auf der Talk-Seite der Import-Seite.

@milet , auf der Wiki-Seite ist beschrieben, nach welcher Logik die Datensätze gemergt werden.

@Map-Peter : Baumreihen werden zzt. ignoriert. Die Anzahl ist auch garnicht mal so gering overpass turbo … ich mache mir dazu eine Notiz. Ich glaube es wird auf manuelles Review vor oder nach dem Import hinauslaufen, so oder so muss es dann auf der Import-Seite beschrieben werden.

Übrigens, @Jo_Cassel , find ich total gut dass du mitmachen möchtest! Und wenn jemand noch dazu Lust hat, gerne noch dazu kommen! Ich bin die Woche erstmal bei der SotM in Antwerpen, aber danach könnte man direkt loslegen, wenn ansonsten alles geklärt ist. (Ich melde mich.)

Du beschreibst, dass dann aber die vorhandenen Daten in OSM durch die Katasterdaten überschrieben werden. Das finde ich nicht so gut. Wenn Du anhand der Position (2m-Radius) ein OSM-Objekt identifizierst, dass wahrscheinlich einem bestimmten Baum im Kataster entsprechen soll und dann die Daten abweichen, dann sollte eine manuelle Prüfung stattfinden. Wenn die vorhandenen Daten übereinstimmen, dann kann man natürlich dies als Bestätigung ansehen und die restlichen Daten aus dem Kataster ergänzen.

1 Like

Also, den Output des Programmes habe ich schon mit den OSM Daten verglichen, daher kommen überhaupt diese Zahlen (0-2 und ab 8 Meter), weil ich gesehen habe, dass die OSM Straßenbäume bisher halt nicht so sehr genau an der richtigen Stelle stehen.

Ein manuelles Review in diesen Fällen bringt sehr wenig bis nix und ist zugleich sehr aufwändig (etwa 20000 Straßenbäume, also 10% sind bereits in OSM gemappt), da man als Reviewer ja auch nur das Satellitenbild zur Verfügung hat. Auf Satellitenbildern kann man auch nicht wirklich sehen, ob das ein Baum ist, oder 3 extrem dicht aneinander stehende, was ja der Grund ist, warum die Positionen der Bäume überhaupt voneinander abweichen.
Oder, um es klar zu sagen: Kein einziger Baum in OSM steht genau an der gleichen Stelle wie der dazugehörige Baum im Straßenbaumkataster.

Schau mal selbst, @OSM_RogerWilco , unten eine Anleitung


Wer mal selbst schauen mag, hier die Anleitung wie man das Programm benutzt:

  1. Java installiert haben
  2. https://github.com/westnordost/hh-import-trees/releases/download/v0.1/hh-import-trees-0.1.jar herunterladen
  3. https://daten-hamburg.de/umwelt_klima/strassenbaumkataster/Strassenbaumkataster_HH_2022-07-28.zip herunterladen und entpacken. Die GML-Datei ist die wichtige
  4. in Commandline java -jar hh-import-trees-0.1.jar wfs_hh_strassenbaumkataster_2022-08-02.gml eingeben, enter
  5. Es fallen zwei Dateien raus. Die ...-neu.osm sind die zu-reviewenden Daten (2-8m von OSM-Bäumen entfernt). Die ...-aenderungen.osc sind die Änderungen die ohne Review übernommen werden. Beide könnte man dann in verschiedene Layer in JOSM tun und sie dort mit den OSM-Bäumen vergleichen.

(Overpass-Abfrage für alle Bäume in Hamburg:

area(3600062782)->.searchArea;
node["natural"="tree"](area.searchArea);
out meta;

)

P.S: natürlich NIX hochladen!!

20.000 Bäume mit widersprüchlichen Daten? Mir geht es um Bäume, dessen aktuelle Daten Du trotz Abweichung überschreiben möchtest. Für mich wäre das ein Indiz, dass man eine falsche Zuordnung von Kataster-Objekt zu OSM-Objekt hat. Warum auch immer - Baum wurde zwar mit richtigen Daten erfasst aber 10m falsch positioniert, etc. Es können aber einfach nur die OSM-Daten falsch sein. Natürlich kann man solche Konflikte nur vor Ort auflösen.

Das sind keine widersprüchlichen Daten. Wie gesagt, schau es dir selbst an.

Ein leichter Versatz ist vollkommen normal beim von-Luftbild-mappen. (Wie viele Änderungen an Objekten in OSM bestehen aus leichtem hin- und herschieben von Nodes?) Der Versatz ist bei Bäumen ein wenig größer weil es auf Luftbildern verglichen mit Gebäuden und Straßen schwieriger ist, die genaue Position des (Mittelpunktes des) Stammes zu erkennen. Wir sprechen von Abweichungen von bis zu ein paar Metern, nicht von 10 Metern.

Ich glaube, Du hast mich noch nicht verstanden. Vielleicht hilft ein Beispiel:

Baum A ist in OSM als Eiche getaggt. Dieser hat jetzt wegen der Position (Radius 2m) ein Match mit Baum X aus dem Kataster. Baum X ist im Kataster ein Ahornbaum. Wenn ich Dich richtig verstanden habe würde die Eiche in OSM dann zum Ahornbaum automatisch umgetaggt, richtig?

Achso. Ja stimmt. Ich notiere das mal auf der Talk-Seite des Imports.