Handelt es sich nicht eher stattdessen um eine Bushaltestelle? bench=yes und bin=yes halte ich in sofern für in Ordnung, als dass diese Teil der Bushaltestelle sind. Einen Fahrradständer würde ich nicht als Teil einer Bushaltestelle verstehen, auch wenn diese begrüßenswerterweise vermehrt in der Nähe von Bushaltestellen aufgestellt werden.
Wie würdest du denn nun weitere Eigenschaften des Fahrradständers erfassen, wie beispielsweise covered=* und capacity=*? Diese Tags können ja schlecht exakt so auch noch an der Bushaltestelle angebracht werden, da dann nicht mehr klar ist, worauf sie sich beziehen. Also wäre ein Präfix notwendig, beispielsweise bicycle_parking:covered=* und bicycle_parking:capacity=*. Ist das dann auch automatisch Teil der “vorhandenen Logik” oder sollte das nicht doch besser explizit dokumentiert werden? Wo hört das Implizite auf, wo fängt das Explizite an?
Edit: Irgendwie sind wir mittlerweile schon sehr weit vom Thema abgekommen Sollte man diese Diskussion besser in einem eigenen Thread fortführen?
bicycle_parking bezieht sich auf eine Fahrradabstellanlage und nicht auf einen Birnbaum, das war die Intention meiner Aussage…
Das kommt auf die konkrete Situation vor Ort an, wenn das Verkehrsunternehmen direkt an die Haltestelle eine Fahrradabstellanlage baut oder gar in diese integriert, dann halte ich das schon für sinnvoll.
Na, so wie beispielsweise bei “bench” auch, an das entsprechend getrennt erfasste amenity.
Dann sind diese Daten doch aber doppelt erfasst. Einmal als Teil der Bushaltestelle, und dann nochmal als separates Element. Das empfände ich als sehr unglücklich.
Das wurde auch im alten Forum ausführlich diskutiert.
Das eine sagt, dass es eine Sitzbank gibt, das andere, wo sich diese genau befindet, mit entsprechenden Eigenschaften. Analog zu lit=yes an Straßen und Plätzen, da werden die Laternen auch zusätzlich einzeln erfasst.
Hintergrund war, dass sonst nicht bestimmbar ist, ob z.B. eine Sitzbank zu einer Bushaltestelle gehört. Über die räumliche Nähe funktioniert die Zuordnung nämlich nicht. Zwischen der Bank und der Bushaltestelle kann beispielsweise ein Hindernis, wie z.B. ein Geländer, eine Mauer, ein Abhang oder sonstiges sein, selbst dann wenn sich die beiden Objekte direkt beieinander befinden. Um das alles zwecks Zuordnung abzubilden bedürfte es dann schon einer sehr detailliert Abbildung der Realität, also extremes Micromapping und selbst dann ist ungewiss, ob diese Zuordnung durch Algorithmen sicher durchgeführt werden kann. Monsterrelationen waren wohl auch nicht so beliebt. Alles weitere dazu ist im alten Forum zu finden.
Ich halte es aber nicht für sinnvoll hier jede alte Diskussion “aufzuwärmen”, auch wenn der Titel dazu verleitet hier eine Sammlung mit “aufgewärmten” Diskussionen zu erstellen.
Das ist im Prinzip natürlich richtig, es bringt aber nicht jedermann die notwendigen Kenntnisse mit, hier zielgerichtet tätig werden zu können. Wenn man als Neuling gerne effektiv mappen möchte und keine entsprechenden Vorkenntnisse mitbringt, muss man sich erst mal im Laufe einiger Wochen halbwegs in die Taggingschemata einarbeiten. Dazu gehört dann auch das Studium unzähliger Wikiseiten, die in ihren Aussagen nicht immer konsistent sind oder eindeutige Regeln enthalten.
Mit mappen, Wiki studieren und ggf. zwecks Weiterbildung im Forum mitlesen ist man, ein normales Arbeits- und Familienleben vorausgesetzt, eigentlich zeitmäßig schon am Limit angelangt. Als nächstes kommen die QA Tools dazu und dann möchte man vielleicht auch mal eine Overpass-Abfrage starten und wie entlockt man der TI am besten die gewünschten Informationen …?!? Für viele User sind das Selbstverständlichkeiten, aber für andere ist das alles Neuland, das man sich Step by Step erarbeiten muss.
Und wenn man dann wirklich so weit ist, dass man im Wiki in einer Auflistung eine fehlende Übersetzung auf die schnelle nachtragen will … denkste, da muss man erst mal Syntax und Handling studieren, wenn man sowas vorher noch nie gemacht hat … also noch eine weitere Baustelle eröffnen …?!?.. nee, irgendwann isses genug. Mir selber geht es genau so - ich würde gerne am Wiki mitarbeiten und parallel dazu auch noch fehlende Fotos und Beiträge auf den Wikimedia-Seiten beisteuern, aber da fehlen mir einfach ein paar Stunden am Tag, sorry, es kann nicht jeder alles machen.
Deswegen wäre das eine Supersache:
die OSM insgesamt wirklich etwas bringen würde … eine “Arbeitsgruppe Wiki” aus Usern, die so etwas gerne machen und denen auch eine gewisse Autorität eingeräumt wird (z.B. so ähnlich wie den Mods im Forum). Also erst öffentlich diskutieren, einen Konsens oder Kompromiss finden, dokumentieren. Das wäre für die vielen Mapper, die nicht die Zeit oder die Kompetenz haben, an der Dokumentation mitzuarbeiten, sicher eine große Hilfe und für jeden Neueinsteiger sowieso. Und es würde auch das “Aufwärmen” mehrfach diskutierter Themen in vielen Fällen überflüssig machen.
Die Editoren unterstützen Neulinge doch sehr, da muss sich eigentlich kaum jemand in das Wiki oder ins Forum einlesen. Ich verwende JOSM, das Standard-Preset bringt da schon enorm viele Taggingschemata mit. Über 99,99 % meiner Bearbeitungen hätte ich vornehmen können, ohne jemals ins Wiki oder das Forum sehen zu müssen.
Der durchschnittliche Mapper wird das vermutlich niemals brauchen. Bis auf den eingebauten Validator habe ich auch schon länger keine QA Tools mehr verwendet und Overpass-Abfragen sollten zum Mappen auch nicht notwendig sein.
Wer sich tief, über das Mappen hinaus, einarbeiten will, der benötigt dafür natürlich zusätzlich viel Zeit.
Da kann ich dir zustimmen, deshalb konzentriere ich mich eigentlich auch eher aufs Mappen. Bei mir liegen noch einige tausend Bilder, welche ich über den Winter abarbeiten will.
Sicherlich wäre das schön.
Es müssten sich aber Menschen finden, die bereit sind, diese Aufgabe zu übernehmen. Das sollten dann erfahrene Mapper sein. Wer das machen will, nur zu! Bitte nicht vergessen, dass das auch international koordiniert werden muss. Das dürfte schon eher anspruchsvoller werden.
Letztendlich fehlen uns überall Beitragende, beim Mappen, Wiki, Software, OSMF, Pressearbeit, …
Es gibt Fälle, wo es umständlich/nicht kurz und prägnant/uneindeutig wäre, einen anderen Schlüssel für einen Tag zu verwenden. Wenn man zum Beispiel erfassen will, daß der Pollen einen festen Durchmesser hat, um ihn von den „gedrechselten" Modellen hier in Berlin zu unterscheiden, dann benutze ich natürlich auch diameter=fixed, auch wenn es für konkrete Zahlenwerte definiert ist, die ich aber nicht habe.
Hallo,
um mal wieder was zum Thema zu sagen.
aus meiner Sicht ist OSM eine sehr dynamische Community. Mal ist das Thema wichtiger im eigene Leben, mal weniger wichtig. Alte Nutzer verlieren das Interesse, neue Nutzer werden auf uns Aufmerksam und wollen mitmachen.
Daher ist es essentiell, das wir unsere Ideen bzgl. wie etwas gelöst werden sollte auch im Wiki dokumentieren. Idealerweise auch in Englisch. So dass es auch global einheitlich genutzt werden kann.
Ebenso verändert sich die Welt, die wir mappen als auch die Tools, die wir zur Verfügung haben für das Erfassen und Auswerten.
Wenn ich mich so zurück erinnere an die Zeit, wo wir ohne Luftbilder unterwegs waren… Damals wurden quasi nur wesentliche Gebäude erfasst (wegen dem Aufwand) und building=yes war nur so ein Zusatztag, dem man der amenity=* mitgegeben hat. Als dann mit den Luftbildern die Objekte, die nur building=yes hatten, war das irgendwie “blöd” für die Auswertung und was vorher etabliert war, wurde entsprechend erweitert.
Sollte man diese Diskussion besser in einem eigenen Thread fortführen?
