Straßenbaumkataster Hamburg importieren

[OSM_RogerWilco]

Mein Beispiel mit den 10 m von oben war nur ein Szenario, warum an der Stelle vom real existierenden Ahron in OSM eine Eiche steht. Es ist z.B. möglich, dass …

• der Ahorn falsch getaggt wurde (Baumattribute in OSM sind falsch).
• in 10 m Entfernung tatsächlich eine Eiche steht, die auch vor Ort richtig erfasst wurde und später von jemanden (nach Luftbild) an die Position vom Ahorn verschoben wurde. (Position in OSM ist falsch).
• …

[SK53]

Sorry haven’t read all the replies as I’ve been looking at the data. Broadly it looks good:

Basic values are roughly in expected ranges (but note 0 in the pflanzejahr field):

Suggestions of some outliers, which need to be checked (circumference cf. height):

More detailed breakdown with potential outliers (sorry graph labels are slightly offset):

Data used as CSV, imported into R for some basic cross-checks. I think actual geographical location check has been mentioned by @milet). An existence check should be carried out on a sample (at least 200 trees I’d suggest) and involve basic checks that the other values are correct. On the Birmingham tree dataset I did this for just under 200 trees or 1% of the total and the basic error rate was around 6%. The oddest one being a few dozen trees which did not belong to the city, but most were trees having died been replaced, or removed. There were also species errors (Turkish Hazel, a tree as ordinary Hazel (Nussbaum)), but these were mainly obvious on inspection.

Remarks on tags:

Keeping genus is extremely useful for general use, and as @streckenkundler remarks is likely to be reliable when species may be incorrect. In my experience this is particularly true with rare/unusual trees in a genus which were not familiar to the person entering the data, who then assigns them to a common species.

I would retain sorten and follow the convention used in the Vienna tree import of taxon:cultivar='Globosum' for sorten_latein='Acer platanoides 'Globosum' etc. Many street trees will be chosen from particular cultivars for aesthetic or practical reasons and some (e.g., Populus nigra ‘Italica’ are familiar to most people. The entire construction can be placed in the taxon tag if desired.

A few remarks about taxonomy of the trees (not exhaustive):

• Sophora is an old name and the current generic name is Styphnolobium
• Sorbus might be problematic (although I don’t think so) because it was split recently into 7 different genera. Although widely adopted in the UK, at least, the experts believe this change is premature.
• Genera which are mainly shrubs should be checked, examples Cornus, Corylus, Euonymus, “Sambucus” possibly Rhus (Essigbaum). Salix may also include shrubs
• Mischbestand (fortunately only 1) and those with genus absent need to be treated with caution. In the UK one often finds things like “new tree”, “empty pit” in these entries.

For wikidata tags I would recommend using one corresponding to the actual taxon entered (e.g., if Sophora is retained use wikidata for Sophora japonica). Wikidata handles current synonymies reasonably well, and this allows better cross-referencing to original data. This can be important because at a national level the accepted scientific name of a species may be different to that advocated by places like wikipedia, IPNI or iNaturalist. Often there are good reasons for this, and it helps anyone used to the regular names in floras (e.g., Rothmaler) and other works.

Hope this helps

PS. I’ll look at species & cultivar values and add anything else which crops up in this thread.

[westnordost]

…wow!

Thank you for this!

I’ll add at least one todo: ignore pflanzjahr if 0. Also, we should check the outliers. Maybe even not automatically import trees with a stammumfang greater than 600 cm (= ⌀ 2m)?

Regarding sorte, from a quick look, it looked like the sorte field was always identical to the species. Is it not, in some cases? And if it is not, can you explain more how to get the cultivar from the “sorten latein” field? I mean, is it always the last word, or could it be several words?

[SK53]

You can do a straight comparison between art and sorte, for instance, in QGIS:

trim(replace( regexp_replace( "sorte_latein" , "art_latein" ,'') ,'''',''))

You can use this as a test or to generate suitable text.

For example, the Lombardy Poplar (Populus nigra ‘Italica’) then has the specific name removed, and the single quotes removed around the cultivar name to give taxon:cultivar=Italica. The quotes are necessary to show that it is a cultivar name, but if the tag is explicit I think this is redundant. Other good examples of cultivars are fruits which you buy in the shops Pyrus communis ‘Conference’, Malus domestica ‘Golden Delicious’ etc. So usually one word, but some older ones two or more, they should be enclosed in single quotes.

a few other things:

• quite a few rows (around 5000) with “Genus spec” or simply “Genus” in the art_latein field (i.e., species not known). These need to only be populate the genus tag.
• a few rows with an extra word (or letter) after the specific name (see Castanea): a basic check for a those not meeting a regular expression of “Word1 word2” should find them
• there are some forms, where the form (f. formname) will need to be trimmed off to get the species name (Gleditsia triancanthos f. inermis). Leave the whole thing in taxon (which is very flexible). Forms are similar to cultivars but do not have confirmed parentage. In this case planted Gleditsia tend to be ones without thorns (inermis) and this characteristic may arise independently many times. See below on Corkscrew Willow.
• Platanus x hispanica (26) is the same species as Platanus acerifolia (9925), but various authorities have different views as to who first described the species scientifically. As these are documents from the 18th century it is not easy to resolve & I have been unable to find an official judgement from the ICBN on the matter. FWIW in the UK we use the former. I’d move all to Platanus acerifolia here.
• Willows. Corkscrew willow (Salix matsunda f. tortosa or ‘Tortosa’) is these days regarded as Salix babylonica. See Plants of the World Online. You can leave it as in the current form it is clear what is meant. Salix alba ‘Tristis’ is almost certainly Golden Weeping Willow and should be tagged like this one. Note how this shows how wikidata allows for some cultivars. This taxon goes by many, many different names in tree registers, nearly all wrong!
• Hybrid trees: the common street lime has been mentioned, but Populus canescens and Populus berolinenis are hybrids too, as are a few others. To be absolutely correct an ‘x’ is placed between the genus and specific epithet, but there is no ambiguity if omitted.
• Plant taxonomy is an art, and although it’s been going for nearly 300 years and has a complex rule book, it’s still a bit like OSM tagging.

[westnordost]

Great findings! You seem to be really an expert on this field, is it anything related to your daytime job?

I guess some things are not that important from a data import point of view, such as that some (outdated?) synonyms of certain species are used. I guess any data user interested in species data will also need to understand and merge the data from different tags (wikidata:species, species, species:XX) and be able to understand what is synonymous, anyway.
(Maybe it is also worth reporting these things back to the city, only that I do not know which are kind of mistakes and which are kind of opinions. You could copy&paste the things you consider mistakes and write me an email and I’ll translate them to German and forward these to the city. If you like.)

For some of the other points you mention, I am not sure exactly what you mean. And as I will be in Antwerp this weekend and some days after, will not be able to act upon them, such as making the import script aware of these things, e.g. extract the taxon from the sorte_latein etc.

Now, I do not want to steal your thunder, so if you like, feel free to fork and contribute to hh-import-trees - the function where a Kataster tree is transformed into a OSM tree is here: https://github.com/westnordost/hh-import-trees/blob/main/src/main/kotlin/KatasterParser.kt#L74-L95 , the merging of the datasets is done in Main.kt

I’ll be back mid next week.

[Nakaner]

@westnordost

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.

Man kann zwar die anderen Mapper dazu anhalten, gefällte Bäume nicht zu löschen, sondern nur umzutaggen. Es gibt dennoch Möglichkeiten gelöschte Objekte zu ermitteln. Du kannst auf https://osm-internal.download.geofabrik.de/ regionale OSM-Extrakte mit kompletter Versiongeschichte herunterladen (gleiche regionale Aufteilung wie beim öffentlichen Download-Angebot ohne personenbeziehbare Mapper-Informationen). Mit osmium time-filter kannst du einen Snapshot zu einem bestimmten Zeitpunkt in der Vergangenheit machen. Mit osmium tags-filter kannst du die Bäume aus dem Snapshot extrahieren. Anschließend kannst du z.B. mit einem eigenen Skript in einer Programmiersprache deiner Wahl ermitteln, welche Bäume zwischen den beiden Zeitpunkten verloren gegangen sind (Osmium hat auch einen Befehl, um Diffs zu erzeugen, aber da sind dann nur die neueren Objektversionen, nicht die alten, enthalten).

[westnordost]

Alright, ich habe die angesprochenen Vorschlage umgesetzt:

1. Wenn die Ratio die sich aus Kronendurchmesser / Stammdurchmesser ergibt sehr implausibel sind, werden sie nicht übernommen. (Kleiner als 2, größer als 100. Median ist 23. Betroffen sind etwa 525 Bäume im Datensatz. Oder sollte ich eher nach absoluten Kronendurchmesser/Stammdurchmesser-Werten gehen?)
2. Werte die mit “0” angegeben sind, werden nicht übernommen (z.B. Pflanzjahr)
3. Wenn mehrere Bäume unter 8 Metern von einem Katasterbaum entfernt sind, wird er nie automatisch mit einem OSM-Baum zusammengeführt (auch wenn der OSM-Baum quasi an der gleichen Stelle steht wie der Katasterbaum)
4. Katasterbäume deren Eigenschaften mit OSM-Bäumen in Konflikt stehen (z.B. andere Baumart) werden nicht automatisch zusammengeführt
5. taxon:cultivar und taxon:cultivar:de (=Sorte) aus Daten extrahieren und entsprechend taggen (nur wenn nicht identisch mit Art)
6. Art wird nicht getaggt wenn identisch zu Gattung oder explizit angegeben ist, dass die Art unbekannt ist (“… spec.” bzw. “… Art unbekannt”)
7. denotation=avenue wird hinzugefügt

Außerdem ist mir aufgefallen, dass die baumids zwischen den HPA-Bäumen und BUKEA-Bäumen trotz gegenteiliger Aussage der Behörde doch überlappen… das ist jetzt auch noch berücksicht.

Wiki ist entsprechend aktualisiert.

Allerdings:

@SK53

there are some forms, where the form (f. formname) will need to be trimmed off to get the species name (Gleditsia triancanthos f. inermis). Leave the whole thing in taxon (which is very flexible). Forms are similar to cultivars but do not have confirmed parentage. In this case planted Gleditsia tend to be ones without thorns (inermis) and this characteristic may arise independently many times. See below on Corkscrew Willow.

Nicht sicher was du meinst. Ich kann “Gleditsia triancanthos f. inermis” in den Quelldaten nicht finden.

[westnordost]

Nevermind, habe es gefunden. Ich weiß auch nicht warum ich es nicht vorher gesehen habe, die Namen stehen in den Quelldaten.

[ScubbX (Markus Mayr)]

Habe gerade von der Diskussion gehört und wollte nur kurz auf ein vergangenes Projekt berichten, in welchem ich den Baumkataster der Stadt Wien importiert hatte:

• Part1: Preparing the OpenGovernment TreeCadastre of Vienna for OSM-import (1) | GISForge
• Part2: Preparing the OpenGovernment TreeCadastre of Vienna for OSM-import (2) | GISForge
• Part3: OSM-import of the OpenGovernment TreeCadastre of Vienna | GISForge

[westnordost]

Oh, übrigens, der Import ist durch. (Schon vor ein paar Wochen.)
Wenn das Amt dann irgendwann eine neue Version des Katasters veröffentlicht (alle 1-2 Jahre), kann das Diff davon importiert werden.

[flo2154]

Ich bin gerade durch diese MapRoulette-Challenge (siehe auch Notable trees of OSM) auf ein paar wenige Bäume in Hamburg gestoßen, die mit einem implausiblen start_date importiert wurden:

• Node: 11381566340 | OpenStreetMap hatte 175, das ließ sich anhand der umgebenden Bäume leicht manuell auf 1975 ändern → Changeset: 151330715 | OpenStreetMap
• Node: 11381774723 | OpenStreetMap hat 199, das ist leider nicht so leicht erratbar, daher habe ich Note: 4246441 | OpenStreetMap aufgemacht
• Node: 11381542110 | OpenStreetMap hat 20 → Note: 4246464 | OpenStreetMap
• Node: 6344604447 | OpenStreetMap hat 200 → Note: 4246468 | OpenStreetMap

Falls der Import nochmal wiederholt wird, sollte der Pflanzjahr-Check vielleicht ausgeweitet werden, damit nicht nur 0, sondern auch nicht-vierstellige Jahreszahlen ignoriert werden.

Und vielleicht kennt jemand die Verantwortlichen für die Originaldaten, da könnte man diese paar Ausreißer melden.

[westnordost]

Ich habe die Fehler mal an die BUKEA weitergegeben. Ich denke, Notizen zu machen bringt nichts. Für OSM Mapper ist es nicht möglich, durch Begehung diesen Fehler zu korrigieren. Daher würde ich empfehlen, offensichtlich falsche Daten einfach zu löschen.