DE talk:Tag:natural=tree

From OpenStreetMap Wiki
Jump to navigation Jump to search
Talk:Tag:natural=tree - Other languages

Messung der "Dicke" des Stammes

Üblicherweise wird in der Forstwirtschaft und der Baumpflege die Dicke des Stammes in 1.3m Höhe über dem Erdboden als Durchmesser und gelegentlich als Umfang angegeben. Auch in Baumschutzsatzung wird gewöhnlich der Durchmesser in 1.3m als ein Kriterium für die Schutzwürdigkeit herangezogen (z.B. Hamburger Baumschutzverordnung). Gemessen wird der Umfang mit einem Maßband und der Durchmesser mit einer Kluppe oder einem Umfangmaßband. International wird der Stammumfang meist als "girth" und der Durchmesser als "diameter at breast height" (dbh) bezeichnet. Eine Anpassung der Nomenklatur und der Messvorschrift (1.0m -> 1.3m) wäre für die Verständlichkeit der Attributes hilfreich. --NotBob 17:16, 13 October 2012 (BST)


species

der Ausdruck species=* ist falsch und sollte in genus=* umbenannt werden. Es gibt zB. 110-200 Arten (species) unter der Gattung (genus) Ahorn. [1] --Skyper 23:17, 11 May 2010 (UTC)

Tagwatch

Hier auf Tagwatch zu verweisen, finde ich unangebracht. Die Statistiken können nicht erkennen, ob ein Tag manuell gesetzt wurde. So wurden z.B. im Rahmen der Diskussion auf der Mailing-Liste (entgegen der Meinung der Mehrheit der Diskutierenden) massenhaft denotation=cluster-Tags automatisch angebracht. Dieses Tag war vorher noch überhaupt nicht dokumentiert gewesen, so dass wohl praktisch alle 22475 Verwendungen des Tags auf den Alleingang eines einzigen Benutzers zurückgehen, der damit seine Interpretation von natural=tree mit Gewalt durchsetzen wollte. --Tordanik 15:21, 25 September 2010 (BST)

Vollkommen richtig. --Scai 21:01, 26 September 2010 (BST)
Falsch. Es war vorher bereits im (deutschen) Wiki dokumentiert und ca. 2600 mal von anderen Usern verwendet. Beides läßt sich anhand der History leicht überprüfen, also bitte vermeidet solche falschen Behauptungen aus dem Gefühl heraus. --Nop 22:06, 26 September 2010 (BST)
Falls meine Annahme diesbezüglich falsch ist, bitte ich natürlich um Entschuldigung. Kannst du dennoch mal auf die bereits vor deiner Aktion existierende Doku verlinken? Ich kannte das Tag vorher nämlich nicht, und hier auf DE:Tag:natural=tree stand es in der Version unmittelbar vor deinem Edit (siehe hier) jedenfalls noch nicht drin.
Ich möchte aber darauf hinweisen, dass der Kern meiner Aussage - Tagwatch ist hier mit Vorsicht zu genießen - auch dann noch stimmt, wenn "nur" 90% der Tags von deinem Bot stammen. --Tordanik 23:39, 26 September 2010 (BST)

denotation

Wie ich auf der englischen talk-Seite bereits angemerkt habe, ist die Auswahl bei denotation zu spärlich. Wie soll man einzelne Bäume taggen, die zB auf einer Wiese stehen, aber nicht wegen ihrer Größe hervorstechen (also keine Landmarken sind) und auch sonst in keine der anderen Kategorien passen? Oder Bäume mitten in einem Wald, die dennoch eine gewisse Bedeutung besitzen, zB weil sie Teil eines Lehrpfades sind, eine besondere Form haben, uralt sind etc.? Bitte Liste ergänzen und auch auf die englische Seite übertragen, dort gibt es den denotation-Tag immer noch nicht. Man kann doch nicht an alle Bäume der Welt ein fixme anhängen und dann nicht erklären, was es damit auf sich hat. --Scai 09:18, 27 September 2010 (BST)

Anzahl?

Sollte man wenn zB: nur 2-3 Bäume ganz nah nebeneinander sind als 1 Node mit angabe der Anzahl taggen? --Curmet 09:07, 2 October 2010 (BST)

meine Bäume werden gar nicht angezeigt...?

Hallo zusammen,

ich hab versucht herauszufinden, warum die Einzelbäume, die ich gemapt habe (aus welchem Grund auch immer, bin auch auf diese Diskussion gestoßen), GAR NICHT in der Karte, welches Layer auch immer, auftauchen. Genutzt habe ich ganz normal "natural=tree". Gibts da geographische Besonderheiten, dass Bäume nicht überall auf der Welt angezeigt werden ?

Danke Euch! --TKN (talk) 08:25, 28 August 2013 (UTC)

Hast du ein Beispiel für so eine Stelle? --Tordanik 03:52, 30 August 2013 (UTC)

http://www.openstreetmap.org/#map=19/13.62113/25.32401 Ich vermisse 31 bäume und einen Springbrunnen... --TKN (talk) 11:06, 30 August 2013 (UTC)

Ah, ganz einfach: du hast bei natural=tree jeweils Natural geschrieben, also mit großem N. Wenn du das korrigierst, sollte es mit den Bäumen klappen. Der Springbrunnen hingegen sieht richtig eingetragen aus, aber ich glaube die Standarddarstellung zeigt Springbrunnen gar nicht an. Zumindest kann ich mich nicht erinnern, dort schon mal einen gesehen zu haben. --Tordanik 12:27, 30 August 2013 (UTC)

Ja super, das war´s, Danke. Weißt Du auch, warum die Bäume allerdings in der höchste Zoomstufe nicht MEHR angeziegt werden? Das macht doch eig. keinen Sinn? --TKN (talk) 20:30, 30 August 2013 (UTC)

Also, ich sehe sie auch dort (hübsch gemappt übrigens). Ist vermutlich ein veraltetes Bild, das noch in deinem Browser gecached wird - das kommt häufiger vor: https://help.openstreetmap.org/questions/8794/footpaths-not-showing-in-certain-zoom-levels --Tordanik 21:23, 30 August 2013 (UTC)

Danke. Stimmt, weltweit keine Brunnen in punkthafter Form zu finden. Muss mal schauen, ob der hier für eine flächenhafte Darstellung groß genug ist...--TKN (talk) 22:20, 30 August 2013 (UTC)

Die Benutzung von key:type ausserhalb von Relationen sollte vermieden werden

Bitte ziehe in Betracht zukünftig die bestätigten Taggs leaf_type=broadleaved/needleleaved zur Definition von Baumtypen zu verwenden. Bitte überlege auch, die bestehenden Taggs von Elementen, die du selbst erzeugt hast, zu ändern. --Rudolf (talk) 10:13, 23 June 2014 (UTC)

Vorschlag das Kapitel "Baumreihen" nach De:Tag:natural=tree_row zu verschieben

Ich schlage vor das Kapitel "Baumreihen" nach De:Tag:natural=tree_row zu verschieben und hier einen Link einzufügen. Es ist sinnvol die Sachverhalte dort zu beschreiben, wo man sie zuerst vermutet. --Rudolf (talk) 08:19, 25 June 2014 (UTC)

An sich hast du Recht, das gehört wenn dann zu natural=tree_row. Allerdings sollte man den Absatz vorher noch mal gründlich auf Konsenstauglichkeit abklopfen: Er ist zwar ziemlich alt, aber existiert in der englischen Version nicht und ist, soweit ich das sehe, ohne Proposal entstanden. --Tordanik 10:34, 26 June 2014 (UTC)
Scheinbar ist "tree_lined" obsolet. Genauso "alley" von der englischen Seite. Damit ist m.E. der meiste Inhalt überholt oder redundant. Ich würde evtl. bei De:Tag:natural=tree_row einen Hinweis auf veraltete Tags aufnehmen und den Abschnitt hier löschen. --Rudolf (talk) 12:31, 26 June 2014 (UTC)

Tag für Kronendurchmesser

Warum gibt es zwar Tags für Stammumfang und Baumhöhe, aber Keinen für den Kronendurchmesser?. Ich kenne das als Wertetripel. Und gerade bei Grundrissdarstellungen bzw. Kartendarstellungen ist davon der Kronendurchmesser doch der interessanteste Wert??? Jo Cassel (talk) 11:46, 16 June 2015 (UTC)

Ich stimme zu, dass ein Schlüssel für den Kronendurchmesser standardisiert werden sollte. Ein möglicher Kandidat wäre diameter_crown=*. --Tordanik 12:06, 16 June 2015 (UTC)
Ja, auf "diameter_crown" war ich bei meiner OSM-Recherche auch schon gestoßen. Hier übrigens ein Beispiel, wie der Wert bei einer Kartendarstellung genutzt werden kann/könnte https://geoportal.frankfurt.de/karten/baumkataster.html ("Der Kronendurchmesser wird maßstabsgetreu in der Karte abgebildet.") Jo Cassel (talk) 15:53, 17 June 2015 (UTC)

Standortangabe bei Stadt-Bäumen

Wie taggt man eine Standortangabe bei Bäumen? In städtischen Baumkatastern ist es (zumindest in de) üblich den Straßennamen anzugeben, gegebenenfalls noch mit weiteren Standortinformationen ("Schulhof Beispielschule"). Ich hatte das in OSM auch gemacht, unter Verwendung der addr:city und addr:street-Tags. Ein User teilte mir mit, dass er damit Bauchschmerzen hat und Probleme sieht, weil diese Tags "für Grundstücke und Gebäude" gedacht seien. Ein anderer User hielt sich erst gar nicht mit Mitteilungen auf, sondern löschhte mir bei 108 Bäumen diese Standortangaben. Auf Nachfrage erfuhr ich, "weil Bäume keinen Briefkasten haben". Alternativen konnte mir bisher keiner Nennen. Gibt es Erfahrungen und Lösungen? Jo Cassel (talk) 11:56, 16 June 2015 (UTC)

Mal eine Gegenfrage: Braucht es überhaupt eine Standortbeschreibung, wenn der Standort durch die Koordinaten des Knotens eindeutig bestimmt ist? Auch die nächstgelegene Straße und die Stadt ließe sich ja automatisch berechnen, müsste also nicht von Hand eingetragen werden. --Tordanik 12:04, 16 June 2015 (UTC)
Mir ist schon klar, dass jedem Node in OSM eindeutige Koordinaten zugeordnet sind, und ich bin auch nicht der Meinung, dass nun jeder Baum unbedingt eine zusätzliche Standortangabe benötigt. Wenn man das Mapping und Tagging von Bäumen aber ernsthafter angeht und ein Baumkataster erstellt, beispielsweise das aller Naturdenkmäler einer Kommune, dann gehört da eine "menschenlesbare" Standortangabe IMHO dazu, sonst bleibt eine Text-Ausgabe (beispielsweise ohne Karte, in Listenform) eher unbrauchbar.
Mein spezielles Problem s. https://wiki.openstreetmap.org/wiki/User:Jo_Cassel
ist außerdem, dass die numerische Kennung der "7000 Eichen" nicht eineindeutig ist, dies bedeutet hier benötige ich zwingend eine Straßenangabe für eine eineindeutige Zuordnung.
Dabei benötige ich allerdings NICHT zwingend die addr:-Tags. Ich kann das (für mich) auch anders lösen. Aber was ist denn projektintern gewünscht? Warum definiert man ein addr:-Schema, das dann nur für Postanschriften verwendet werden soll/darf[?] und macht sich nicht gleichzeitig Gedanken um Standortangaben allgemein? Hier ein paar Beispiele, die mich ratlos machen:
Standort im "ref"-Tag bei Briefkästen: http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dpost_box
Eigener, spezieller "ObjektX-Standort"-Tag: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a s. dort "AED", oder bei http://wiki.openstreetmap.org/wiki/Stolpersteine
und hier noch Standort im "name"-Tag bei technischen Bauten: http://wiki.openstreetmap.org/wiki/Hambergen/Stromversorgung
Was ich auch schon gesehen habe - und mir noch vergleichsweise sinnhaft vorkommt - ist die Standortangabe im "description"-Tag.
Momentan spiele ich mit dem Gedanken, Den Standort bei den "7000 Eichen" in den ref-Tag und den der "Naturdenkmäler in der Stadt Kassel" in den "description"-Tag zu integrieren. Was ich mir aber wünsche ist so etwas wie Rechts- und Planungssicherheit. Zur Zeit müßte ich ca. 450 Bäume ändern, jede Woche sollen es aber mehr werden und ich möchte vermeiden, dass in einigen Monaten jemand vorbeikommt und mir erzählt "so geht das aber mal gar nicht!".
Was ich auch vermeiden möchte ist dass irgendwann in der Zukunft von einem anderen User die Straßenangaben (von welchem Tag auch immer) in den "addr:street"-Tag überführt werden, um dann wiederum später von einem dritten "Experten" ersatzlos gelöscht zu werden.
Was tun? Jo Cassel (talk) 16:05, 17 June 2015 (UTC)
Das "addrː̈"-Schema ist für Adressen da und nicht zur allgemeinen Positionsbestimmung. Zur allgemeinen Positionsbestimmung verwenden wir lat/lon. Wenn jemand wissen will, in welcher Kommune ein bestimmtes lat/lon-Paar liegt, gibt es dafür das Reverse Geocoding. Das müsste jemand anwenden, der eine Liste von Bäumen mit menschenlesbarer Position erstellen will. Der Standort eines Baums gehört weder in addrː-, noch in ref-, noch in description-Tags und nicht mal in das historische "is_in", und wenn Du irgendeine Sicherheit willst, dann kann das allenfalls die sein, dass eine Standortangabe dieser Art garantiert irgendwann rausfliegt. --Frederik Ramm (talk) 12:53, 9 February 2016 (UTC)
"Reverse Geocoding" hört sich ja mega supercool an.
Wie funktioniert das denn ganz praktisch, wenn ich zum Beispiel hier den String "Stegerwaldstraße, Offene Schule Waldau" ermitteln möchte? Jo Cassel (talk) 13:33, 9 February 2016 (UTC)
Ein Reverse Geocoder würde zwar eher etwas wie "Stegerwaldstraße 45" (oder 47) ausgeben - aber menschen-lesbar ist das dann genauso.
Ich bin zwar in diesem konkreten Fall nicht so absolut gegen einen Angabe in "description" - aber richtig verlässlich ist dieses Tag für Dich eben nicht.

Nachdem hier nach Monaten keine praktikablen und sinnvollen Vorschläge kamen, obwohl ich mein Problem mehrfach im Diskussions-Forum mit Línk nach hier angesprochen hatte, und nachdem mir vor einigen Tagen ein Bot mit suboptimaler KI über 250 Bäume verschlimmbessert hatte, hab ich nun als Konsequenz mein eigenes Schema für das Taging von Baumstandorten entwickelt und verwende dies.
Es ist schlicht und einfach das etablierte addr:-Schema (https://wiki.openstreetmap.org/wiki/Key:addr), jedoch habe ich den String addr durch den String tree_location ersetzt. Jo Cassel (talk) 14:26, 27 March 2016 (UTC)

Zur Dokumentation hier auch noch ein zweiter Vorschlag: Ähnlich zum addr:-Schema gibt es ein nicht dokumentiertes, aber knapp 20.000 mal genutztes object:-Schema (allerdings überwiegend in Düsseldorf, wahrscheinlich ein Import oder sowas). Mit "object:street" lässt sich also die Straße angeben, der ein Objekt zugeordnet wird; mit "object:housenumber" die Hausnummer usw. (object:city, :country, :postcode, :suburb). Für beschreibende Standortangaben bietet sich "object:location" an.
Zumindest bei Straßenbäumen, die in städtischen Baumkatastern aufgeführt sind, ist es durchaus ein Mehrwert, wenn wenigstens die Straße getaggt wird, der dieser Baum zugeordnet wird. Das lässt sich nicht immer automatisiert ermitteln (siehe z.B. in diesem Beispiel).
--Supaplex030 (talk) 15:18, 7 October 2016 (UTC)

"Ergänzende Attribute" um `ref` erweitern?

Was haltet ihr davon, die Liste "Ergänzende Attribute" um `ref` zu erweitern?

Schlüssel=Wert Symbol Beschreibung Bild Kartensymbol Hinweise / Links
ref=31 Referenznummer am Baum Eine Referenz aus dem lokalen Baumkatasters, die am Baum zu sehen ist.

Quelle:

--Tordans (talk) 16:23, 25 March 2018 (UTC)

Ich wäre auch dafür, "ref" aufzunehmen. Bei dieser Gelegenheit könnten wir diskutieren, ob "ref" oder "tree:ref" besser geeinget ist, die Nummer aufzunehmen, unter der ein Baum in Baumkatastern geführt ist und die meist mit einem kleinen Schildchen am Baum angebracht ist. Ich habe in Anlehnung an einen Baumimport aus Wien immer "tree:ref" genutzt, sehe aber eigentlich keine Vorteile mehr. Andere Objekte wie Straßenlaternen oder Wasserpumpen tagge ich ja auch mit "ref"... Spezielle (technische/interne) Referenznummern, die ein Baum darüber hinaus auch noch haben kann, können ja bei Bedarf mit XY_ref/ref:XY eingetragen werden. Mit User:Jo_Cassel hatte ich ref vs. tree:ref schonmal kurz andiskutiert.
Btw: Interessant, dass auf der Wiki-Seite zu Key:ref gar nicht so richtig erwähnt ist, dass auch andere Objekte außer highway damit getaggt werden können - auch wenn sie neben den 7 Millionen Straßen nur eine Minderheit ausmachen :)
Alles in allem bräuchte die (deutsche) Wikiseite aber ohnehin mal eine Überarbeitung, oder? Auch andere oft verwendete Tags fehlen, v.a. Key:leaf_cycle oder auch Key:diameter_crown. Das Thema Standortangaben (siehe Diskussion hier oben drüber) könnte man auch nochmal aufmachen. Zahlreiche weitere spezielle Tags wurden schon diskutiert - darauf könnte zumindest irgendwo verwiesen werden. Etwas mehr Struktur und Übersichtlichkeit wäre auch nicht schlecht. Ich versuche bei Gelegenheit mal, einen Vorschlag zu machen.
--Supaplex030 (talk) 18:33, 25 March 2018 (UTC)
Was wir auch an `ref` gefällt, ist, dass der iD-Editor die Zahl direkt neben dem Baum anzeigt. Das macht es sehr leicht zu kontrollieren, was noch fehlt. Außerdem +1 für die übrigen Tags. --Tordans (talk) 18:55, 25 March 2018 (UTC)

Micromapping?

Warum ist Bäume mappen Micromapping? —Dieterdreist (talk) 15:20, 7 October 2020 (UTC)

Nö Zen http://overpass-turbo.eu/s/IYP ;-) Jo Cassel (talk) 17:19, 7 October 2020 (UTC)
Saubere Arbeit, Respekt. In diesem Beispiel würde ich den Micromappingbegriff nicht völlig wegwischen wollen, aber eben weil da noch sehr ausführliche Details dabei sind, wenn man dagegen "nur" einen Baum mappt, ist das noch nicht automatisch "Mikromapping", jedenfalls nicht mehr als einzelne Gebäude zu mappen. --Dieterdreist (talk) 21:39, 7 October 2020 (UTC)
Konnte mit dem Audruck "Micromapping" noch nie viel anfangen und verwende ihn gar nicht. Meiner Erfahrung nach nutzen ihn einige negativ konnotiert im Sinne von "es gibt wichtigeres (das was ich mache)" - da stehe ich drüber und mache viel mit Bäumen. Ist möglicherweise auch eine Frage, inwieweit die Kollegen kleinmaßstäbliches Arbeiten (so deutlich kleiner < 1:25 000) gewohnt sind, bzw. dies mit einem "Kartenprojekt" überhaupt in Verbindung bringen. Die obigen Bäume tauchen in einer von mir gerenderten Karte in 1:2000 auf. Auch 1:1000 ist noch gut machbar, aber < 1:500 würde ich in OSM nicht unbedingt umsetzen wollen. ... Jo Cassel (talk) 14:00, 8 October 2020 (UTC)

diameter_crown mit Erfassungsdatum als note=*

Am Ende der Tabelle über die Baumeigenschaften steht:
diameter_crown=8 / Durchmesser der Krone in Metern. Wenn möglich, Erfassungsdatum mit note=* ergänzen.
Ich halte es für nicht korrekt hier note=* zu missbrauchen. Wir haben dafür [[2]] als prefix.
i.e.: check_date:diameter_crown=2022-12-31 HirschKauz (talk) 06:01, 23 January 2023 (UTC)

Kronendurchmesser erfasse ich nicht, häufig aber den Stammumfang.
Die Details lege ich im zugeordneten source-Tag ab, das Tagging bei unserem ND-Beispielbaum: https://www.openstreetmap.org/node/3927344961
circumference=4.75
source:circumference=Messung 2020-11-13 in h=1,30 m
kann ich so empfehlen - im note-Tag hat sowas jedenfalls nichts verloren ... Gruß ... Jo Cassel (talk) 15:49, 23 January 2023 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE_talk:Tag:natural%3Dtree&oldid=2469100"