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

@ 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 :frowning: , 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? - - :frowning: :frowning: :frowning:

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. :wink:

Viele Grüße
tippeltappel

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”.

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.

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.

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.

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

Es gibt height=.

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

Edbert (EvanE)

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. :slight_smile:

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.

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. :wink:

@ Willi
Die Bemerkung war nicht als Vorwurf gedacht! Nochmals Danke für den Tipp! :slight_smile:
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

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:

species=Quercus

species:en=Oak

species:de=Eiche

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

Gruß
tippeltappel

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?

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.

Das ist kein allgemeines OSM-Phänomen, sondern liegt speziell den Deutschen im Blut. Bevor die Schmähungen jetzt kommen: Gehöre auch dazu… :wink:
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:Tag:natural%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”