Da hat der betreffende User die App aber definitiv falsch bedient. Ansonsten hätte diese keine notes, sondern ein cycleway:both=no ausgeworfen.
Und ich finde das mappen von cycleway:both=no definitiv nicht verwerflich, da das definitiv klarstellt, dass es hier keinen Radweg gibt. Damit wird ausgeschlossen, dass die Straße nicht einfach nur noch nicht gemappt wurde (was auch noch sehr oft vorkommt). Die Frage ist, wie sich die App verhält, wenn es einen benutzungspflichtigen straßenbegleitenden Radweg gibt. Dann wäre nämlich bicycle=use_sidepath angebracht. Wenn das dann da dran geklatscht wird, ohne dass der Radweg schon gemalt wurde, könnte das zu Falsch-Negativ-Fehlern kommen.
Für residental und alles da drunter ist die Info sicherlich nicht notwendig, da kann ich allerdings nicht sagen, wie sich die App hier verhält. Aber auch hier bin ich eig der Meinung, dass es besser ist, die Info zu haben, als dass es mögliche Lücken in der Abdeckung gibt.
Ich habe mich nur darauf bezogen, dass ich nicht weiß, ob die App bicycle=use_sidepath mappt.
Da die App offensichtlich bereits für einige oneway:bicycle=no verantwortlich ist, habe ich daraus geschlossen, dass es einen Button “Kein Radweg” gibt und der User daher keine Notes erstellen musste um das eintragen zu lassen.
Kann die Äpp eigentlich erkennen, ob eine Straße einen separat gemappten begleitenden Radweg hat?
In dem Fall soll ja nicht zusätzlich cycleway=* getaggt werden.
Und ich bin der Meinung, dass wir keine Negativ-Datenbank mit Einträgen brauchen, die vor allem der Befriedigung irgendwelcher Apps dienen. Tagging for the app sozusagen.
Ansonsten gibt es - auch nur ein Beispiel von vielen - so etwas schönes wie hier aus dem recycling-Bereich: http://www.openstreetmap.org/node/2277053564
20x “no”, 1x “yes”
Sollen so Straßen getaggt werden, dann vielleicht auch für jede residential noch inklusive foot=yes und bicycle=yes? Denn weiß ich in letzter Konsequenz, ob Fußgänger oder Radfahrer nicht doch die Passage hier verwehrt ist? Das muss doch immer erstmal festgestellt sein!
Vielleicht könnte man ja als Lösung für manches “Tagging for the app” Standardwerte einführen, aber ich weiß, daß ist ein alter Hut…
Z B. finde ich, dass man für highway=residential sidewalk=both, surface=asphalt und cycleway=no erwarten kann. Überall da, wo das nicht zutrifft, wird dann sidewalk und cycleway getaggt. Überall wo’s zutrifft, nicht. Aber klar, jetzt kommt wieder jemand und sagt, dass das von Land zu Land unterschiedlich ist und so weiter… Die Frage ist aber, wohin das führen soll.
Moin
Mir sind gestern paar “Feldwege” mitten in der Stadt aufgefallen, die sich als bisher namenlose Ex-Pedestrians entpuppten aus diesem und vor allem diesem Changesets, beide von StreetComplete 3.6.
Beim Korrigieren festgestellt, dass sowas in der Ecke schon mal passiert ist *), was diesem CS zu entnehmen ist mit SC 2.3.
Gibt es diesen offensichtlichen bug immer noch?
Ich denke mal das hier dürfte die entsprechende Stelle im Questcode sein, d.h. nach meiner sehr subjektiven bisherigen Wahrnehmung wird dir westnordost daraufhin antworten, dass es sich hierbei leider um einen Bedienerfehler handelt und er sich nicht zuständig fühlt … oder er könnte dir entgegen, dass es sich hierbei um einen footway anstatt um einen pedestrian handelt
Hab es gerade eben mal überprüft:
Das sollte kein Bug sein, sondern viel mehr ein Fehlverhalten des Nutzers:
Stellt die App dem Nutzer die Frage wie eine Straße heißt, kann der Nutzer natürlich den Straßennamen eintragen, aber auch als weitere Antwortmöglichkeit auswählen, dass diese Straße gar keinen Namen hat. Mit dieser Antwort öffnet sich dann ein weiterer Dialog, in dem der Nutzer angeben kann, wieso die Straße keinen Namen hat. Unter anderem sind dies:
Ist bloß so etwas wie eine Zufahrt → ändert den Weg zu “highway=service”
Ist nur ein Feld- oder Waldweg → ändert den Weg zu “highway=track”!
Etwas anderes → lässt den Nutzer eine Notiz hinterlassen
Sie hat einfach keinen Namen → fügt “noname=yes” hinzu
Der Nutzer hat hier wahrscheinlich fälschlicherweise die zweite Antwort gewählt, obwohl es eher die letzte sein sollte…
Sry, aber wer man eine Fußgängerzone nicht von einem Feldweg unterscheiden kann, dem ist auch nicht merh zu helfen…
Da kann man dem Entwickler wirklich keinen Vorwurf machen.
Bitte solche Changesets auch kommentieren! Auch wenn der User nur mit StreetComplete arbeitet, hat er trotzdem ein gültiges OSM-Konto und kann daher auch auf seine Fehler aufmerksam gemacht werden!
Okay hsimpson, ich mache dir folgendes Angebot: du bekommst von mir ein Bier ausgegeben, wenn du erfolgreich einen der User erreichst und eine entsprechende Antwort erhälst… also dahingehend, dass man ihnen auf Grund mangelnder Unterscheidungskompetenz nicht mehr helfen könne.
hmm,
Miggel seit 7.11.2007 angemeldet und alle paar Jahre mal ganze 6 Edits
und olvagor macht nicht den Eindruck, als ob er den Fehler bewusst gemacht hat
Doch, ich denke schon. Nämlich den, dass er dem Nutzer die Konsequenz seiner Angabe nicht klar macht.
Ich habe das Interface jetzt nicht gesehen, aber wenn es wie oben beschrieben ist, kann ich gut verstehen, wenn jemand denkt, dass er hier wirklich nur die Begründung für die App angibt (für die “Naja, so ne Fußgängerzone ist wie so ein Feldweg, das ist zwar Weg, aber nicht benannt”) und nicht die Klassifizierung ändert. Dazu kommt die kleine Menge an Auswahlmöglichkeiten (service, track), wo viele andere denkbar wären (vor allem footway, path, etc.).
Hier wäre es durchaus Sache des Entwicklers, das Interface deutlicher zu gestalten. Als Vorschlag könnte der Dialog vielleicht eher so aussehen:
Es handelt sich hierbei nicht um [aktueller highway-key], sondern um… (würde eine längere Liste üblicher highway-keys öffnen, aus denen einer ausgewählt werden kann, wobei entweder vor oder nach der Auswahl eines neuen Schlüssels ein Hinweis angezeigte werden könnte im Sinne von “Wegtyp ändern” bzw.“Soll der Typ des Wegs wirklich auf [neuer highway-key] geändert werden?”)
Die aber auch Sinn macht, denn ich glaube nicht, dass jemand eine einen (in der Realität) Fußweg als Straße in OSM einträgt. (Die App sucht nur nach Straßen ohne Namen und nicht Fußwege…)
In der ganzen App ist nie die Rede von OSM-Tags und -Values, weil die App vor allem für neuere Nutzer gedacht ist, die evtl. gar keine Ahnung von OSM haben… Insofern kann man hier dem Nutzer keine Liste an irgendwelchen highway-Tags vorsetzen sondern muss die Werte geschickt in Worte verpacken. Und so wird es ja im Moment quasi auch schon gemacht…
Aber genau dann sind wir bei dem Punkt angekommen, wo wir gar nicht mehr anders können, also solche changesets zwangsweise zu reviewen und gesondert freizugeben …
@ENT8R: Ja, ich ging von einer entsprechenden Übersetzung, nicht von den konkreten Werten aus. Mir geht es aber gar nicht primär darum, sondern darum a) klar zu machen, dass die Auswahl den Wegtyp ändern wird, b) dass es mehr als nur zwei oder drei Typen in Frage kommen, auch wenn die vielleicht die häufigsten sein mögen (aber wie man sieht taucht zumindest pedestrian halt auch auf) sowie c) die Möglichkeiten, die den Wegtyp nicht ändern, prominenter darzustellen, in dem nicht mehrere verschieden Wegtypen auf der gleichen Auswahlebene wie diese Möglichkeiten angezeigt werden. Zusammen sollten diese drei Punkte dem Nutzer klarer zeigen könne, welche Antwort hier die Situation am Besten beschreibt. Denn wie gerade da, wo eben nicht konkrete Tags angezeigt, sondern nur verklausuliert werden, scheint mir das eben nicht klar zu sein, was welche Antwort bewirkt und ob man sie auswählen sollte. Denn wer sagt “Ich kann dem Benutzer nicht zumuten, den Unterschied zwischen highway=track und highway=path zu kennen”, der sollte auch sagen “Ich kann dem Benutzer nicht zumuten, zu erkennen, ob seine Antwort nur eine (vielleicht applikationsinterne) Notiz ist oder ob das eine konkrete Änderung der Datenbank bewirkt.”
