Moin,
für ein Projekt im Umweltschutz geht es darum, das Bürger sogenannte Baumscheiben eintragen.
Siehe auch: http://de.wikipedia.org/wiki/Baumscheibe
Die daraus ableitbare Karte soll dann als Grundlage für weitere Aktionen dienen.
Ich habe dazu in YAPIS jetzt als Key/Value-Kombination vorgesehen:
man_made:tree_grate
Ist das wohl die richtige Wahl? Dazu würde ich auch gern eine Seite im Wiki anlegen, entweder zur Diskussion (Proposal?) oder wie auch immer. Was ist da zu tun?
LG,
-moenk
Der Artikel macht das für mich nicht wirklich klarer - vermutlich willst du nicht Baumscheiben, sondern Baumscheibenabdeckungen eintragen?
Es wäre doch sinnvoll, das zu einem Zusatzattribut des Baums zu machen, ansonsten hat man ja den Knoten für die Baumscheibe und den für den Baum direkt übereinander. Dann wäre eher so was wie tree_grate=yes als weiteres Tag am Baum-Knoten naheliegend.
Oder geht es speziell um “leere” Baumscheibenabdeckungen?
Am besten erst mal eine Proposal-Seite zur vorläufigen Dokumentation anlegen, z.B unter “Proposed features/Tree grate” oder so. Mehr als das übliche Info-Kästchen, eine kurze Erklärung und ein Bild (man kann z.B. das aus Wikipedia direkt einbinden, ohne es im OSM-Wiki extra neu hochladen zu müssen) ist gar nicht nötig. Das kann z.B. so ähnlich aussehen.
Abstimmung braucht man für so etwas meiner Meinung nach eher nicht, aber es mal international zu diskutieren fände ich sinnvoll.
Wenn es sich dann später mal etabliert hat, kannst du das Attribut dann auf den Tag:/Key:-Seiten dokumentieren.
Tordanik,
es geht um leere Plätze für Bäume, also um diese Abdeckung, die aber auch Baumscheibe genannt wird (find ich auch etwas verwirrend). Man soll das mappen können, auch ohne dass ein Baum da ist, wenn denn einer gepflanzt wurde soll man um natural=tree ergänzen können.
Also kein Zusatzattribut für einen Baum, sondern das Bauwerk, dass es viel zu oft ohne Baum gibt, weil die Stadt aus Gründen die hier offtopic werden da keinen gepflanzt hat.
Da ich per Mail gefragt wurde: Es ist kein Schreibfehler, es muss tree_grate heißen, siehe z.B. hier: http://www.google.de/search?q=tree+grate - allerdings natürlich mit Gleichheitszeichen und nicht mit Doppelpunkt, also man_made:tree_grate - und Bürger sollen eintragen, wo in Berlin ein Baum fehlt. Damit kann man dann der Stadt etwas auf die Füße treten.
LG,
-moenk
Ist es dafür überhaupt notwendig, alle Baumscheiben in OSM zu mappen? Wäre da nicht vielleicht eine Plattform in Anlehnung an OSMBugs oder Mapdust besser geeignet?
Hallo -moenk,
bei Apps4Deutschland wurde im Berliner Sonderwettbeweb die Idee einer Baumkataster-App prämiert. In der Berliner Open Data-Strategie wird auf Seite 39 auch das Baumkataster als Beispiel erwähnt. Im Gegensatz zu Bremen gibt es in Berlin einige nette Behördenmitarbeiter, die für innovative Ideen Interesse zeigen und mitmachen. Vielleicht wären da Ansatzpunkte gegeben.
Bei SenStadtU und den untergeordneten Behörden ist eigentlich alles an (Hilfs-)Geoaten vorhanden, um die leeren Abdeckungen mit Submetergenauigkeit erfassen zu können. Bei einer solchen Genauigkeit wären die Daten sehr wertvoll und könnten für alles (auch OSM) verwendet werden.
Grüße
Joachim
Ich denke, dass der Schlüssel im man_made gut aufgehoben ist.
@Tordanik: logisch sollte der an den gleichen Node getaggt werden, an dem auch der Baum getaggt ist/wird. Das verhindert doch aber nicht, dass der Tagg man_made=tree_grate ist, oder?
Ich finde es konzeptionell unschön, wenn ein Node mehr als ein “Haupt-Tag” (also Tag mit Schlüssel wie eben natural oder man_made) hat. Mit einem man_made-Tag “ist” der Node dann eben sowohl ein Baum als auch eine Baumscheibenabdeckung, und es ist unklar, auf was sich die sonstigen Eigenschaften des Nodes beziehen. Im Allgemeinen sollte man so was vermeiden.
In diesem Fall hier funktioniert es wahrscheinlich sogar, weil bei keiner naheliegenden Eigenschaft unklar ist, wozu sie gehört (material wäre wohl eher die Abdeckung, height eher der Baum etc.). Und wenn man es auch ohne Baum verwenden möchte, dann passt das schon mit man_made.
Das sollte man sich aber wirklich überlegen. In OSM macht es nur Sinn, wenn es auch noch von anderen Anwendungen genutzt wird. Wenn es nur um das eine Projekt geht, der Stadt die Liste der leeren Baumscheiben unter die Nase zu halten, dann ist eine OSMBugs-artige Lösung wesentlich naheliegender.
Und ehrlich gesagt fallen mir momentan wenig andere Anwendungsfälle ein. Ich meine, man könnte es im 3D-Rendering anzeigen. Aber das bringt nur dann überhaupt etwas, wenn die Positionierung sehr exakt ist - denn wenn die Abdeckung vom Gehsteig dann in der Straßenmitte landet, hätte man sie besser gar nicht gerendert. Und da hier Bürger ohne OSM-Erfahrung einbezogen werden sollen, dann würde ich nicht mit einer so genauen Arbeit rechnen.
Durchmesser wäre ein Beispiel, das für beides verwendet werden könnte.
Gut…aber wo ist da jetzt der Unterschied zu der Variante mit dem “Nebentagg”? Beim angesprochenen Durchmesser weiß man immer noch nicht, welcher wofür gilt (wenn man mal außer acht lässt, dass der Baum wohl den kleineren haben sollte 
).
+1
Es handelt sich hier um ein lokales Projekt, dass mit YAPIS realisiert werden soll. Sorry, aber solche Daten haben mit Verlaub nichts in OSM zu suchen. Eine externe Tabelle/DB reicht hier völlig aus - gerade unter dem Aspekt, dass die hierfür vorgesehene Anwendung keinerlei Probleme haben dürfte, diese externen Daten zu pflegen.
Gruss
Walter
Walter,
das sind verschiedene Dinge: YAPIS ist ein einfaches Tool, mit dem Geocacher ein paar POI eintragen sollen. Ich nahm an, dies sei für die OSM erwünscht. Letztlich ist es auch ein einfacher Einstieg in das Thema POI mappen.
Die Baumscheiben soll man damit sicher auch eintragen können, vor allem soll es aber egal sein, wie man sie einträgt. Es wird da sicher Aktivisten geben, die das mit JOSM oder Potlatch machen wollen, das hat mit YAPIS erst mal nichts zu tun.
Ich hatte mich ohnehin gewundert, was bei der OSM so alles eingetragen wird: Bäume, Stolpersteine, da hat wohl jeder so sein Steckenpferd. Daher auch die Frage nach dem organisatorischen Ablauf: Irgendwie wir ja basisdemokratisch über solche Ansinnen entschieden. Vielleicht mag mir da mal jemand unter die Arme greifen und so einen RFC/Proposal auf den Weg bringen, das hab ich in dem Wiki nicht so ganz verstanden.
Muss das auf englisch gemacht werden, damit die OSMF darüber mit befinden kann? Oder auf deutsch, damit das neue Key/Value-Pair hier erst mal etabliert werden kann? Letztlich soll es ein Tag sein, das zu einem Baum oder ohne einen Baum gesetzt werden kann. Nicht nur von dem BUND-Aktivisten, auch nicht nur in Berlin, sondern von jedem der es sinnvoll findet, Stellen zu markieren wo ein Baum hingehört.
Natürlich kann man da eine eigene Datenbank aufbauen! So hab ich das aber nicht verstanden, dass man auf Basis der OSM eigene Bestände aufbauen soll. Da freue ich mich auf einen angeregten Diskurs an dieser Stelle.
LG,
-moenk
Wieso nicht einfach 2 Varianten?
man_made:tree_grate
ohne Baum
und
natural:tree
|-tree_grate:yes
mit Baum
Bei der geringen Zahl an Anwendungen die darauf zurückgreifen, ein verkraftbarer Mehraufwand. Ich muss Tordanik einfach rechtgeben, 2 Haupt-Tags sind unschön und werden oft nicht ausgewertet.
Ok, wenn dem so so sein soll, ist eine “eigene” Zusatz-DB/Tabelle natürlich nicht machbar. (*)
Bei dem “ein paar POI eintragen” habt ihr sicher die Diskussion mit Wheelmap verfolgt und auf die kleinen aber feinen Tücken geachtet?
Proposals sind “out”. Es hat sich herausgestellt, dass es nichts bringt, wenn weltweit ca 15 Leute einer Meinung sind und dann was beschliessen, was für den Rest nahezu verbindlich sein soll. Spar dir das.
Knifflig: Baum mit Baumscheibe wäre ein Zusatztag zum Baum - Baumscheibe ohne Baum muss ein autarker Tag sein. Also kommt nur der zweite Weg in Frage (xxx=yes ?)
Gruss
Walter
*) Inzwischen kann Josm auch mittels eines Plugins Daten in einer externen Datenbank/Tabelle ablegen: http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html , Potlatch und Merkaator aber nicht. Daher ist hier eine universielle Lösung nicht möglich.
Jimmy,
das ist sehr interessant: Ich war davon ausgegangen dass man gut zwei K/V-Pairs in einem Objekt kombinieren kann. Für die Idee würde die erste Variante reichen, die würde ich dann auch in YAPIS zu den knapp 250 anderen Vorgaben ergänzen.
Vor allem müsste aber eine Seite im Wiki her, wo diese Idee nachlesbar ist. Das eilt noch nicht so sehr, die Idee wird zur langen Nacht der Wissenschaften in Adlershof erst im Juni vorgestellt. Wenn OSM wieder online ist kann ich ja mal einen Beispieleintrag machen von so einem Platz wo ein Baum stehen sollte.
Ich kann mir vorstellen dass das Projekt der OSM eher förderlich als schädlich ist, wenn man sich den aktuellen Stand anguckt: http://www.baeume-fuer-berlin.de/?idcatside=71
LG,
-moenk
Ich weiß ja nicht, was du unter basisdemokrtisch verstehst, aber die Proposals sind es nicht wirklich. Wenn 50 Leute abstimmen ist das schon viel. Zum vergleich, täglich editieren ~2000 Mapper. Gut man könnte sagen, die anderen interessiert es nicht. Aber wenn ein Thema nur ~50 Leute interessiert und davon noch einige dagegen sind, die Daten zu erfassen, dann sollte man sich schon fragen, ob das ganze etwas für OSM ist. Denn letztlich setzt sich ohnehin das durch, was verwendet wird, also in der Datenbank vorhanden ist.
OSM ist ein internationales Projekt mit der Sprache englisch. Wenn man über Neues mit der gesamten Community sprechen will, dann sollte man dies auf englisch tun. Proposals sind für die gesamte Community interessant, von daher englisch.
Als Mapper sollte man sich die Frage stellen: Nutzt diese Info irgendjemanden, oder trage ich es nur ein, weil die Info da ist. OSM sollte nicht zur Datenmüllhalde verkommen, weil die ABM/das Projekt zu bequem ist, einen eigenen Server aufzusetzen. Das soll nicht heißen, dass das bei diesem Projekt so ist. Man sollte es als Mapper nur immer hinterfragen.
OSM nützt es bspw. nicht sonderlich viel, wenn diese Infos jetzt in einer einmaligen Aktion gemappt werden und dann kümmert sich keiner mehr um das Aktualisieren der Daten.
Da wundere ich mich auch immer wieder. 
Jeder der es sinnvoll findet? 
Um Stellen für eventuelle Baumstandorte/-pflanzungen festzulegen, gehört schon ein wenig Wissen über die Funktion der Verkehrsanlage an der ausgewählten Stelle, über den Zustand des unterirdischen Bauraums u. dgl. dazu. Dieses Wissen kann logischerweise nicht jeder haben. Ich befürchte, dass es unzählige (willkürliche) Eintragungen und somit Daten gibt, die keiner prüft und pflegt.
Die Festlegung dieser Stellen ist Aufgabe der Ämter, Behörden und Verbände. Und diese haben i. d. R. ihre Informationen dazu. Und wie schnell ein Baum an einer möglichen Stelle (nach)gepflanzt wird, wird sicherlich nicht von OSM beeinflusst.
+1
Wir erfassen, was ist und nicht ,was sein sollte.
Michael, Torsten,
völlig richtig, es soll nur erfasst werden was es schon gibt. Sorry wenn das etwas missverständlich war. Also nicht wo nach Meinung eines Bürgers ein Baum hingehört, sondern wo die Planung baulich schon einen vorgesehen hat und der immer noch fehlt. Also wo das “man_made=tree_grate” schon in der Gegend steht und nur noch die Natur (“nature=tree”) darin fehlt. Dabei wird nicht die Tatsache an sich gemappt, dass es fehlt, sondern das ist implizit ableitbar, wenn es ein Tag für eine Baumscheibe und keines für einen Baum gibt.
LG,
-moenk
Wenn man sowas schon taggen will, kann man auch darüber nachdenken, das Ganze etwas allgemeiner fassen:
Bsp.: Baumsicherheit=Pflöcke, Metallbügel, Abdeckplatten, Stammschutzgitter, Stammschutzzaun, Baum_steht_im_(erhöhten)_Blumenbeet
(oder so ähnlich & natürlich auf englisch)
Angelehnt an den Wikipedia eintrag:
[Um Schaden zu verhindern] werden Pflöcke, Metallbügel oder Abdeckplatten […] angebracht.
Moin alle,
ich erlaube mir auf diesen Flyer hinzuweisen und das Interesse auf Seite 20 zu richten:
http://www.adlershof.de/fileadmin/web/news-termine/lndw/2012/Programmheft_Lange_Nacht_der_Wissenschaften_2012_Adlershof.pdf
Vielleicht gibt es ja noch Freiwillige, die zum Thema OpenStreetMap mit am Stand stehen möchten?
LG,
-moenk