Sind solche Klusters erwünscht?

Baumschwund? Abholzer? Von was sprichst du? In Mitteleuropa sind die Wälder sehr stark am wachsen - zT zu stark am wachsen...

Prinzipiell ist gegen das Kartieren einzelner Bäume nichts einzuwenden - wenn es dann den Baumbestand einer Stadt betriftt, wäre es wünschenswert, wenn Gattung, Größe und eventuell vorhandene Referenznummer eines Baumkatasters hinzukommen... Der derzeit enthaltene Datenstand ist etwas fragwürdig, da nicht alle Bäume eingetragen sind (wenn man es macht, sollte man es vollständig machen...)

http://osm.org/go/0M3bR4xbA--

Tagging für jeden Baum dort:

circumference
crown_radius
denotation
genus
genus:pl
health
height
type

siehe tree table in der Wiki...
😉

In Wien wurden auch die Bäume importiert:
http://www.openstreetmap.org/?lat=48.21 … 13&zoom=17
Tagging:
http://www.openstreetmap.org/browse/node/2044241284

Wie bekomme ich per Overpass API den höchsten Baum raus? 😄

vielleicht sollte man auch alle häuser in einen extra layer packen? nur so als idee...
😄

Ich persönlich finde das taggen der Bäume eigentlich unproblematisch. Ich denke auch hier wurde wie in Wien ein Baumkataster importiert. Wenn die Daten einmal zur verfügung stehen, sollte man sie auch nutzen. Vielleicht lässt sich ja so beim "Spender" erreichen, dass er sich für die weitergehende Bereitstellung von Daten (wie zum beispiel die fehlenden Hausnummern im Nachbarort http://www.openstreetmap.org/?lat=47.54 … 1&zoom=16) einsetzt.

Gerade bei den Hausnummern gibt es m.E. auch hinsichtlich eines genauen Routings noch Defizite, ganz besonders im ländlichen Bereich.

Grüße aus Sachsen

Uwe

Nahmd,

chris66 wrote:

den höchsten Baum raus? 😄

Das ist ohne jede Frage der hier, insbesonders im Vergleich zu dem hier.

Gruß Wolf

.oO( und jetzt schnell hinter einem dicken Baum in Deckung gehen )

An diejenigen, die hier das Importieren der Bäume befürworten: Wie sollen die Daten aktuell gehalten werden? Insbesondere, wie werden wir die Bäume wieder los, die im nächsten Baumkataster nicht mehr vorhanden sind, weil sie der Kettensäge oder dem fleißigen Biber zum Opfer gefallen sind?

Baßtölpel

Moin

Die Bäume hält man so aktuell wie die anderen Daten auch: mit Mapper vor Ort.
Ich trag auch jede Menge Bäume ein. Vorerst nur mit natural=tree, aber da ist ja nunmal auch nen Baum.
Ich trag auch die Eingänge zu den Häusern als highway=service & access=private ein.
Und Strassenlaternen.
Und Dachformen und Häuserfarben^^

Amiga4000

Basstoelpel wrote:

Wie sollen die Daten aktuell gehalten werden?

Gar nicht, das gehört bei einem Import dazu. Und ich fürchte, daß Bäume bald unser kleinstes Problem sein werden, wenn nun sukzessive mehr öffentliche Daten verfügbar werden und deren blindes Importieren auch bei uns immer mehr in Mode kommt.

Oli-Wan wrote:

Und ich fürchte, daß Bäume bald unser kleinstes Problem sein werden...

So wirds wohl sein, den ein Baum wird viele hundert Jahre alt und kann nicht wandern (außer in Stuttgart 😉 )
Er wechseln nicht die Farbe, hat keine Telefonnummer oder Webseite, interessiert sich nicht für Relationen und nicht für's routing.
Er bleibt sein leben lang entweder ein Laubbaum oder ein Nadelbaum 🙂

Nahmd,

Amiga4000 wrote:

Die Bäume hält man so aktuell wie die anderen Daten auch: mit Mapper vor Ort.
Ich trag auch jede Menge Bäume ein. Vorerst nur mit natural=tree, aber da ist ja nunmal auch nen Baum.

Aber bitte immer mit “type=”, auch wenn es nur für den Renderer ist.

Ich habs nicht so mit Bäumen, bin eher ein Heckenschütze. 😉

Ich trag auch die Eingänge zu den Häusern als highway=service & access=private ein.

Willkommen im Club. 🙂

Und Dachformen und Häuserfarben^^

Die Dachformen könnte ich mir auch angewöhnen, die Häuserfarben lasse ich aber lieber sein. 🤔

Gruß Wolf

Nur leider fehlt auch bei dem Massenimport in Wien wieder das wichtigste Tag: Die Klassifizierung als "urban".

Wie im Wiki noch zu lesen ist natural=tree eigentlich nicht irgendein Pipifax-Baum sondern ein markanter Baum. Das ist nur durch die ganze Massenerzeugung kartographisch irrelevanter Gewächse komplett verwässert.

Jetzt haben wir durch solche Importe massenhaft unbedeutende Bäume mit veralteter Beschreibung (die Dinger neigen dazu zu wachsen oder einzugehen) und können einen Blumenkübel in Wien (kartographisch völlig irrelevant) und eine weithin sichtbare Eiche auf dem Feld (kartographisch relevant und auf jeder normalen Topokarte zu finden) nicht mehr am Tagging unterscheiden.

Von daher betrachte ich jeden dieser unzureichend getaggten Massenimporte als deutliche Verschlechterung der Datenqualität. Wieso passiert es eigentlich immer wieder daß ein Massenimport entgegen der Beschreibung im Wiki durchgezogen wird?

bye, Nop

Moin!

Netzwolf: Uh, ich nix Biologe. Wie soll ich da nur den korrekten Type finden.
Nop: zu dem Import in Wien gab es ausreichend vorher eine Diskussion in talk-at. Warum/wieso/weshalb sollte da nachzulesen sein. Oder wenns fehlt: hat niemand gewusst.
Aber im Wiki steht: natural=tree - a single tree, often significant.
Ein einzelner Baum. Und oft signifikant, aber nicht immer. Nun kann man streiten, ob die vielen einzelnen, nicht signifikanten Bäume das verwässern oder nicht. Aber z.B. eine Allee mit Bäumen rechts und links, da sind IMHO die Bäume schon signifikant. Und da setz ich halt jeden Baum nen Tag.
Genauso am Spielplatz oder Grundstücke/Wiesen: wenn da 4 Bäume neben dem Sportplatz stehen, fallen die auf und sind da. Werden getaggt.
Einzelne Bäume im Wald werden ned getaggt, ausser sie sind wichtig. Und für wichtige Bäume kann man ja noch "monumental trees: additional monument=yes" hinzunehmen.

Die Baum-reihen mag ich ned so wirklich, aber haben auch ihre Daseinsberechtigung. Halt so nen Ding zwischen Wald und einzelnem Baum. Wo man einzelne Bäume ned erkennen kann, aber zu schmal für nen Wald ist.

Amiga4000

Amiga4000 wrote:

Netzwolf: Uh, ich nix Biologe. Wie soll ich da nur den korrekten Type finden.

“type=” unterscheidet nur zwischen Laubbaum und Nadelbaum. 🙂

Aber im Wiki steht: natural=tree - a single tree, often significant.
Ein einzelner Baum. Und oft signifikant, aber nicht immer. Nun kann man streiten, ob die vielen einzelnen, nicht signifikanten Bäume das verwässern oder nicht. Aber z.B. eine Allee mit Bäumen rechts und links, da sind IMHO die Bäume schon signifikant. Und da setz ich halt jeden Baum nen Tag.
Genauso am Spielplatz oder Grundstücke/Wiesen: wenn da 4 Bäume neben dem Sportplatz stehen, fallen die auf und sind da. Werden getaggt.
Einzelne Bäume im Wald werden ned getaggt, ausser sie sind wichtig. Und für wichtige Bäume kann man ja noch "monumental trees: additional monument=yes" hinzunehmen.

Mit der Angabe der Klassifizierung hilfst Du den Kartenrenderern: die müssen aus einem Überangebot an Daten auswählen, was sie darstellen und wie. Die Klassifizierung hilft dabei sehr: ein Naturdenkmal wird man so eben möglich immer darstellen, mglw. mit einem "ND" daneben wie in topographischen Karten. Auch ein Landmark wird man immer darstellen. Habe ich aber einen Haufen Bäume ohne weitere Angaben, so werde ich vielleicht einen kleinen grünen Punkt rendern, möglicherweise aber auch gar nichts. Letztendlich wird man als Kartenersteller bei der Generalisierung Bäume ohne Klassifikation einfach als irrelevant wegfiltern.

Gruß Wolf

Netzwolf wrote:

Mit der Angabe der Klassifizierung hilfst Du den Kartenrenderern: die müssen aus einem Überangebot an Daten auswählen, was sie darstellen und wie. Die Klassifizierung hilft dabei sehr: ein Naturdenkmal wird man so eben möglich immer darstellen, mglw. mit einem "ND" daneben wie in topographischen Karten. Auch ein Landmark wird man immer darstellen. Habe ich aber einen Haufen Bäume ohne weitere Angaben, so werde ich vielleicht einen kleinen grünen Punkt rendern, möglicherweise aber auch gar nichts. Letztendlich wird man als Kartenersteller bei der Generalisierung Bäume ohne Klassifikation einfach als irrelevant wegfiltern.

Und genau so herum wäre es m.E. auch sinnvoll angelegt, anstatt erzwingen zu wollen, das unbedeutende Bäume mit Extra-Tag als gekennzeichnet werden. Das kann doch nicht funktionieren, weil es nicht intuitiv ist, das ein einfacher Baum mit natural=tree nicht hinreichend beschrieben ist, sondern natural=tree für besondere Bäume reserviert sein soll.

Nahmd,

g0ldfish wrote:

Und genau so herum wäre es m.E. auch sinnvoll angelegt, anstatt erzwingen zu wollen, das unbedeutende Bäume mit Extra-Tag als gekennzeichnet werden.

Ja.

Wobei bei einem Import ein Komplett-Tagging (im angesprochenen Fall: Klasse=Stadtbegrünung) kein Mehraufwand gewesen wäre. Und über die Angabe Laubbaum/Nadelbaum freut sich der 3D-Renderer. 🙂

Gruß Wolf

Leider wurde (dürfte so ca. 2 Jahre her sein) wie es losging das natural=tree nicht mehr nur für signifikante Bäume genommen wurde (was Jahrelang vorher ja konsens war!)

Die falsche Entscheidung mittels BOT umgesetzt und dabei denotation=urban bzw. denotation=cluster den normalöen Bäumen mitgegeben.

Damals fand ich es OK im nachinein währe es besser gewesen dem signifikante Bäumen einen tag mitzugeben.

Nun wird es immer schwerer das zu unterscheiden!

Amiga4000 wrote:

Nop: zu dem Import in Wien gab es ausreichend vorher eine Diskussion in talk-at. Warum/wieso/weshalb sollte da nachzulesen sein. Oder wenns fehlt: hat niemand gewusst.

Ich frag mich natürlich wie qualifiziert die Diskussion war wenn noch nicht mal das Wiki berücksichtigt wird. :-(

bye, Nop

g0ldfish wrote:

Und genau so herum wäre es m.E. auch sinnvoll angelegt, anstatt erzwingen zu wollen, das unbedeutende Bäume mit Extra-Tag als gekennzeichnet werden. Das kann doch nicht funktionieren, weil es nicht intuitiv ist, das ein einfacher Baum mit natural=tree nicht hinreichend beschrieben ist, sondern natural=tree für besondere Bäume reserviert sein soll.

Es gibt viele wenig intuitive Tags bei OSM, die historisch gewachsen sind. Wenn natural=tree jeder Baum ist, wieso sind viele Bäume dann nicht natural=wood sondern landuse=forest? Ein künstlicher Fischteich dagegen ist natural=water? Oder umgekehrt wenn nur Urwald natural=wood ist, dürfte ein künstlich gepflanzter Allee-, Deko oder Parkbaum überhaupt natural sein?

Wenn wir hier auf der grünene Wiese diskutieren würden, wie wir den ersten Baum in der DB taggen wollen, würde ich Dir völlig zustimmen.

Es ist aber so, daß bis September 2010 die Defintion "Lone or significant tree" unangefochten und ohne jede Diskussion im Wiki stand. D.h. 6 Jahre lange haben hunderte von Mappern 1000ende von Bäumen (ja, es gab zwei Auswertungen der Daten dazu wo nachgezählt wurde) nach dieser Definition eingetragen.

Dann haben Leute angefangen massenhaft irrelevante Bäume aus Spaß oder Massenimporten entgegen diesem Tagging in die Datenbank zu blasen. Als Reaktion wurden nicht die Daten korrigiert sondern der Wiki-Eintrag auch entsprechend verwässert.

Das ändert aber nichts daran, daß mehrere 1000 vorher mühsam von Hand als signifikanter Baum eingetragene Objekte dadurch bedeutungslos wurden.

Nachträglich die Definition eines 1000fach benutzten Tags zu ändern oder sie einfach mit einem abweichend getaggten Massenimport zu überbügeln ist für mich Vandalismus: Die Information, die viele Mapper mühsam eingetragen haben geht verloren. Genausogut hätte man die Objekte selbst willkürlich umtaggen können.

Ich hab den Wien-Importer angeschrieben und ihm erklärt warum für einen vollständigen Import noch das "urban" Tag fehlt. Ich glaube nicht daß was passieren wird, da hab ich schon resigniert. Aber still zugucken wie gute Daten durch schlechte Importe zerstört werden kann ich auch nicht.

Was mich jedesmal wieder erschreckt mit welcher Gedankenlosigkeit der gleiche Fehler immer wieder wiederholt wurd und mit welcher Gleichgültigkeit solche Zerstörungen von der Mehrheit in Kauf genommen werden. Wenn jemand ein paar Objekte direkt beschädigt, rückt ihm die DWG auf die Pelle, aber wenn 1000nden Objekten rückwirkend die Definition entzogen wird, das ist ok.

kopfschüttelnd, Nop

Nop wrote:

Es gibt viele wenig intuitive Tags bei OSM, die historisch gewachsen sind. Wenn natural=tree jeder Baum ist, wieso sind viele Bäume dann nicht natural=wood sondern landuse=forest?

Ja, das ist auch nicht ideal und wenn es nach mir ginge, wären wir schon länger zu "natural=wood" für alle Wälder und ein Zusatztag für "forstwirtschaftlich genutzt" (oder eben "naturbelassen" o.ä.) zurückgekehrt.

Leider ist das nachträglich schwer durchzusetzen. Im Fall natural=tree setzt sich die sinnvollere Definition derzeit hingegen von ganz alleine durch - man müsste der Entwicklung nur freien Lauf lassen und den Widerstand aufgeben.

Es ist aber so, daß bis September 2010 die Defintion "Lone or significant tree" unangefochten und ohne jede Diskussion im Wiki stand. D.h. 6 Jahre lange haben hunderte von Mappern 1000ende von Bäumen (ja, es gab zwei Auswertungen der Daten dazu wo nachgezählt wurde) nach dieser Definition eingetragen.

Ja, das ist vor drei Jahren schlecht gelaufen. Ändert dein jetziger Widerstand etwas daran, wie es gelaufen ist?

Sollte deine Vermutung stimmen, könntest du ja prinzipiell auch jetzt noch allen Bäumen, die vor September 2010 erstellt und seither nicht geändert wurden, ein lone_or_significant=yes anhängen. Bei allen natural=tree, die seither erfasst wurden, gibt es keinerlei Grund, eine besondere Bedeutung zu vermuten.

Netzwolf wrote:

Und über die Angabe Laubbaum/Nadelbaum freut sich der 3D-Renderer. 🙂

Oh, Nachtrag: Dieser Hinweis verdient ein +1. 😉

Tordanik wrote:

Ja, das ist auch nicht ideal und wenn es nach mir ginge, wären wir schon länger zu "natural=wood" für alle Wälder und ein Zusatztag für "forstwirtschaftlich genutzt" (oder eben "naturbelassen" o.ä.) zurückgekehrt.

Das unterstütze ich voll und ganz. Das was im Wiki als Kriterium für "natural=wood" genannt wird ist für mich in letzter Kosequenz nicht schlüssig, da ich genug Wälder kenne, die in ihrer Zusammensetzung natürlich sind, totzdem aber bewirtschaftet werden.

Sven

streckenkundler wrote:

Das unterstütze ich voll und ganz.

Ich auch. Und viele mehr, wie auch an Proposals wie "http://wiki.openstreetmap.org/wiki/Prop … /landcover" zu sehen ist. Leider geht da nichts voran :-(

Aber natürlich würde ich hier nur ungern "natural=" sehen, weil nicht jeder forstwirtschaftlich genutzte Wald (wozu gehört dann eine Christbaumkultur?) auch "natürlich" ist. Ich beschreibe zuerst einfach nur, dass da Bäume sind. Und ob die spärlich genutzten Hangwälder im Hochgebirge eher "Urwald" oder "Wald" sind, kann/möchte ich spätestens an der Grenze bei den Latschen nicht mehr beantworten. Wie wäre es mit sowas wie "typ=naturnah" als Zwischending? Hier wäre dann auch sowas wie "typ=park" möglich, weil man doch immer wieder Probleme mit dem Taggen von größerem innerörtlichen Baumbestand hat.
Wer erbarmt sich?

streckenkundler wrote:

Tordanik wrote:

Ja, das ist auch nicht ideal und wenn es nach mir ginge, wären wir schon länger zu "natural=wood" für alle Wälder und ein Zusatztag für "forstwirtschaftlich genutzt" (oder eben "naturbelassen" o.ä.) zurückgekehrt.

Das unterstütze ich voll und ganz. Das was im Wiki als Kriterium für "natural=wood" genannt wird ist für mich in letzter Kosequenz nicht schlüssig, da ich genug Wälder kenne, die in ihrer Zusammensetzung natürlich sind, totzdem aber bewirtschaftet werden.

Sven

Meiner Beobachtung nach ist wood oder forest eher Zufall und oft austauschbar, zumindest ausserhalb Westeuropas, wo alles geregelt sein muss. Wälder sind nun mal Wälder und ob die forstwirtschatliche Nutzung nun (gesetzlich) geregelt ist oder nicht ändert nichts daran, dass in fast jedem Wald mal Bäume gefällt werden um sie zu nutzen. Es gibt viele Leute bei OSM, die die Unterscheidung nichtmal verstehen weil dort Wälder nicht "bewirtschaftet" werden sondern einfach so vor sich hinwachsen und ab und an mal ein paar Bäume gefällt werden.

Was die ursprüngliche Bedeutung von natural=tree angeht, ist es eigentlich egal welcher Meinung man ist. Die Realität hat die ursprüngliche Bedeutung überholt. Da kann beleidigt sein wie man will, jahrelang schmollen und auf seine ehemals berechtigte Meinung bestehen, aber es ändert nichts mehr.

SunCobalt wrote:

Wälder sind nun mal Wälder und ob die forstwirtschatliche Nutzung nun (gesetzlich) geregelt ist oder nicht ändert nichts daran, dass in fast jedem Wald mal Bäume gefällt werden um sie zu nutzen. Es gibt viele Leute bei OSM, die die Unterscheidung nichtmal verstehen weil dort Wälder nicht "bewirtschaftet" werden sondern einfach so vor sich hinwachsen und ab und an mal ein paar Bäume gefällt werden.

...deswegen verstehe ich die Abgrenzung/Unterteilung auch nicht. Wenn ich eine festgelegte absolute Nichtnutzung des Waldes habe (Naturwald, keine forstliche Nutzung) dann fällt das für mich in die Kategorie boundary=protected_area mit protectet_Class= irgendwas... Da dies i.d. R. in urgend einer Art und Weise administrativ festgelegt ist.
Ansonsten ist das Wald, als Nadel- Misch oder Laubwald, zuzüglich einer optionalen Angabe eines Natürlichkeitsgrades (beschreibt den Grand der natürlichen Ausstattung in Hinblick auf Baumartenzusammensetzung, Unterwuchs und Krautflora)... 3, maximal 5 Stufen reichen da... Aber wie gesagt: optional, für Mapper, die ob ihres Wissens dazu in der Lage sind, Aussagen zu treffen. Genau so fehlen mir noch ettablierte Subtags die den Feuchtegradienten von Wald ( auch Offenland) darstellen, auch...

So. um auch noch zum Thema was zu sagen: Diese Einzelbaumgeschichte ist auch komisch... abgesehen von den klassischen Baumreihen und Alleen: Die Unterscheidung, ob ein Einzelbaum was natürliches ist oder nicht, kann kaum einer sagen... lediglich markannte Einzelbäume im Siedlungsbereich (ich gehe erst mal hier explizit vom ländlichen Raum aus) können i.d.R. als gepflanzt angesehen werden. Alles andere... das weiß nur die Göttin der Bäume...

Letztendlich sind das neutrale Einzelbäume: mir kommt da single_tree=yes; tree=coniferius;decidious, name=* ect.pp. in den Sinn... Aber wie gesagt: das ist ausschließlich Baumreihen und Alleen. Die sind Straßen- und Wegeblegleitend und gehören dahin.

Sven

Nop wrote:

Es ist aber so, daß bis September 2010 die Defintion "Lone or significant tree" unangefochten und ohne jede Diskussion im Wiki stand. D.h. 6 Jahre lange haben hunderte von Mappern 1000ende von Bäumen (ja, es gab zwei Auswertungen der Daten dazu wo nachgezählt wurde) nach dieser Definition eingetragen.

Dann haben Leute angefangen massenhaft irrelevante Bäume aus Spaß oder Massenimporten entgegen diesem Tagging in die Datenbank zu blasen. Als Reaktion wurden nicht die Daten korrigiert sondern der Wiki-Eintrag auch entsprechend verwässert.

Das ändert aber nichts daran, daß mehrere 1000 vorher mühsam von Hand als signifikanter Baum eingetragene Objekte dadurch bedeutungslos wurden.

Wieviele Bäume hast du damals eigentlich mit denotation = cluster, fixme = set better denotation versehen? Das dürften doch diverse 10.000 gewesen sein, oder?

Hättest du stattdessen die (mutmaßlich kleinere) Gegenmenge mit denotation = landmark, fixme = verify denotation o.ä. bedacht, wäre das vielleicht weniger kritisiert worden (vielleicht auch nicht), vor allem aber wäre es deutlich zukunftssicherer gewesen, weil nicht andauernd neu hinzukommende (unbedeutende) Bäume nachbearbeitet werden müssten.

Auch ein bisschen kopfschüttelnd,
g0ldfish

Das scheint ein grösseres Ding zu sein. Ich bin noch nicht so Expert in OSM aber ich weiss aus anderen Projekten, das "saubere" Datensätze eine unbedingte Voraussetzung sind um relevante Daten wiederzufinden. Es wäre vielleicht wünschenswert, wenn ein Supervisor Kommitee Daten löscht die nicht den Kriterien entsprechen?

Atalantia wrote:

Das scheint ein grösseres Ding zu sein. Ich bin noch nicht so Expert in OSM aber ich weiss aus anderen Projekten, das "saubere" Datensätze eine unbedingte Voraussetzung sind um relevante Daten wiederzufinden. Es wäre vielleicht wünschenswert, wenn ein Supervisor Kommitee Daten löscht die nicht den Kriterien entsprechen?

welchen kriterien?

Tordanik wrote:

Sollte deine Vermutung stimmen, könntest du ja prinzipiell auch jetzt noch allen Bäumen, die vor September 2010 erstellt und seither nicht geändert wurden, ein lone_or_significant=yes anhängen. Bei allen natural=tree, die seither erfasst wurden, gibt es keinerlei Grund, eine besondere Bedeutung zu vermuten.

Dafür gibt es dann denotation = landmark/urban/avenue/cluster.
Das tagge ich bei jedem Baum immer mit ran.

Jayjay01 wrote:

Atalantia wrote:

Das scheint ein grösseres Ding zu sein. Ich bin noch nicht so Expert in OSM aber ich weiss aus anderen Projekten, das "saubere" Datensätze eine unbedingte Voraussetzung sind um relevante Daten wiederzufinden. Es wäre vielleicht wünschenswert, wenn ein Supervisor Kommitee Daten löscht die nicht den Kriterien entsprechen?

welchen kriterien?

lol... gibt es nicht?

g0ldfish wrote:

Hättest du stattdessen die (mutmaßlich kleinere) Gegenmenge mit denotation = landmark, fixme = verify denotation o.ä. bedacht, wäre das vielleicht weniger kritisiert worden (vielleicht auch nicht), vor allem aber wäre es deutlich zukunftssicherer gewesen, weil nicht andauernd neu hinzukommende (unbedeutende) Bäume nachbearbeitet werden müssten.

Das ist ein Denkfehler.

Bei frischen Müllimporten weißt Du sicher, daß diese Bäume unzureichend getaggt und nicht relevant sind und kannst ohne Fehlerquote alle richtig markieren. Der Wien-Import ließe sich ohne Probleme oder Fehler korrigieren - aber nach den Mechanical Edit Regeln darf das nur der Autor und der tut's anscheinend nicht.

Die Bestandsbäume dürften großteils so gemeint sein, sicher wissen kannst Du es aber nicht. Das heißt Du hättest eine Fehlerquote und eine endlose Diskussion darum wie hoch diese Fehlerquote wohl ist.

Die Variante ohne Fehlerquote ist IMHO immer besser.

bye, Nop

Nop wrote:

g0ldfish wrote:

Hättest du stattdessen die (mutmaßlich kleinere) Gegenmenge mit denotation = landmark, fixme = verify denotation o.ä. bedacht, wäre das vielleicht weniger kritisiert worden (vielleicht auch nicht), vor allem aber wäre es deutlich zukunftssicherer gewesen, weil nicht andauernd neu hinzukommende (unbedeutende) Bäume nachbearbeitet werden müssten.

Das ist ein Denkfehler.

Bei frischen Müllimporten weißt Du sicher, daß diese Bäume unzureichend getaggt und nicht relevant sind und kannst ohne Fehlerquote alle richtig markieren.

Der Denkfehler liegt bei dir: Du liest "neu hinzukommende (unbedeutende) Bäume" und denkst an Importe.

Nur was bringt es, bei importierten Bäumen einen 100% korrekten Massenedit durchzuführen, wenn inzwischen auch bei den von Hand eingetragenen natural=tree ohne Zusatztags die Mehrzahl "normale" Bäume sein werden? Eine Anwendung, die nur markante Bäume darstellen möchte, wäre zwar die Importe los, aber läge trotzdem noch bei den allermeisten angezeigten Bäumen falsch.

Die einzige nachhaltige Lösung besteht darin, dass möglichst viele Mapper gerade an Bäume, über die es mehr zu sagen gibt, Zusatztags mit den entsprechenden Infos hängen. Denn nur dann ist die Situation unmissverständlich klar.

Und genau diese Tatsache - dass mit natural=tree eben gerade bei markanten Bäumen noch nicht alles gesagt ist, sondern der Eintrag erst mit Zusatztags für viele Anwendungen überhaupt brauchbar wird - sollte die Dokumentation im Wiki auch vermitteln. So zu tun, als sei mit dem bloßen natural=tree ein Baum bereits als "besonderes" Exemplar gekennzeichnet, ist absolut kontraproduktiv.

Tordanik wrote:

Die einzige nachhaltige Lösung besteht darin, dass möglichst viele Mapper gerade an Bäume, über die es mehr zu sagen gibt, Zusatztags mit den entsprechenden Infos hängen. Denn nur dann ist die Situation unmissverständlich klar.

Und genau diese Tatsache - dass mit natural=tree eben gerade bei markanten Bäumen noch nicht alles gesagt ist, sondern der Eintrag erst mit Zusatztags für viele Anwendungen überhaupt brauchbar wird - sollte die Dokumentation im Wiki auch vermitteln. So zu tun, als sei mit dem bloßen natural=tree ein Baum bereits als "besonderes" Exemplar gekennzeichnet, ist absolut kontraproduktiv.

Wo die Gewichtung liegt können wir endlos diskutieren. Derzeit hat keiner aktuelle Auswertungen um seine Behauptung zu belegen.

Sicher vernünftig auswerten kann man es nur noch mit einem Zusatztag, das nach Aussagen von einigen anderen hier in dem Tag auch von ihnen praktiziert wird. Also könnte man einfach das Tag immer passend setzen und sämtliche Probleme erledigen.

Oder wir diskutieren das aus, sobald wir einen Consens über das Tagging von Radwegen gefunden haben. :-)

bye
Nop

Basstoelpel wrote:

An diejenigen, die hier das Importieren der Bäume befürworten: Wie sollen die Daten aktuell gehalten werden? Insbesondere, wie werden wir die Bäume wieder los, die im nächsten Baumkataster nicht mehr vorhanden sind, weil sie der Kettensäge oder dem fleißigen Biber zum Opfer gefallen sind?

Diff alter/neuer Stand Baumkataster, im diff auftauchende Bäume löschen?

Atalantia wrote:

Jayjay01 wrote:

Atalantia wrote:

Das scheint ein grösseres Ding zu sein. Ich bin noch nicht so Expert in OSM aber ich weiss aus anderen Projekten, das "saubere" Datensätze eine unbedingte Voraussetzung sind um relevante Daten wiederzufinden. Es wäre vielleicht wünschenswert, wenn ein Supervisor Kommitee Daten löscht die nicht den Kriterien entsprechen?

welchen kriterien?

lol... gibt es nicht?

Welche Kriterien gibt es nicht?

Nop wrote:

Bei frischen Müllimporten weißt Du sicher, daß diese Bäume unzureichend getaggt und nicht relevant sind und kannst ohne Fehlerquote alle richtig markieren. Der Wien-Import ließe sich ohne Probleme oder Fehler korrigieren - aber nach den Mechanical Edit Regeln darf das nur der Autor und der tut's anscheinend nicht.

Der Wien-Import war wie gesagt in der AT-Mailingliste abgesprochen, und nebenbei gesagt beim Wien-Stammtisch auch, und alle in AT sind vom Ergebnis begeistert. Mir kommt vor, dass in manche Leute in DE grün vor Neid werden und nun reagieren wie der Fuchs in der Fabel mit den Weintrauben.

denotation=* ist ein Fehlkonzept, das offenbar von konventionellen Karten abgeschaut wurde. Dort sind mitunter Bildbäume u.dgl. eingezeichnet. Für andere Bäume ist in diesen Karten weder Platz, noch gibt es die Ressourcen um sie aktuell zu halten. Das ist auf OSM alles nicht umlegbar, wir haben genug Ressourcen und die Möglichkeit zu Imports, die es damals noch nicht gab, und ob Platz in der Karte ist, das entscheiden die Renderer. Wir haben nicht nur 1 Karte für 1 bestimmten Abwendungszweck, sondern eine Datenbank für unendlich viele mögliche Karten, für unendlich viele mögliche Zwecke. Darum ist es sinnlos, von "signifikanten" oder "nicht signifikanten" Bäumen zu sprechen. Was signifikant ist, ist subjektiv und hängt vom Anwendungszweck ab. Für die Frau Krämer sind vielleicht genau jene Bäume signifikant, die im Umkreis von 100m von ihrem Haus stehen. Und der Herr Müller ist ein Schleckermaul, für den sind alle Obstbäume signifikant. Alle anderen löscht er aus OSM raus, weil im Wiki steht, dass nur signifikante Bäume gemappt gehören.

Schauen wir uns mal die Werte von denotation=* an:

denotation=urban oder cluster sind sinnlos, weil sie genau null Information enthalten.

denotation=avenue ergibt sich automatisch daraus, dass die Bäume neben einer Straße stehen.

denotation=natural_monument ist nur für Bäume dokumentiert, doch zu Naturdenkmälern zählen auch Höhlen, Felsrippen, Wiesen... Sollen wir auf die dann ebenfalls denotation=natural_monument setzen? Und wenn eine Höhle kein Naturdenkmal ist, taggen wir sie dann mit denotation=urban?

denotation=landmark ist subjektiv. Ist ein Baum eine Landmarke, wenn im Umkreis von 50m kein anderer Baum steht, oder genügt es, wenn die anderen Bäume niedriger sind, oder soll die Distanz 100m sein, oder 83,7m? Muss der Baum auf einer Anhöhe stehen?

Fazit: Wenn wir die Eigenschaften von Bäumen und ihre Umgebung genau genug mappen, können Anwendungen selber ermitteln, welche Bäume für sie signifikant sind. Das Tag denotation=* gehört früher oder später deprecated.

Und wie soll man einen als Naturdenkmal ausgezeichneten Baum oder einen Bildbaum kennzeichnen?

na mit denotation=*

ein baum sollte ein baum bleiben, auch wenn es mal anders gedacht war.
signifikante bäume erhalten einen zusatztag, da es bestimmt 2-3 weniger sind als die anderen........

grüße von lutz

fkv wrote:

Der Wien-Import war wie gesagt in der AT-Mailingliste abgesprochen, und nebenbei gesagt beim Wien-Stammtisch auch, und alle in AT sind vom Ergebnis begeistert. Mir kommt vor, dass in manche Leute in DE grün vor Neid werden und nun reagieren wie der Fuchs in der Fabel mit den Weintrauben.

Neid? Es geht darum wie man den ganzen Müll wieder los wird. :-)

fkv wrote:

denotation=* ist ein Fehlkonzept, das offenbar von konventionellen Karten abgeschaut wurde. Dort sind mitunter Bildbäume u.dgl. eingezeichnet. Für andere Bäume ist in diesen Karten weder Platz, noch gibt es die Ressourcen um sie aktuell zu halten. Das ist auf OSM alles nicht umlegbar, wir haben genug Ressourcen und die Möglichkeit zu Imports, die es damals noch nicht gab, und ob Platz in der Karte ist, das entscheiden die Renderer. Wir haben nicht nur 1 Karte für 1 bestimmten Abwendungszweck, sondern eine Datenbank für unendlich viele mögliche Karten, für unendlich viele mögliche Zwecke. Darum ist es sinnlos, von "signifikanten" oder "nicht signifikanten" Bäumen zu sprechen. Was signifikant ist, ist subjektiv und hängt vom Anwendungszweck ab

Dann schau Dir mal die Legende einer beliebigen gedruckten Topokarte an. Wenn Du nicht verstehst was ein markanter Baum ist findest Du beim Landesvermessungsamt sicher eine schöne Definition für Dich.

Wenn eine amtliche Topokarte für Dich ein Fehlkonzept ist...

fkv wrote:

denotation=avenue ergibt sich automatisch daraus, dass die Bäume neben einer Straße stehen.

Es ist also auch unnötig, maxspeed oder one-way zu taggen, wenn die Verkehrsschilder neben der Straße eingetragen sind?

Es ist auch nicht nötig, Adreßinformationen zu taggen, die POIs liegen an an einer Straße und in einem Stadt-Poly?

Erklär mir bitte mal wie eine Renderregel für eine beliebige gängige OSM Software aussieht mit der man sowas auswählen kann.

fkv wrote:

denotation=landmark ist subjektiv. Ist ein Baum eine Landmarke, wenn im Umkreis von 50m kein anderer Baum steht, oder genügt es, wenn die anderen Bäume niedriger sind, oder soll die Distanz 100m sein, oder 83,7m? Muss der Baum auf einer Anhöhe stehen?

Genauso subjektiv wie highway=secondary vs. tertiary vs. unclassified.

Die Mapper die das Tag benutzen haben anscheinend genug gesunden Menschenverstand daß es dazu meines Wissens noch nie eine Diskussion gab. :-)

fkv wrote:

Fazit: Wenn wir die Eigenschaften von Bäumen und ihre Umgebung genau genug mappen, können Anwendungen selber ermitteln, welche Bäume für sie signifikant sind. Das Tag denotation=* gehört früher oder später deprecated.

Wie gesagt: Technisch sind alle Deine Vorschläge völlig unmöglich. Sämtliche Renderer stützen sich auf das Tagging.

Ich glaube Du bist nur deshalb davon überzeugt daß das alles ganz einfach ist weil Du noch nie eine Renderregel geschrieben hast und nicht weißt wovon Du redest.

bye, Nop

Leute, bitte mäßigt euch!

Das sind alte Kamellen. Das Kind ist in den Brunnen gefallen und wahrscheinlich wird niemand das jemals wieder zurücksetzen können oder wollen. Also bitte Schluss mit einer Debatte, die keine Änderungen ergeben wird.

Ob die Änderung, so wie gemacht wurden, sinnvoll waren, mag jeder für sich entscheiden. Ändern tut das jedoch nichts.
Heute - nach den Erfahrungen mit dem Redaction-Bot - würde so ein Massen-Edit wahrscheinlich von der DWG wieder zurückgesetzt werden. Die Maßstäbe sind mittlerweile etwas strenger geworden.

Edbert (EvanE)

malenki wrote:

Basstoelpel wrote:

... Wie sollen die Daten aktuell gehalten werden? ...

Diff alter/neuer Stand Baumkataster, im diff auftauchende Bäume löschen?

Hast Du mal ein Beispiel eines Imports, bei dem das auch tatsächlich gemacht wurde? Mir wollen gerade nur Importe einfallen, wo die Daten einmalig in OSM gekippt wurden, und dann durften die Mapper sehen, ob und wie sie die Daten (teilweise muß man sagen: den Plunder) aktuell halten (ausgenommen möglicherweise Seezeichen u.ä., da scheint eine regelmäßige Wartung stattzufinden).
Die technische Möglichkeit - gerade bei einfachen Punktobjekten wie Bäumen - möchte ich gar nicht bestreiten, aber aller bisherigen Erfahrung nach haben Importeure wenig Interesse an der anschließenden Pflege "ihrer" Daten. Da kann ich den Wienern nur wünschen (ohne Ironie und den oben unterstellten Neid), daß ihr Baumimporteur eine Ausnahme von dieser Regel bildet.

Sehr richtige und wichtige Hinweise, danke Oli-Wan.
Die Sache ist mit Sicherheit vergessen, also zur Erinnerung: vor 2 Jahren initiierte ich in Polen die Gründung einer "OpenStreetMap Polska e.V.". Ich bin nun zwar weiterhin in dem Verein, aber die Arbeit machen die Leute vor-Ort. Einer der Gründe war damals die Stärkung der Koperation zwische einzelnen Mitglieder ( ähnlich wie es in der BRD regional durch die Stammtische geschieht). Da das Land bei Weitem nicht die Mapperdichte hat wie wie´s in der BRD haben, ging es auch darum, besser die Mapping Aktionen zu koordinieren und bei Vorträgen als "Organisation" aufzutreten. Jedes Land hat Etwas Spezifisches und in Osteuropa ist es: Hat man einen Ausweis, wird man ernster genommen.

Ich habe allerdings nicht gedacht, dass uns dieses Verein so viele Türen öffnet. So gab es beispielsweise mehrere Städte die, ähnlich wie München es vor hat, der Community diverse Daten zur Verfügung gestellt haben. Da alle solche Importe und deren Umfang notiert werden und über die Vorstandsmitglieder des Vereins laufen, kann man davon ausgehen, dass die Daten upgedatet werden.

Dein Hinweis Oli-Wan, werde ich weiterleiten, damit die Sache nicht in Vergessenheit gerät.

Wolfgang B wrote:

Und wie soll man einen als Naturdenkmal ausgezeichneten Baum oder einen Bildbaum kennzeichnen?

Bildbaum ist natural=tree + historic=wayside_shrine (bzw. wayside_cross).
Für Naturdenkmäler sollten wir eine Lösung finden, die nicht nur auf Bäume, sondern auch auf andere Naturdenkmäler anwendbar ist. Sowas wie natural_monument=yes. Es gibt boundary=protected_area + protect_class=3, aber das passt nicht so richtig auf Naturdenkmäler, denn wie soll man zu einem Baum oder einem Höhleneingang eine Grenze (boundary) zeichnen?

Nop wrote:

fkv wrote:

denotation=* ist ein Fehlkonzept, das offenbar von konventionellen Karten abgeschaut wurde. Dort sind mitunter Bildbäume u.dgl. eingezeichnet. Für andere Bäume ist in diesen Karten weder Platz, noch gibt es die Ressourcen um sie aktuell zu halten. Das ist auf OSM alles nicht umlegbar, wir haben genug Ressourcen und die Möglichkeit zu Imports, die es damals noch nicht gab, und ob Platz in der Karte ist, das entscheiden die Renderer. Wir haben nicht nur 1 Karte für 1 bestimmten Abwendungszweck, sondern eine Datenbank für unendlich viele mögliche Karten, für unendlich viele mögliche Zwecke. Darum ist es sinnlos, von "signifikanten" oder "nicht signifikanten" Bäumen zu sprechen. Was signifikant ist, ist subjektiv und hängt vom Anwendungszweck ab

Dann schau Dir mal die Legende einer beliebigen gedruckten Topokarte an. Wenn Du nicht verstehst was ein markanter Baum ist findest Du beim Landesvermessungsamt sicher eine schöne Definition für Dich.

Lies meinen Absatz nochmal, ich will mich nicht wiederholen.

Wenn eine amtliche Topokarte für Dich ein Fehlkonzept ist...

Das habe ich nicht geschrieben. Weiß nicht, wie du auf so was kommst.

fkv wrote:

denotation=avenue ergibt sich automatisch daraus, dass die Bäume neben einer Straße stehen.

Es ist also auch unnötig, maxspeed oder one-way zu taggen, wenn die Verkehrsschilder neben der Straße eingetragen sind?

Aus Verkehrsschild-Nodes ergibt sich nicht, von wo bis wo sie gelten.

Es ist auch nicht nötig, Adreßinformationen zu taggen, die POIs liegen an an einer Straße und in einem Stadt-Poly?

addr:street muss explizit getaggt werden, weil es nicht immer die näheste Straße ist, bzw. es gibt Adressen ganz ohne Straße. addr:postcode ist hingegen überflüssig, wenn es sich aus einem PLZ-Polygon ergibt.

Erklär mir bitte mal wie eine Renderregel für eine beliebige gängige OSM Software aussieht mit der man sowas auswählen kann.

Preprocessing ist das Zauberwort. Erst muss der Datenbestand aufbereitet werden, bevor Rendering sinnvoll möglich ist.

fkv wrote:

denotation=landmark ist subjektiv. Ist ein Baum eine Landmarke, wenn im Umkreis von 50m kein anderer Baum steht, oder genügt es, wenn die anderen Bäume niedriger sind, oder soll die Distanz 100m sein, oder 83,7m? Muss der Baum auf einer Anhöhe stehen?

Genauso subjektiv wie highway=secondary vs. tertiary vs. unclassified.

Die Mapper die das Tag benutzen haben anscheinend genug gesunden Menschenverstand daß es dazu meines Wissens noch nie eine Diskussion gab. :-)

Bei highway=* gibt es genug Diskussionen, bis hin zu Editwars. Darum wird in den meisten Ländern versucht, halbwegs klare Definitionen zu finden, z.B. trunk...Autostraße, primary...Bundesstraße, seconday...Landeshauptstraße usw.

Wie gesagt: Technisch sind alle Deine Vorschläge völlig unmöglich. Sämtliche Renderer stützen sich auf das Tagging.

Wir taggen nicht für die Renderer. Technisch ist das alles problemlos möglich, es hat sich nur noch keiner dazu bequemt es umzusetzen.

fkv wrote:

Wie gesagt: Technisch sind alle Deine Vorschläge völlig unmöglich. Sämtliche Renderer stützen sich auf das Tagging.

Wir taggen nicht für die Renderer. Technisch ist das alles problemlos möglich, es hat sich nur noch keiner dazu bequemt es umzusetzen.

Ich wiederhole nochmal: Du dokumentierst hier nur Deine völlige Ignoranz wie die Techniken funktionieren. Es ist natürlich alles ganz einfach solange man sich nur hinstellt und es von anderen Leuten fordert.

Wenn das so problemlos ist: Poste eine Renderregel "ist ein Alleebaum" für mkgmap, dann reden wir weiter.

bye, Nop

Moin

Und wieder mal: Bäume sind kein Mist, sie sind da uns sollten getaggt werden, auswerten ist eine andere Sache. Und zwar ALLE Bäume. Besondere Bäume werden halt extra getaggt.
Wir mappen ja auch alle Straßen, alle Häuser, alle Adressen, alles, was UNS interessiert, oder?
Oder nur weil plötzlich viele Bäume EINE Karte kaputt macht, sollen die raus?
Wie sieht das mit den Radwegen aus, den Häusern, den Wanderwegen?

Realität ist da draussen, die sollte in die Datenbank rein, und wenns die Blumenbeete vor den Häusern sind, die sind da und gehören in die Datenbank.
Nicht jede Karte muß diese anzeigen.
Oder mappen wir jetzt doch für die renderer/spezialkarten?

Amiga4000

Nop wrote:

Wenn das so problemlos ist: Poste eine Renderregel "ist ein Alleebaum" für mkgmap, dann reden wir weiter.

Willst du in deiner Wanderreitkarte allen ernstes Alleebäume darstellen? Mach lieber Renderregeln für Bildbäume und Naturdenkmal-Bäume, das geht ohne Preprocessing, und von mir aus unterstütze ich dich dann bei den Regeln und den Icons. So was ähnliches hab ich dir schon mal angeboten, dann kam keine Antwort...