Ich seh die Straße vor lauter Bäumen nicht

So etwas hat mich auch schon gefuchst.
Weg bekommst Du das nur, wenn Du das Typfile änderst (ändern kannst).

Das Schema zur Erfassung von Bäumen http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree
sieht noch nicht sehr überzeugend aus. Die Erfassung von besonderen und/oder alleinstehenden Bäumen mit natural=tree macht Sinn. Doch eine ganze Baumreihe mit einzelnen Nodes darstellen?
Baumreihen als schmales Polygon oder Linie zu erfassen, hat sich anscheinend noch nicht überall herum gesprochen. Wenn das keinen Konsenz findet, sollte man zumindest das Taggingschema so ergänzen, daß man bei der Auswertung der OSM-Daten zwischen Baumreihen an Bächen oder Feldrainen, Alleebäumen, Solitairbäumen oder besondern Bäumen (Naturdenkmal) unterscheiden kann:

natural=tree
tree=treeline/parkway/group/single/natural_monument

Dann hätte man beim Rendern die Möglichkeit,
- je nach Typ ein größeres oder kleineres Symbol zu setzen,
- Alleebäume mit einer ID zu verknüpfen, die nicht in Suchkategorien auftaucht
- Naturdenkmäler besonders hervorzuheben und in die Suchkategorie Landmerkmal zu verknüpfen

Vielleicht kann man das Thema ja mal neu aufgreifen.

Gruß
tippeltappel

Ich finde das Problem liegt eher an Mapnik. In den Zoomstufen 17 und 18 sind die Straßen gleich breit, das führt dazu dass Objekte die eigentlich nah an der Straße sind so dargestellt sind dass sie sich bei Zoomstufe 17 auf der Straße befinden.
Zoomstufe 16 ist nur etwas kleiner als 17.

Hier ist eine Straße in Bamberg bei Zoom 18:
http://b.tile.openstreetmap.org/18/139009/89029.png
Bei 17 sind die Bäume schon teilweise auf der Straße:
http://c.tile.openstreetmap.org/17/69504/44514.png
Bei 16 verläuft die Straße geradewegs durch die Bäume:
http://c.tile.openstreetmap.org/16/34752/22257.png

Suidakras Problem hat mit mapnik nicht das Geringste zu tun.
Gruß
tippeltappel

tippeltappel wrote:

Suidakras Problem hat mit mapnik nicht das Geringste zu tun.
Gruß
tippeltappel

Richtig.

Was für einen Garmin-Karte verwendest du denn?

- Hilft eigentlich nur Typfile ändern
- oder mit dem Ersteller der Karte reden, ob er die Bäume ganz weglässt

Gruß

godofglow wrote:

- oder mit dem Ersteller der Karte reden, ob er die Bäume ganz weglässt

Als ich das erste mal auf so ein Problem gestossen bin, habe ich mich auch ziemlich ueber den "Spinner" geaergert, der das eingetragen hat.
Danach kam dann aber schnell die Erkenntnis, dass mein bei OSM prinzipbedingt keine Vorgaben machen kann, bis zu welchem Level Details zu erfassen sind. Insofern wird es immer (mehr) solche Auswuechse geben, wo die Leute sich jenseits jeglicher Vernunft (weil auch jenseits jeglicher Genauigkeit) in Details verlieren.

Fuer dieses spezielle Problem sieht meine persoenliche Loesung so aus, dass ich in meinen selbstgebauten Karten nur noch Einzelbaeume darstelle, die einen Namen haben. Die anderen gehen leider im Rauschen des Datenmuells unter.

Gruss
Torsten

de_muur wrote:

....
Danach kam dann aber schnell die Erkenntnis, dass mein bei OSM prinzipbedingt keine Vorgaben machen kann, bis zu welchem Level Details zu erfassen sind. Insofern wird es immer (mehr) solche Auswuechse geben, wo die Leute sich jenseits jeglicher Vernunft (weil auch jenseits jeglicher Genauigkeit) in Details verlieren.
....

In diesem Zusammenhang kann man sicherlich lange über "Vernunft" diskutieren. Ich finde, es ist gerade ein
großes PLUS von OSM, dass jeder erfassen kann, was ihn interessiert.
Was natürlich bleibt, sind entsprechende Filter für die Anwendungen.

@fx99
Und der Filter benötigt Tags zum filtern.
Darauf zielt oben ausgeführter Vorschlag ab.

Wenn einem eine Ansammlung von Einzelbäumen in die Quere kommt, könnte man die durch Ergänzung mit vorgeschlagenem Tag "entschärfen", und den Renderer der Lieblingskarte auf das ergänzte Taggingschema aufmerksam machen.

Mit Potlach wäre das natürlich ein mühseliges Unterfangen. Aber kann man nicht mit JOSM Kartenelemente gezielt herausfiltern? Wer kennt sich da aus?

Gruß
tippeltappel

fx99 wrote:

In diesem Zusammenhang kann man sicherlich lange über "Vernunft" diskutieren. Ich finde, es ist gerade ein
großes PLUS von OSM, dass jeder erfassen kann, was ihn interessiert.
Was natürlich bleibt, sind entsprechende Filter für die Anwendungen.

Das Problem ist nur, dass bei solchen Sachen haeufig die Unterscheidung anhand der Signifikanz vergessen wird.

natural=tree war eigentlich definiert worden fuer bedeutende Baeume. Wenn man nun jeden kleinen Strassenbaum mit dem selben Tag erfasst, kann man halt die bedeutenden Baeume von den unbedeutenden nicht mehr unterscheiden.

Es spricht ja nichts dagegen, dass jemand jeden Grashalm in die OSM-Datenbank eintragen will. Es sollte dann alelrdings dafuer gesorgt werden, dass dann aber auch solche tags verwendet werden, die den Anwendungen ein sinnvolles Filtern erlauben.

Im konkreten Fall waere es z.B. nicht schlecht, wenn man statt einem einfachen natural=tree ein natural=minor_tree oder ein ergaenzendes tree=minor, importance=minor oder was auch immer zur Unterscheidung gesetzt haette.

Gruss
Torsten

godofglow wrote:

tippeltappel wrote:

Suidakras Problem hat mit mapnik nicht das Geringste zu tun.
Gruß
tippeltappel

Richtig.

Was für einen Garmin-Karte verwendest du denn?

- Hilft eigentlich nur Typfile ändern
- oder mit dem Ersteller der Karte reden, ob er die Bäume ganz weglässt

Gruß

zur Zeit habe ich die Karte von Kleineisel. Normalerweise habe ich mit einzelnen Bäumen.Grashalmen,Steinen usw. keine Probleme aber es gibt noch sooooooooooooooooo viele Wald und Wiesenwege die noch nicht erfasst sind. Wenn da mal "alles" aufgezeichnet wurde kann man ja immernoch die einzelnen Bäume nach der Familiengeschichte befragen ; ). mal ganz abgesehen davon das so ein Schmarrn dann doch Speicherplatz vergeutet.
Aber die Idee den Den Kartenersteller mal anzuschreiben is gut.

Jeder User Taggt anders. Wenn ich zu 100% zu Fuß unterwegs bin, liegt mein Tagging-Radis nur ein paar Kilometer um mein Haus. Da ist man schnell an dem Punkt, wo man Bäume Taggt. Autobahnen kann man so aber gar nicht Taggen.

Wer zu 100% mit dem Auto Taggt, wir kaum nen Baum Taggen, dafür aber Autobahnen.

Aus aktuellem Anlaß hole ich das Thema noch einmal hoch.
Als ich heute eine frisch gerenderte Karte absurfte, mußte ich feststellen, daß seit neuestem ganze Eifeldörfer unter Baum-Icons versinken.
Nächste Überraschung, die Ortslagen sind nicht mehr zu erkennen, weil jeder Garten eingezeichnet wurde und sich deren Grün vom umliegen Weideland kaum unterscheidet.
Mit einem neuen, durchsichtigen landuse-Icon, das die Farbe der residental-Fläche durchscheinen läßt und nur einen Hauch grüner Sprenkel über die "Dorf"-Farbe legt, konnte der "Schaden" behoben werden. Wie aber sieht die Sache aus, wenn korrekt mit Multipolygonen gemappt wird?

Also diese Anhäufung von Details stellen einen als Kartenbastler vor ganz neue Herausforderungen. Da hat man ja bald keine Zeit mehr zum Mappen! 😉

Für die Bäume muß ich mir noch etwas einfallen lassen. Hatte eigentlich nicht vor, alle heraus zu werfen und ein kleines Icon für unbedeutende Bäume erstellt, doch wenn die Karte über kurz oder lang mit zahllosen Bäumen vollgepflanzt ist, bringt das eine Überladung der Tiles mit sich. Deshalb würde ich schon gerne gezielt filtern können.

Hier wurden die Bäume alle nur mit natural=tree getagt. Das einzige Filter-Kriterium ist der fehlende Name.
Die Karten-Situation ist sehr unterschiedlich. Mal viel mal wenig Bäume. Mal an der Straße, mal im Garten, mal auf einer Wiese.
http://www.openstreetmap.org/?lat=50.48 … rs=B000FTF
http://www.openstreetmap.org/?lat=50.48 … rs=B000FTF

Die Arbeit, die da drin steckt, muß man wirklich anerkennen. Aber was bringt es, wenn man die Daten nicht differenziert filtern kann?

Hier eine Sammlung von Wiki-Seiten, die sich mit dem Thema Baum, Wald, Obstplantagen beschäftigen:

Bäume
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
unterscheidet sich deutlich von der deutschen Übersetzung:
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree
http://wiki.openstreetmap.org/wiki/DE:Key:natural

Wald
http://wiki.openstreetmap.org/wiki/DE:T … e%3Dforest
http://wiki.openstreetmap.org/wiki/User:Fabi2/treetype

farm
http://wiki.openstreetmap.org/wiki/DE:T … use%3Dfarm
Auch auf solchen Flächen stehen Bäume.

Obstanbau
http://wiki.openstreetmap.org/wiki/DE:T … %3Dorchard
http://forum.openstreetmap.org/viewtopic.php?pid=79713

Übersichtlich ist das alles irgendwie nicht gerade.
Eine Problemlösung konnte ich da nicht herauslesen.

Da Wander- oder Fahrradwege im Schatten einer Allee gerade im Sommer angenehmer sind, könnte ein Hinweis von Nutzen sein. Deshalb würde mir ein Standortvermerk als Filter gefallen.
tree_position=garden|meadow|park|road
usw.

Dann könnte man alle unbedeutenden Bäume aus Gärten, Wiesen etc. aus der Karte raus werfen und nur die Allee-Bäume drin lassen. Und wenn die nerven, dann wirft man die auch raus und läßt nur noch die Schatten spendende Solitairbäume an Rastplätzen stehen usw.

Ideen?

Viele Grüße
tippeltappel

tippeltappel wrote:

Nächste Überraschung, die Ortslagen sind nicht mehr zu erkennen, weil jeder Garten eingezeichnet wurde und sich deren Grün vom umliegen Weideland kaum unterscheidet.

Zumindest dies widerspricht klar dem Wiki: "Hausgärten werden nicht extra getaggt und gehören zum Wohngebiet landuse=residential."

Wie heisst es so passend: "Auch Übereifer kann schädlich sein."

Edit:

Wer ist wohl schneller, die eifrigen Mapper oder die eifrigen Administratoren, Systembetreiber, Programm- und Kartenentwickler, die versuchen der anschwellenden Datenmenge Herr zu werden? 😉

So kann ich zur Zeit Thailand noch einigermaßen akzeptabel komplett (150 MB) auf einem Netbook mit JOSM bearbeiten aber ich arbeite seit einem Jahr beinahe täglich daran dies zu ändern, habe jedoch noch keinen einzigen Baum oder Pferdekottütenspender erfasst.

Ist es nicht möglich die Bäume erst in einem niedrigen Zoombereich anzuzeigen? Tracks werden ja teilweise auch erst bei ca 200m angezeigt.

tippeltappel wrote:

...
Also diese Anhäufung von Details stellen einen als Kartenbastler vor ganz neue Herausforderungen. Da hat man ja bald keine Zeit mehr zum Mappen! 😉

Für die Bäume muß ich mir noch etwas einfallen lassen. Hatte eigentlich nicht vor, alle heraus zu werfen und ein kleines Icon für unbedeutende Bäume erstellt, doch wenn die Karte über kurz oder lang mit zahllosen Bäumen vollgepflanzt ist, bringt das eine Überladung der Tiles mit sich. Deshalb würde ich schon gerne gezielt filtern können.

Hier wurden die Bäume alle nur mit natural=tree getagt. Das einzige Filter-Kriterium ist der fehlende Name.
Die Karten-Situation ist sehr unterschiedlich. Mal viel mal wenig Bäume. Mal an der Straße, mal im Garten, mal auf einer Wiese.
http://www.openstreetmap.org/?lat=50.48 … rs=B000FTF
http://www.openstreetmap.org/?lat=50.48 … rs=B000FTF

Die Arbeit, die da drin steckt, muß man wirklich anerkennen. Aber was bringt es, wenn man die Daten nicht differenziert filtern kann?
...

Hallo tippeltappel

Ich vermute mal du redest von selbst gerenderten Karten für Garmin-Geräte.

Meine Vorschläge wären folgende:
- kleine Symbole wie bei Mapnik verwenden (grüner Punkt)
- Zoomlevel für Bäume beschränken (Mapnik = Z16-Z18)

Besondere Bäume (nach deinen Kriterien) kannst du ja mit einem
größeren Symbol oder auch in mehr Zoomlevel rendern.

Edit: In Mapnik erscheinen mir deine Beispiele keineswegs überladen.
Das liegt u.a. an den recht kleinen Symbolen für natural=tree.
Insgesamt sind in den Orten natürlich recht viele Details erfasst.

Edbert (EvanE)

@ Suidakra
Das bringt leider nicht die gewünschte Lösung.

Es gibt besondere Bäume, die auch auf herkömmlichen Wanderkarten als Landmerkmal eingetragen sind. Die dienen als Orientierungshilfe. Sie haben keinen Namen, sind aber von Bedeutung. Wenn man das Wiki aufmerksam liest, stellt man leicht fest, daß das Tag natural=tree für solche Landmarken gedacht war. Solche Bäume möchte ich in einer Zoomstufe sehen, in der die Karte noch eine gewisse Übersicht vermittelt. (Sofern man bei einem winzigen Display überhaupt von Übersicht reden kann.) Auf dem VHCx habe ich die Anzeige daher bislang auf bis zu 500m eingestellt. Wenn sich die unwichtigen Bäume nun nicht rausfiltern lassen, verliere ich diese Landmerkmale auf der Karte. Das Icon ist schon so klein, daß sich die unbenannten Landmarken auf dem VHCx nur noch finden lassen, wenn man weiß, wo man suchen muß. Das ist sehr ärgerlich. Die einzeln getagten Baumgruppen dagegen summieren sich zu einem Störfaktor. Das müßte nicht sein. Baumgruppen können ja auch mit einem Polygon eingetragen werden. Dasselbe ist auch mit Baumreihen möglich. Da nun aber offensichtlich immer mehr Mapper glauben, es sei gut, jeden Baum einzeln einzutragen (die kleinen grünen Glühwürmchen sehen in Mapnik ja ganz "lustig" aus ... ) bekommen wir langsam aber sicher ein nicht unerhebliches Problem. Ohne Filtertags ergibt diese "Baumgeschichte" salopp gesagt einen ziemlichen Murks. Dazu kommt, daß die völlig überflüssigen Nodes die Kartentiles überladen und ein kleines GPS-Gerät mit zusätzlichen Berechnungsvorgängen belasten. Doch es kommt noch besser. Jeder Node ist mit einer ID verknüpft. Will ich die Landmerkmale (egal ob Bäume oder etwas anderes) in der Suchliste anzeigen lassen, hab ich ohne ein Filtertag, das die unwichtigen Bäume aussondern kann, keine Chance. Entweder müllen mir die ganzen unwichtigen Bäume die Suchliste zu oder die Baum-Landmarken fliegen zusammen mit den überflüssigen Bäumen aus der Suchliste raus. Dann sind die Baum-Landmarken futsch 🙁 , aber ich finde wenigstens den Rest.

Die Bäume mit einer ID verknüpfen, die in keiner der Suchlisten auftaucht, ist auch nicht die Lösung. Dann sieht man die Baum-Landmarken zwar auf der Karte (vorausgesetzt, das winzige Icon wird erkannt), kann sie aber nicht in der Liste der Landmerkmale finden. Das Problem mit diesen nicht suchbaren IDs: Sie werden unter Umständen nicht von allen Garmin-Geräten gleichermaßen erkannt.
All zu viele der nicht suchbaren IDs gibt es nicht. Der überwiegende Teil der nutzbaren Ids taucht zumindest in der Suchergebnisliste von "alle POI" auf. An den IDs hängen nicht dokumentierte von Garmin programmierte Default-Einstellungen, die nur begrenzt beeinfllußt werden können. Da einzugreifen ist eine Wissenschaft für sich! Dazu kommt, daß die Default-Einstellungen in den verschiedenen MapSource-Varianten und den verschiedenen Firmware-Versionen der GPS-Geräte nicht (!!!) zu 100% übereinstimmen. Ein OSM-Kartenbastler, der der Gemeinschaft sein Werk zur Verfügung stellt, muß also nicht nur per try&error die optimale Karten-Einstellung für sein eigenes Gerät herausfinden, sondern auch noch schauen, wie es für die anderen Geräte und Softwareversionen paßt.

Aber bleiben wir bei den "normal" einprogrammierten Bäumen. Gerät man in die Nähe einer Baum-POI-Sammlung, findet man in der Suchergebnisliste erst mal nur die nächststehenden Bäume. Wenn es viele sind, war es das. Die Liste zeigt sämtliche Bäume der Umgebung an und ist damit "dicht". Die wirklich interessanten Dinge lassen sich nicht mehr finden. Was soll man damit noch anfangen?

Ein ähnliches Problem war mit den Strommasten zu lösen. Die liegen jetzt auf so einer ID ohne Suchfunktion. Parkbänke auch.
Dahin sollen auch die Alleebäume verbannt werden. Aber nicht die Baum-Landmarken. Doch wenn die sich nicht per Filter-Tag unterscheiden lassen? - - 🙁 🙁 🙁

Mit dem fleißigen Mapper des verlinkten Kartenausschnittes hatte ich übrigens einen sehr netten, konstruktiven Briefwechsel. Lokal werden wir das Baumproblem sicher lösen. Aber das Phänomen breitet sich ja offensichtlich aus. Deshalb bin ich der Meinung, es wäre nützlich, das Thema im Wiki sozusagen neu zu ordnen und auf die Probleme hinzuweisen, die entstehen, wenn Mapper übers Ziel hinaus schießen und Filtertags zum Aussondern des Überschusses fehlen.

Viele Grüße
tippeltappel

@ Edbert
Deine Vorschläge kleines Icon, niedrige Zoomstufe hab ich längst (soweit machbar) umgesetzt. Doch die Umsetzbarkeit dieser Idee steht und fällt mit dem Vorhandensein eines überzeugend präsentierten und von allen Bäumemappern eingesetzten Filtertags, das Landmarken und Naturdenkmäler von 0-8-15-Bäumen unterscheidet.

Viele Grüße
tippeltappel

Was hat denn der konstruktive Briefwechsel ergeben? Ein zweite Klasse Baum wie natural=tree und natural=minor_tree oder ähnliches?

Bis sich ein brauchbares Schema entwickelt hat, könnte man die Bäume auch wie folgt filtern:
1) Eine Liste der wichtigen Bäume anlegen (nach Kriterien wie Name vorhanden oder nicht)
2) Alle Bäume im näheren Umkreis der wichtigen Bäume in eine Liste unwichtiger Bäume verschieben.
3) Die übrigen Bäume als wichtig ansehen falls es keine weiteren Bäume im näheren Umkreis gibt, ansonsten als unwichtig ansehen
Nun können die 2 Listen anstatt eines Filtertags genutzt werden.

Wie und ob sich obiges mit den Werkzeugen zur Erstellung von Garmin-kompatiblen Karten umsetzen lässt, kann ich leider nicht beurteilen.

Die lokale Lösung ist noch nicht fertig. Als erstes schlug der Mapper selbst vor, größere Baumgruppen in Polygone umzuwandeln. Baumansammlungen in Gärten will er wohl lieber wieder heraus nehmen. Wobei ja das Mappen der Hausgärten laut OSM-Wiki so ja auch nicht ganz richtig ist. (Vielen Dank, Willi! Habe die Zitatquelle nach einigem Suchen gefunden.)

Zu Deinem Vorschlag, Augustus:
Wie stellst Du Dir das mit der Liste vor? Wer soll die anlegen?
Und wie soll man diese räumlichen Bezüge definieren?
Das ist nicht nur alles viel zu kompliziert sondern verlangt auch Tags, die zumindest die bedeutenden Bäume hervorheben. Doch genau die fehlen meiner Meinung nach bis jetzt.

Meine Renderregel sorgt dafür, daß Bäume mit Namen als Baum gemalt werden, die ohne werden nur als Punkt sichtbar. Das löst das Problem aber nicht zufriedenstellend. Siehe oben.
Historische Landmarken in Form großer, alter Bäume gehen in dieser "Baumflut" unter, wenn der Mapper sie nicht mit einem sinnvollen Tag kennzeichnet.

natural=minor_tree ist nicht konkret genug und lediglich ein Ausschlußkriterium.
Wir brauchen beschreibende Tags, an denen man die Bedeutung des Baumes festmachen kann und die es einem als Kartenbastler ermöglichen, diese über Renderregeln zu sortieren/gewichten. Das ist wie eine ganz normale Datenbankabfrage nach dem Motto:
- zeige alle Bäume mit name=vorhanden
- zeige/ignoriere alle Bäume mit denotation=(vorhanden)landmark|natural_monument|avenue|
- ignoriere alle Bäume mit name=nicht vorhanden und denotation=nicht vorhanden

Nach einigem Überlegen scheint mir eine Definition mit
denotation=landmark|natural_monument|avenue|
eine gute Idee zu sein, um das angesprochene Problem zu lösen.
Das ist konkret, nennt die wichtigsten Funktionen/Eigenschaften, deretwegen Bäume in Wanderkarten aufgenommen werden und läßt nur wenig Interpretationsspielraum zu. Der Renderer hat die Chance, Landmarken und Naturdenkmäler optisch hervor zu heben und je nach Anwendungsbereich der Karte Allebäume als kleine Punkte zu zeigen oder auch nicht. Den Rest kann man dann rauswerfen oder zeigen, wie's beliebt.

In Renderregeln werden Kriterien definiert, die relevante Objekte aus der Datenbank herausfiltern und den gewünschen Darstellungsformen zuordnen. Wenn die Mapper die Objekte aber ohne Unterscheidungsmerkmale in der Datenbank ablegen, kann man sie nicht differenziert abfragen. Das Ergebnis ist immer ein fauler Kompromiß.

An den mir bekannten Landmarken werde ich das Tag dann demnächts mal "dranpappen". Vielleicht merkt es ja jemand und das Vorbild macht Schule. 😉

Viele Grüße
tippeltappel

tippeltappel wrote:

Wobei ja das Mappen der Hausgärten laut OSM-Wiki so ja auch nicht ganz richtig ist. (Vielen Dank, Willi! Habe die Zitatquelle nach einigem Suchen gefunden.)

Tut mir leid, dass du länger gesucht hast. Ich dachte der Link auf die Wiki Seite und das genaue Zitat genügen die Stelle schnell per Suche zu finden. Leider gibt es auf der Seite keine Kapitel und somit keine "Unterlinks".

tippeltappel wrote:

Hier eine Sammlung von Wiki-Seiten, die sich mit dem Thema Baum, Wald, Obstplantagen beschäftigen:

Bäume
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
unterscheidet sich deutlich von der deutschen Übersetzung:
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree
http://wiki.openstreetmap.org/wiki/DE:Key:natural
...
Übersichtlich ist das alles irgendwie nicht gerade.
Eine Problemlösung konnte ich da nicht herauslesen.
...
Nach einigem Überlegen scheint mir eine Definition mit
denotation=landmark|natural_monument|avenue|
eine gute Idee zu sein, um das angesprochene Problem zu lösen.
...
An den mir bekannten Landmarken werde ich das Tag dann demnächts mal "dranpappen". Vielleicht merkt es ja jemand und das Vorbild macht Schule. 😉

Ich sehe hier schon eine Problemlösung. Die Kurzbeschreibung der deutschen Seite lautet "Einzelner oder signifikanter Baum". Und das ist definitiv etwas anderes als eine Baumreihe, wie ja auch das Beispielfoto zeigt. Für Baumreihen werden auf der Wiki Seite Wege vorgeschlagen. Also ist Baumreihen als nodes erfassen ein Widerspruch zum Wiki. Ich gehe davon aus, dass dies aus Unkenntnis oder Unverständnis von Wiki und den von dir so klar geschilderten Problemen geschieht. Ein Hinweis an den jeweiligen Kartografen auf Wiki und diese Diskussion dürfte genügen und schneller gehen als darauf zu warten, dass es jemand merkt. Meines Erachtens sollten die im Wiki vorhandenen Vorschläge fertig gestellt und angewendet werden anstatt neue Tags einzuführen. Die Einführung von immer mehr und neuen Tags kann auch das Gegenteil bewirken. Die Beschreibungen werden weniger gelesen, weniger verstanden, weniger akzeptiert, und noch weniger angewandt.

"Nachwort": OSM ist sehr offen und das ist gut so. Aber die Freiheit des Einzelnen endet dort wo die der Anderen anfängt.

Willi2006 wrote:

...
Ich sehe hier schon eine Problemlösung. Die Kurzbeschreibung der deutschen Seite lautet "Einzelner oder signifikanter Baum". Und das ist definitiv etwas anderes als eine Baumreihe, wie ja auch das Beispielfoto zeigt. Für Baumreihen werden auf der Wiki Seite Wege vorgeschlagen. Also ist Baumreihen als nodes erfassen ein Widerspruch zum Wiki. Ich gehe davon aus, dass dies aus Unkenntnis oder Unverständnis von Wiki und den von dir so klar geschilderten Problemen geschieht. Ein Hinweis an den jeweiligen Kartografen auf Wiki und diese Diskussion dürfte genügen und schneller gehen als darauf zu warten, dass es jemand merkt. Meines Erachtens sollten die im Wiki vorhandenen Vorschläge fertig gestellt und angewendet werden anstatt neue Tags einzuführen. Die Einführung von immer mehr und neuen Tags kann auch das Gegenteil bewirken. Die Beschreibungen werden weniger gelesen, weniger verstanden, weniger akzeptiert, und noch weniger angewandt.

Was als signifikant angesehen wird, kann je nach Betrachtungsweise
sehr unterschiedlich sein:

- Sind Bäume innerhalb eines Parkplatzes signifikant?
- Sind Bäume zwischen Radweg und Straße signifikant?
- Sind Bäume links und rechts eines Weges signifikant?

Ich denke in allen drei Beispielen ist die Antwort: Ja, das ist signifikant.
- Die Bäume unterteilen den Parkplatz.
- Die Bäume zeigen an, dass der Radweg von der Straße abgesetzt ist.
- Die Bäume links und rechts signalisieren Schatten an heißen Tagen.

Edbert (EvanE)

Bäume können auch der Orientierung dienen. Von weitem sind sie wesentlich sichtbarer als ein Schild mit einem Straßennamen oder einer Hausnummer.
Oder man sucht eine neue Wohnung und sieht schon auf der Karte schattenspendende Bäume vor einem Haus.

de_muur wrote:

natural=tree war eigentlich definiert worden fuer bedeutende Baeume.

Das war rückblickend eben keine gute Entscheidung: "tree" heißt nun einmal nur "Baum", nicht etwa "besonderer Baum" oder "alleinstehender Baum". Man sollte seine Tags schon so nennen, dass die Intention aus ihnen hervorgeht. Ich glaube, dass deutlich weniger Leute das Tag für 0815-Bäume verwendet hätten, wenn es "important_tree" o.ä. hieße...

Die Lösung des Problems sollte m.E. auch sein, "besonderen" Bäumen ein neues Tag, am besten wohl als Zusatztag zu natural=tree, zu spendieren und die Einschränkung von natural=tree auf "besondere" Bäume auch in der Dokumentation aufzugeben. Denn erstens wird man sonst auch in Zukunft "falsches" Tagging bekommen, wenn Leute einen Baum eben mit dem naheliegenden Tag "tree" eintragen, zweitens gibts von den bedeutenden bedeutend weniger, und drittens kann man so ggf. verschiedene Arten von "Bedeutung" unterscheiden.

tippeltappel wrote:

denotation=landmark|natural_monument|avenue|

Das ist doch z.B. schon mal ein guter Ansatz. Kann man damit rechnen, bei Gelegenheit ein Proposal dazu (oder zu anderen in dieser Diskussion noch auftauchenden Anregungen) zu sehen?

Ich fände es gut wenn sich Bäume auch hinsichtlich ihrer Größe klassifizieren lassen. Damit ließe sich einerseits das Rendering der Bäume besser steuern, auch ließe sich das Baumalter grob abschätzen.
http://www.hmts.de/baumalter.htm

Bikeman2000 wrote:

Ich fände es gut wenn sich Bäume auch hinsichtlich ihrer Größe klassifizieren lassen. Damit ließe sich einerseits das Rendering der Bäume besser steuern, auch ließe sich das Baumalter grob abschätzen.
http://www.hmts.de/baumalter.htm

Es gibt height=<Wert>.

Das darf man auch bei Bäumen verwenden.
Muss man halt alle paar Jahre anpassen.

Edbert (EvanE)

de_muur wrote:

godofglow wrote:

- oder mit dem Ersteller der Karte reden, ob er die Bäume ganz weglässt

Als ich das erste mal auf so ein Problem gestossen bin, habe ich mich auch ziemlich ueber den "Spinner" geaergert, der das eingetragen hat.
Danach kam dann aber schnell die Erkenntnis, dass mein bei OSM prinzipbedingt keine Vorgaben machen kann, bis zu welchem Level Details zu erfassen sind. Insofern wird es immer (mehr) solche Auswuechse geben, wo die Leute sich jenseits jeglicher Vernunft (weil auch jenseits jeglicher Genauigkeit) in Details verlieren.

Fuer dieses spezielle Problem sieht meine persoenliche Loesung so aus, dass ich in meinen selbstgebauten Karten nur noch Einzelbaeume darstelle, die einen Namen haben. Die anderen gehen leider im Rauschen des Datenmuells unter.

Gruss
Torsten

Richtig.
Zum einen heißt es Openstreetmap (= offene Straßenkarte), Bäume sollten also nicht je nach Zoomlevel die vorhandenen Straßen zudecken.
Insofern kann es m. E. aber auch nicht sein, daß das eigentliche Ziel einer Straßen-Karte, nämlich die Orientierung über den Straßenverlauf z. B. durch einen Wald oder als Allee im Wust nicht relevanter Details untergeht. So schafft nämlich derjenige, der sich in den Details verliert seinerseits Fakten (Vorgaben) für Andere. Das ist ein bischen so, wie wenn ich meinem Kumpel beim Anstreichen helfe und dabei ohne Rücksicht auf ihn, meine eigene Farbvorstellung verwirkliche. 🙂

Zum anderen:
Nicht jeder erstellt sich eigene Karten. Ich bin den Usern sehr dankbar, die periodisch aktualisierte Karten, zum Wandern oder Radfahren bereitstellen und ich hoffe, daß auch sie den Blick für´s Wesentliche nicht verlieren.

Gruß Jürgen

Für height=* lässt sich ein bestimmter Wert eintragen, das stimmt. Allerdings ist eine Messung der genauen Baumhöhe nicht gerade einfach.
Wenn man aber bestimmte Wertebereiche gruppiert würde dies das Mappen der Bäume stark vereinfachen.

tippeltappel wrote:

[…]
Zu Deinem Vorschlag, Augustus:
Wie stellst Du Dir das mit der Liste vor? Wer soll die anlegen?
Und wie soll man diese räumlichen Bezüge definieren?
[…]

Das mit den Listen ist als Abhilfe zur Kartenerstellung gedacht bis sich geeignete Tags durchgesetzt haben.
Die beiden Listen ließen sich automatisiert beim Erzeugen / Rendern der Karten anlegen und füllen (falls denn die Werkzeuge für die Garmin-Karten so was erlauben). Was dabei als näherer Umkreis gilt, ist meiner Meinung nach vom Einsatzzweck der Karte abhängig.

@ Tordanik @ Edbert
Ich sehe das ähnlich wie Ihr. Bäume können je nach Blickwinkel ganz unterschiedliche Bedeutung haben. Ein Tag wie important_tree führt daher wohl kaum zu einer zufriedenstellenden Filterung. Innerhalb städtischer Bebauung ist jeder große Baum von Bedeutung.

Für schattenspendende Bäume vor Wohnblocks, auf Parkplätzen usw, die keine besondere historische aber eine große ökologische Bedeutung haben, könnte man das Schema erweitern

denotation=landmark|natural_monument|avenue|village_green

Das ist bewußt analog zu landuse=village_green gedacht und läßt sich ohne Verwechslungsgefahr auswerten.

@ Bikeman
Dein Wunsch wurde schon lange umgesetzt und hier beschrieben:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
Offensichtlich ist die Umsetzung dieser Idee jedoch für viele zu mühsam. Wenn ich mit Pferd unterwegs bin, hab ich für solche Ideen ehrlich gesagt keinen Kopf. 😉

@ Willi
Die Bemerkung war nicht als Vorwurf gedacht! Nochmals Danke für den Tipp! 🙂
Hatte bei dem blauen Wort "wiki" nicht "geschaltet" und Deinen Hinweis lediglich als Anregung genommen, das Web nach weiteren Hinweisen zum "garden"-Tagging abzusuchen.

Gruß
tippeltappel

Augustus Kling wrote:

tippeltappel wrote:

[…]
Zu Deinem Vorschlag, Augustus:
Wie stellst Du Dir das mit der Liste vor? Wer soll die anlegen?
Und wie soll man diese räumlichen Bezüge definieren?
[…]

Das mit den Listen ist als Abhilfe zur Kartenerstellung gedacht bis sich geeignete Tags durchgesetzt haben.
Die beiden Listen ließen sich automatisiert beim Erzeugen / Rendern der Karten anlegen und füllen (falls denn die Werkzeuge für die Garmin-Karten so was erlauben). Was dabei als näherer Umkreis gilt, ist meiner Meinung nach vom Einsatzzweck der Karte abhängig.

Sorry, das vermittelt mir absolut keine Idee, wie man das mit einfachen Mitteln (beispielsweise dem MapComposer) umsetzen könnte.
Wie bereits beschrieben, baut man mit Hilfe von Renderregeln auf der Basis von vorhandenen Tags Filter, die die Objekte quasi an- oder ausschalten. > wo kein denotation- oder name-Tag, da kein Filter bzw. nur an/aus

Die einzige praktikable Zwischenlösung ist, daß alle unklassifizierten Bäume extrem verkleinert dargestellt und aus den Suchlisten entfernt werden oder ganz aus Garmin-Karten rausfliegen. Daß dabei auch wünschenswerte Infos verloren gehen, beschrieb ich ja bereits.
Wer gemappte Bäume vermißt, muß prüfen, ob sie mit einem eindeutig nachvollziehbarem Schema klassifiziert sind.

denotation=landmark|natural_monument|avenue|village_green|
und wenn village_green nicht paßt > park oder garden ?

für Bäume mit (belegten, historischen) Namen name=***

Aber daß dann nicht einige Mapper auf die Idee kommen, die botanischen Bezeichnungen in das name-Tag zu packen, weil sie "ihren" Baum in einer zum Download angebotenen Karte sehen wollen. Solche Infos legt man ab in:

1. species=Quercus
   
2. species:en=Oak
   
3. species:de=Eiche
   

Zu finden auf
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

Gruß
tippeltappel

EvanE wrote:

Was als signifikant angesehen wird, kann je nach Betrachtungsweise
sehr unterschiedlich sein:
...
- Die Bäume links und rechts signalisieren Schatten an heißen Tagen.

Signifikant bedeutet laut Duden wichtig, bedeutsam, natürlich im jeweiligen Kontext.

Der Baum in meinem Vorgarten ist für mich wichtig und bedeutsam, da er mir Schatten spendet, manchmal auch Passanten. Ebenso wichtig und bedeutsam ist für mich das Grab meiner Oma, manchmal gehen auch andere dran vorbei oder sehen es gar an. Ich käme jedoch nie auf die Idee, deshalb meinen Baum oder das Grab meiner Oma in einer weltweiten Straßenkarte einzutragen weil mir klar ist, dass Andere meine persönliche Betrachtungsweise nicht teilen.

Diese und andere Diskussionen erinnern mich an die Debatte bei Wikipedia zwischen Inkludisten und Exkludisten, siehe zum Beispiel Die Relevanz des Todessterns oder Wikipedia: Wer Relevanz und Referenz verwechselt. Ist OSM auch schon so weit?

tippeltappel wrote:

[…]Sorry, das vermittelt mir absolut keine Idee, wie man das mit einfachen Mitteln (beispielsweise dem MapComposer) umsetzen könnte.
Wie bereits beschrieben, baut man mit Hilfe von Renderregeln auf der Basis von vorhandenen Tags Filter, die die Objekte quasi an- oder ausschalten. > wo kein denotation- oder name-Tag, da kein Filter bzw. nur an/aus
[…]

Wenn ich das nun richtig verstehe, hat man beim Erstellen von Karten für Garmins nur Tags als Filterkriterium. Die Positionen und Dichte von Objekten stehen also nicht zur Verfügung, oder?
Falls das so ist, dann kannst du alles was ich oben geschrieben hatte ignorieren weil es sich mit den verfügbaren Werkzeugen nicht umsetzen ließe.

Willi2006 wrote:

Diese und andere Diskussionen erinnern mich an die Debatte bei Wikipedia zwischen Inkludisten und Exkludisten, siehe zum Beispiel Die Relevanz des Todessterns oder Wikipedia: Wer Relevanz und Referenz verwechselt. Ist OSM auch schon so weit?

Das ist kein allgemeines OSM-Phänomen, sondern liegt speziell den Deutschen im Blut. Bevor die Schmähungen jetzt kommen: Gehöre auch dazu.... 😉
Man vergleiche mal die Anzahl der Topics und Posts der deutschen Userlist mit denen unserer Nachbarn.

Gruß Jürgen

Die "Baumseite" wurde gründlich "renoviert".
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree

tippeltappel wrote:

Die "Baumseite" wurde gründlich "renoviert".
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree

gefällt mir gar nicht und ein Tree ist nunmal ein stinknormaler Baum. Wenn er was besonderes ist, sollte man das meiner Meinung nach mit zusätzlichen Attributen tun und nicht den Tag umdeuten.
Erinnert mich an eine Dienstanweisung der Deutschen Post
"Ein Postsack ist ein Beutel, der wegen seiner besonderen Verwendung nicht Postbeutel, sondern Postsack genannt wird. Sollte es sich bei der Versackung eines Postbeutels herausstellen, dass ein, in einem Postsack versackter Versackbeutel hätte versackt werden müssen, so ist die zuständige Versackstelle zu benachrichtigen"

tippeltappel wrote:

Die "Baumseite" wurde gründlich "renoviert".
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree

Ah, ich liebe diese Alleingänge. Hatte jemand außerhalb des deutschen Forums schon eine Chance, sich dazu zu Wort zu melden?

Inhaltlich finde ich mindestens folgendes seltsam:

Eine breitere Ausdehnung der Baumreihe legt man als langes, schmales Polygon an.

Das halte ich für unbrauchbar in jeder Anwendung, die tatsächlich Bäume und nicht nur ein grünes Polygon zeichnen will. Bitte streichen. Man kann gerne ein Flächentag für "von Bäumen bedeckte Fläche, die kein Wald ist" diskutieren, aber das ist dann keine Baumreihe mehr. Eine Baumreihe ist per Definition durch einen Way angemessen darstellbar.

signifikanter, alleinstehender Baum

Diese Definition ist nicht neu, aber vor dem Hintergrund einer Einführung von denotation=* noch unsinniger als bisher. "tree" heißt nun mal immer noch "Baum", und dank denotation kann man wichtige Bäume von unwichtigen problemlos an eben diesem Tag (denotation) unterscheiden.

landuse=forest oder besser landuse=tree_row - längliche im Bereich von Weg/Fluß/etc. angelegte Fläche

Erstens: landuse=forest ist für den Anwendungsfall nicht schlechter, sondern falsch. Ein Wald ist was anderes als eine Gruppe Bäume!
Zweitens: Das ist schon wieder keine Baumreihe, sondern eine Fläche mit Bäumen. Wie wäre es mit einem Wert "trees" o.ä.?
Drittens: Es wurde bei den bisherigen Proposals oft genug angemerkt, dass landuse problematisch für so was ist - insbesondere wegen der häufigen Existenz solcher Bereiche auf dem Gebiet anderer landuses. Und wieso nicht natural als Key nehmen wie für Bäume und Baumreihen auch?

natural=tree_line

Wo kommt dieses Tag her? Mir ist es ziemlich egal, ob es nun tree_line oder tree_row heißt - aber ich wüsste doch gerne ob tree_line jetzt vom Himmel gefallen ist oder vorher schon irgendwo dokumentiert war. Falls ersteres: Bitte ans bereits dokumentierte Tag halten oder die Neuerfindung begründen.

Tordanik wrote:

vor dem Hintergrund einer Einführung von denotation=*

ich find dazu nichts. Gibt es dazu einen Link?

tippeltappel wrote:

Die "Baumseite" wurde gründlich "renoviert".
http://wiki.openstreetmap.org/wiki/DE:T … ral%3Dtree

Nun ja.

Du solltest zumindest klar zeigen, was (neue) Vorschläge im Gegensatz
zu den etablierten Tags sind.

Im Übrigen hat das Ganze nur eine eingeschränkte Bedeutung,
wenn es nicht auch der englischen Version erscheint.

JM2C
Edbert (EvanE)

SunCobalt wrote:

Tordanik wrote:

vor dem Hintergrund einer Einführung von denotation=*

ich find dazu nichts. Gibt es dazu einen Link?

Wahrscheinlich nicht. Der Schlüssel 'denotation' wurde durch diese Änderung
der Wiki-Seite von 'natural=tree' quasi heimlich eingeführt.

Ich denke, dass 'Tordanik' auf eine Inkonsistenz in 'tippeltappel's
Änderungen aufmerksam machen wollte.

Edbert (EvanE)

In Wikipedia gibt es über tree_line http://en.wikipedia.org/wiki/Tree_line einen Artikel.
Das bedeutet wohl eher Baumgrenze und wäre so gesehen als Definition für eine Baumreihe falsch.
natural=tree_row ist dafür sicherlich passender.

Der englische Begriff line ist offensichtlich sehr vieldeutig:
http://dict.leo.org/?lp=ende&from=fx3&search=line
Daraus erwachsen leicht Mißverständnisse.

Da die ursprüngliche Definition "alleinstehender, signifikanter Baum" von vielen Mappern längst fleißig ignoriert wird, sollte man darüber abstimmen, ob man diese Definition auch "offiziell" fallen läßt.

Wer nimmt das in die Hand?

Wenn die Definition landuse=wood/forest/scrub für eine mit Bäumen bestandene Uferzone oder andere langgestreckte mit Bäumen besetzte Flächen nicht paßt, scheint natural=trees eine brauchbare Alternative zu sein. Das paßt auch für kleine Baumgruppenpolygone. Ab welcher Fläche dann statt natural=trees landuse=forest/wood (je nach Nutzung) benutzt wird, ist dann wohl eine Ermessensfrage des Mappers. Ob dieser Ermessensspielraum dann am Ende zu Problemen führt?

Gruß
tippeltappel

tippeltappel wrote:

In Wikipedia gibt es über tree_line http://en.wikipedia.org/wiki/Tree_line einen Artikel.
Das bedeutet wohl eher Baumgrenze und wäre so gesehen als Definition für eine Baumreihe falsch.
natural=tree_row ist dafür sicherlich passender.

Der englische Begriff line ist offensichtlich sehr vieldeutig:
http://dict.leo.org/?lp=ende&from=fx3&search=line
Daraus erwachsen leicht Mißverständnisse.

lass doch mal LEO aussen vor. LEO ist nicht so toll. Row scheint da passender, da es scheinbar öfter benutzt wird. Siehe bestehenden Link in Tordaniks Post und hier http://www.linguee.de/search?query=baumreihe

tippeltappel wrote:

Da die ursprüngliche Definition "alleinstehender, signifikanter Baum" von vielen Mappern längst fleißig ignoriert wird, sollte man darüber abstimmen, ob man diese Definition auch "offiziell" fallen läßt.

Wer nimmt das in die Hand?

warum? Es geht doch hier darum, dass "unbedeutende"und "störende" Bäume eingetragen wurden. Scheint ja fast so, als wäre die Abstimmung schon in der Realität erfolgt. Es gibt sehr viele Leute, die schauen nicht ins Forum, Mailingliste und nur bei Zweifeln in die Map Features. Denen kann man nie beibringen, dass ein Tree jetzt ein besonderer Baum sein soll. Ein "offiziell" gibts eh nicht. Ich werde weiterhin jeden Baum taggen, von dem ich denke, dass es nicht schaden kann.

Kannst Du das Wiki bitte wieder korrigieren?