Tree_row: Soll das so?

Das ist grundsätzlich unmöglich.

1 Like

Sowas habe ich auch schon gesehen, würde davon aber abraten.
Das ist normalerweise kein ernsthaftes Problem, aber wenn man Bäume genauer erfasst (z.B. die Art), erfasst man doppelt und es wird pot. doppelt ausgewertet.
Würde jedem raten sich jeweils (nach vor Ort) für eine Methode zu entscheiden.

Man sollte sich aber entscheiden, ob man Einzelbäume oder Baumreihen einträgt. Also bitte nicht doppelt eintragen! Das Beispiel von @uvi zeigt auf der F4map, dass Laubbäume über Nadelbäume gestülpt sind F4map Demo - Interactive 3D map. Eigentlich hatte ich die Bäume mit halben Abstand oder unregelmäßig erwartet. Wichtiger ist die Angabe Laubbäume oder Nadelbäume. Auf der F4map finden sich immer wieder Tannen an lustigen Stellen oder Laubbaumreihen die dort buntgemischt erscheinen.

1 Like

Jo, wir mappen zwar nicht (nur) für F4, aber auch die Höhe einzutragen ist nicht verkehrt.
Weil ein Frischling von 3m und ein Ömmes von 30m, das ist schon ein Unterschied. :wink:

Ich sehe die f4map als gute Kontrolle. Wenn da eine Hecke oder ein Gebüsch steht, ist das anders, als eine Baumreihe. Ja die Größe eines Baumes kann drastisch wirken, da ohne Angabe nur eine Durchschnittsanzeige aufgeführt wird.

Die Möglichkeit, zusätzlich zum Way die Einzelbäume zu mappen, habe ich damals im akzeptierten Proposal zur Einführung von tree_row explizit vorgesehen.

Das ist also durchaus korrekt so und bietet zumindest theoretisch einen Mehrwert gegenüber nur Nodes (dann weiß man nicht, dass die Bäume Teil einer Baumreihe sind) oder nur einem Way (dann kennt man die genauen Standorte der Bäume nicht).

1 Like

Gucke mal bei
Du bist OSM-Mapper, wenn …

Finde, dass natural=tree_row eine OSM-Erfolgsgeschichte war und ist, und heute als eigenständiger Vegetationstag begriffen und verwendet wird. Und (nur) daher sehe ich derartige Doppelerfassungen eher als fragwürdige Altlast.

1 Like

Ich halte es nicht für eine Doppelerfassung, sowohl das Gesamtobjekt als auch seine Einzelteile in der Datenbank zu haben.

Es ist ja z.B. auch gute Mapping-Praxis, dass man einige oder alle der Stellplätze (amenity=parking_space), die Bestandteil eines Parkplatzes sind, erfassen kann, ohne dass man deshalb auf das Gesamtobjekt für den Parkplatz (amenity=parking) verzichtet.

3 Likes