Um auch mal was Positives zu sagen: Ich „stolpere“ in BW auch über immer mehr StreetComplete-Beiträge. Ich bin zwar nicht 100% glücklich damit, dass da tlw. Hausnummern eingetragen werden, ohne anschließend auch gleich die Straßennamen zu ergänzen (das ist dann wohl mein Job ;)), aber bisher wirkten alle Einträge, die ich mir angesehen habe, vernünftig, manche sind sogar ausgezeichnet.
Insofern unterscheidet sich StreetComplete, auch wenn es nicht perfekt ist (gibt es das denn überhaupt bei Apps?), für mich schon wohltuend von Wheelmap etc. Wheelmap wäre an sich eine super Idee, aber wegen hier im Forum oft diskutierter Probleme sind viele viele Bearbeitungen suboptimal bis abwegig. StreetComplete dagegen trägt schon richtig gute Dinge zu unserer Datenbank bei.
Also lasst uns doch versuchen, durch konstruktive Kritik diese App noch besser zu machen, statt durch Gemotze die Fronten nur zu verhärten.
Guter Vorschlag … das würde vielleicht einen neuen Thread unter einem weniger provokanten Titel vorrausstetzen, der vielleicht sogar vom Autoren von StreetComplete gestartet / maintained wird … a La “StreetComplete - Verbesserungsvorschäge” oder so?!?
Ich denke bestehende Datenbestände von Usern ohne besonderes Hintergrundwissen erweitern/aktualisieren zu lassen - das stellt den Entwickler vor besondere Herausforderungen bzgl. der Quests und deren Implementierung.
Wenn man da helfen kann und die Hilfe akzeptiert wird … warum nicht.
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.
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 …
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:
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?
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.
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.
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?
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.
