Stimmt auch wieder. Gut, dann eben eine Warnung. 
Ich hab mir SC heute mal wieder kurz angeschaut und glaube, dass es eher an den Eingabemöglichkeiten UND Einstellmöglichkeiten liegt und weniger an der fehlenden Fehlerprüfung. (Welche bei den Beispielen in JOSM und anderen Tools mindestens eine Warnung wenn nicht gar einen Error wirft).
Bei der Eingabe in SC habe ich nirgends eine Möglichkeit gefunden zu sehen, was ich da überhaupt eingegeben habe. Jemand, der sich etwas unsicher ist, ob das korrekt ist, verwirft das evtl. deswegen, aber als Laie bekommt man das nicht mit und kippt es in die DB. In der Quintessenz heisst das für mich, dass speziell bei OH wahrscheinlich niemand, der seinen Job ernst nimmt und/oder hinterfragt, sinnvolle OH abkippen KANN.
Ich hab vor längerer Zeit mal ein paar Dinge auf SC abgekippt und heute gesehen, dass ich die nich hochgeladen hab. Ja nun, es gibt da so einen Button, wo man die letzte Eingabe rückgängig machen kann, aber weder, was die Eingabe war, noch, was die vorher waren.
Hab das mal abgekippt und schau mir morgen an, was ich kaputtgemacht hab.
Hm, es scheint tatsächlich praktisch wirkungslose Änderungssätze von StreetComplete zu geben – jedenfalls erkenne ich nicht, was hier:
https://www.openstreetmap.org/changeset/54290790
letztlich geändert worden wäre (die Straße wurde benannt und dann der Name wieder entfernt). Kommt so etwas öfter vor? Könnte man solche wirkungslosen Änderungssätze nicht irgendwie vermeiden?
Ich glaube, dazu müssten sich die Entwickler mal auf das Mapper- und/oder OSM-Niveau herablassen*. Es gab zwar hier und anderswo diverse als konstruktiv zu verstehende Angebote in die Richtung, wirklich passiert ist imho nicht sehr viel.
- ODER Kritik nicht als Anpiss wahrnehmen, sondern als Hinweis, dass etwas kaputt oder Scheisse ist oder nicht funktioniert. Peinliches Beispiel: https://github.com/westnordost/StreetComplete/issues/305 DAS hat mich angepisst. Dass man (als Mapper) versucht etwas zu verbessern und nur als Störfaktor oder Anpisser wahrgenommen wird weil es nicht in die Developer-agenda passt.
Edit:
Grad noch mal den ganzen issue gelesen:
Nach einer elend langen Diskussion ist das ein guter Indikator, sich von OH zu entfernen und sich auf andere Dinge zu konzentrieren. Bei den “anderen Dingen” sollte mal als Entwickler auch so fair ggü. der Community sein, Dinge, die man nicht überschaut einfach rauszuwerfen und nicht wochenlang Ahnungslosigkeit raushängen zu lassen.
P.s.Klingt wirklich pissig, ich weiss, ich will niemanden persönlich angreifen, ich meine es neutral und ernst.
–snip–
Hi,
in meiner Gegend finde ich in letzter Zeit oft das Tag “cycleway:both=(meistens no)” scheint zur Standardauswahl bei Straßen in StreetComplete 3.2 gehören.
Wird fast an jede Straße gekleistert. Ist das notwendig?
Gruß
svr54
Habe ich auch schon bemängelt; zumal surface, smoothness, lit, … sinnvoller wären, wenn man schon einmal vor Ort ist.
Du kannst selber auswählen was Dir angezeigt werden soll. Ich habe zur Zeit nur die englischsprachige Version drauf. Da kann ich das wie folgt einstellen.
1.Oben rechts auf die 3 Punkte gehen.
2. Settings auswählen.
3. Runter scrollen bis Advanced.
4.Quest selection auswählen
5.Dann auswählen was man angezeigt bekommen möchte.
Unter anderem kannst da auch surface und lit auswählen.
Ich bin aber der Meinung, wenn ich eine Straße / POI auswähle sollte schon angezeigt werden welche (Haupt-) Schlüssel vorhanden sind. Falls dann ein Schlüssel nicht vorhanden ist, kann ich erweitern oder extra eingeben. Ob ich die dann nutze ist eine andere Sache. Ob aber gerade cycleway:both=no wichtiger ist?
Und es sollte auch nur etwas eingetragen werden, wenn man vor Ort ist.
Ich finde es praktisch das angezeigt wird was fehlt, denn ich kenne nicht alle Unterschlüssel und kann dann vor Ort den passenden aus de App auswählen. Zum Beispiel Dachformen. Zur besseren Übersicht habe ich mittlerweile nur einen Teil aktiviert .
Was mich stört ist das GPS. Während auf der OsmAnd die Position immer sehr genau ist, finde ich die Position bei StreetComplete immer verzögert dargestellt wird.
Warum wird dann nur z.B. cycleway:both=no ergänzt und surface, smoothness, lit nicht?
Na gut - ich nutze SC nicht. Bin nur immer erstaunt, wenn solche einzelne Schlüssel auftauchen - obwohl wichtigeres fehlt. Auch z.B. bei wheelchair:toilets=no an einer Bushaltestelle.
Man kann die Häkchen in der Auswahl so setzten das z.B. nur surface und lit auftaucht wo es noch fehlt. In meiner Gegend habe ich zuerst surface und lit ergänzt. Bei anderer Gelegenheit die fehlenden Öffnungszeiten und die Haltestellenhäuschen. Irgendwann mache ich dann auch mal die cycleway so fern das mit no zu beantworten ist. Die Radwege überlasse ich den Radspezialisten.
Ich setzte immer nur 1 oder 2 Häkchen max. 3, um die Übersicht zu behalten, denn es gibt schon 28 Topics zum auswählen.
Dabei wäre grad hier ein Radweg unbedingt zu erwarten; wo, wenn nicht hier, Am Sonnenhang in Prittlbach, an einer sicherlich verkehrlich hochbelasteten Straße
Dem User gebe ich keine Schuld - der App hingegen schon. Wir brauchen einfach keine solche Schwemme an notes. Es gibt sowieso schon genug offene notes, die auf eine Bearbeitung warten. OSM sollte auch nicht kartieren, was alles nicht ist, sondern was vorhanden ist. Ansonsten überlege ich eine note-Schwemme auf jeden Feld-, Wald und Wiesenweg, der mir unterkommt, loszuschießen, um zu vermerken, dass dort weder Fahrradwege, Beleuchtung, Bürgersteige, Busspuren etc. vorhanden sind. Und zwar alles einzeln.
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.
Viele Grüße
Wenn du nicht weisst, wie sich die App verhält, wie kommst Du dann drauf, dass es ein Fehler beim User wäre?
Bitte nochmal genau lesen
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.
Viele Grüße
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!
Leicht ironische Grüße 
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.
EDIT: Falsche Aussage von mir korrigiert.
Ja, die App schließt Straßen, die einen Abstand von 15 Metern oder weniger zu einem seperaten Radweg haben, aus und zeigt für diese folglich keine Quests an (https://github.com/westnordost/StreetComplete/blob/bf6957a62b5e889f298a396d34179d01897abe96/app/src/main/java/de/westnordost/streetcomplete/quests/bikeway/AddCycleway.java#L24)