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

@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

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

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

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.4848&lon=6.8241&zoom=17&layers=B000FTF
http://www.openstreetmap.org/?lat=50.4817&lon=6.84347&zoom=16&layers=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:Tag:natural%3Dtree
http://wiki.openstreetmap.org/wiki/DE:Key:natural

Wald
http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dforest
http://wiki.openstreetmap.org/wiki/User:Fabi2/treetype

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

Obstanbau
http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%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

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

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.

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