Hat der Autor nicht eigentlich Github dafür vorgesehen? https://github.com/westnordost/StreetComplete/issues
dort kann man ohne Github-Kentnisse - allerdings mit einem Account - zentral alle Wünsche kundtun. Ich halte das für sinnvoller als wenn man sich an verschiedenen Stellen verzettelt. ich werde jedenfalls diesen Weg gehen.
Gruss
walter
Klar - wenn man einen einen konkreten Änderungsvorschlag oder Fehler hat, macht das Sinn … aber um Dinge zu erörtern, bevor daraus was konkretes wird, ist so ein bug/issue tracker doch nicht gedacht, oder?
Ausserdem ist die Reichweite an kundigen Kommentatoren hier vielleicht größer … dachte ich …
Gruß und schönes WE
Stephan
Spätestens wenn man QA macht, nutzt das Deinstallieren gar nix, weil Du Streetcomplete hinterherwischen musst. Speziell bei opening_hours (siehe #13 von vor nem halben Jahr…) sind die Eintragungen teilweise so falsch, dass man überhaupt nicht erahnen kann, was eigentlich gemeint sein könnte.
Willkürliche aktuelle Beispiele:
Tu-Fr 17:00-22:00+, Sa,Su 22:00-18:00+
5.11. SC 2.4
Tu-Su 19:00-18:00+
6.11. SC 2.3
Das ist natürlich gar nicht schön. Wäre es möglich, StreetComplete mit einer etwas intelligenteren Eingabemaske für Öffnungszeiten zu versehen, die solche Dinge verhindert? Oder aber, falls das nicht möglich ist, mit einem nachgelagerten Öffnungszeiten-Parser, der zumindest einen Teil solcher offensichtlich unsinniger Eingaben erkennt und, statt sie zu speichern, dem Benutzer eine Fehlermeldung anzeigt? (Dass es ein Fehler sein muss, wenn in HH1:MM1-HH2:MM2 der Wert von HH2 < HH1 ist oder, wenn HH2 = HH1, MM2 <= MM1, sollte sich ja relativ leicht erkennen lassen. :))
Sorry, das könnte allenfalls eine Warnung sein. Oder müssen wir die Nachtbar, die jeden Tag von 22:00-03:00 offen hat, dann in in Mo-Su 00:00-03:00, 22:00-24:00 umschreiben?
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.
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?