StreetComplete - die nächste suboptimale App

Mal eine Kopie aus dem anderen Thema https://forum.openstreetmap.org/viewtopic.php?pid=707139#p707139 :

zum Kommentar:
Warum verwendet dann streetcomplete maxspeed:type statt source:maxspeed?
(Ich vermute einmal dass es durch die APP einfach zur Überlegenheit des englischen Schlüssels getrimmt wird.)

Und das als Moderator !?

Meinst du als Admin oder Moderator kann ich keine eigene Meinung haben? Ich nutze aus guten Gründen einen extra Admin Account damit meinem Wort nicht mehr Gewicht gegeben wird als dem von Anderen und ich sehe kein Problem darin einen überspitzten Kommentar abzugeben der sogar noch extra als solche gekennzeichnet ist.

Warum bringst du zum wiederholten Male dieses Thema hier ein, lediglich ein paar Posts vorher hab ich auch dich darauf hingewiesen bitte den schon vorhandenen Thread dafür zu nutzen.

OK - dann immer vereinzelte Probleme vereinzelt beschreiben und vereinzelt klären - oder auch nicht?

Es ging hier um die Aussage

von dem User - der selbst diese Aussage in (seiner) APP umgeht.

So oder so und ob mit oder ohne Polemik-Tag bringt einen die Antwort nicht richtig weiter.

Meine Frage zielte dahin, ob man sich jetzt darauf einstellen muß, nicht nur hier und da Changesets zu sehen, wo ein wenig Asphalt auf die Staße gebröselt wird, oder 50 Meter Staße die Information bekommen, daß links und rechts kein Radweg ist, während 10 km davor und dahinter der default “Weiss ich nicht” verbleibt, oder die App nun mehr oder weniger automatisiert diese punktuelle Wissen- oder Unwissenheit auch noch in Notes umsetzt.

Letztere lönnte man schlicht nicht weiter beachten … machen aber das Auffinden relevanter Notes nicht leichter.

Letztendlich würde ich mit RoterEmil anschließen … dann ist viellecht die Note das kleinere Übel.

Und jetzt sag’ bitte keiner man könne das aber nicht so überspitzt darstellen … :wink:

Gruß
Stephan

Also sagen wirs mal so: Diejenigen, die StreetComplete wirklich nutzen, sind in aller Regel solche Nutzer, die niemals einen normalen Editor anfassen würden. Diese App aktiviert uns also ne Menge Wissen, das anders nicht erreicht werden kann.

Das geht eben deshalb so gut, weil die App sehr spartanisch ist und den User nicht mit Unmengen an Infos zuballert. Damit einher gehen dann aber auch Nachteile wie eben ein begrenzter Funktionsumfang.

Dass die App dann am Ende ihres Funktionsumfangs Notes setzt halte ich da dann für total unproblematisch. Zumal sich diese Notes bisher dadurch auszeichnen, dass sie deutlich informativer sind als vergleichbare Notes, wie etwa die von Maps.Me. Das führt dazu, dass sie auch schneller bearbeitet werden können und somit auch schneller erledigt sind.

Insgesamt habe ich tatsächlich in letzter zeit kaum noch StreetComplete-Notes gesehen, was ich von den Maps.Me-Notes definitiv nicht sagen kann.

Auch sind mir bisher keine CS von StreetComplete aufgefallen, die in irgendeiner Art problematisch wären. Spätestens, seit die App die Daten gebündelt hochlädt kann man hier eig keinen Anhaltspunkt für Kritik finden.

Warum sollte das so passieren?

Die App spaltet keine Ways auf und erstellt auch keine neuen Ways oder Nodes. Wenn also ein 50m Stück entstehen sollte, dann nur deshalb, weil es vorher schon existierte. Und hinter der App sitzen ja auch Menschen mit der Befähigung zum Denken. Wenn sie eine Frage zum Radweg beantworten werden sie sicher erkennen, dass das angrenzende Straßenstück dieselbe Frage hat.

Entweder wird diese Frage dann auch beantwortet, oder eben nicht. Letzteres dann meist mangels Wissen.

In dem Fall ist mir trotzdem lieber, dass die User der App die 50m, bei denen sie über Wissen verfügen, dann so korrigieren, als gar nichts zu machen. So kommen dann vieleicht andere Mapper auf die Idee, dass man sich diese Stelle nochmal genauer anschauen sollte!

Viele Grüße

So “schwierige Sachen” hatte ich gar nicht im Sinn … mir geht’s eher um den Mehrwert bereits ohnehin vorhandene Objekte “insulär” mit einem Detaillierungsgrad zu versehen, der durch die App und deren Entwickler bestimmt wird (wie du eingangs richtig bemerktest - mit einem Editor mit mehr Freiheitsgraden oder Diskussionen über was wie zu taggen wäre wird sich die Zielgruppe der App eher nicht auseinandersetzen).

Aber das kann man natürlich jeder für sich bewerten. Ich find’s nur anders nervig als maps.me.

Gruß
Stephan

Ich verstehe gar nicht warum aus den “Detailinseln” so ein Problem gemacht wird.
Die gibt es auch völlig ohne solche Apps da der Detailgrad von OSM in erster Linie davon abhängt wie viele aktive Mapper aus dem Gebiet stammen und wie sehr deren Hang nach Perfektionismus ausgeprägt ist.
Da gibt es Gegenden wo jeder Baum einzeln gemappt und vollständig getaggt ist und andere wo sämtliche Gebäude fehlen und nur die rudimentär die Straßen vorhanden sind. Apps die es für den User sehr einfach machen Informationen hinzuzufügen können der Anfang sein in solchen Gegenden überhaupt mal etwas zu mappen.

Persönlich viel kritischer sehe ich unterschiedliche Wikidefinitionen die ein uneinheitliches und damit schwer auswertbares Tagging produzieren. Das sind Probleme die man wirklich angehen müsste, aber wahrscheinlich nie gelöst werden weil jede Community für sich beansprucht den Stein der Weisen gefunden zu haben.

Dem kann ich nur zustimmen.

Sie richten vielleicht keinen Schaden an, aber man kann sich fragen, was damit erreicht wird, wenn dort, wo zufällig ein SC-Nutzer vorbei kommt, das surface-Tag auf den Wert gesetzt wird, der dort bisher nach allgemeinem Verständnis als Default-Wert galt. Das wäre dann sinnvoll, wenn man langfristig auf Defaults verzichtet. Solange es darüber keinen Konsens gibt, verschwendet dieses punktuelle Taggen von Default-Werten Ressourcen, die man besser für was anderes einsetzen könnte.

Ein Dauerbrenner, der hier im Thread, wenn ich mich recht entsinne schon mehrmals besprochen wurde. Aber gern nochmal:

  1. Jeder verschwendet die Resourcen auf die er gerade Lust hat.
  2. Wenn ich Lust habe defaultwerte zu taggen, dann habe ich einen guten Grund. Fehlendes surface=asphalt (bspw.) kann 2erlei bedeuten: ein Vormapper hat zwecks default seine Ressourcen anders verschwendet oder er hat sich keine Gedanken über den Strassenbelag gemacht.
    surface=asphalt heisst, jmd. hat sich den Strassenbelag angeschaut und es heisst, dass da kein Kopfsteinpflaster ist oder sonstwas.
    Kein surface=asphalt heisst garnix.

Also das Verstehen einer anderen Position würde m. E. aus dem Diskurs entstehen. Natürlich kann auch jeder seine Meinung behalten und die Welt ist auch schön.

Letztendlich ist es weniger das Ergebnis, als vielmehr die Tatsache das dieses Verhalten und das erzeugte Muster durch eine einzelne App erzeugt und gefördert werden.
Natürlich haben auch alle Recht, die sagen, daß das nun im größeren, indivduellen OSM Wildwuchs nun auch nichts mehr ausmacht.

Mir scheint z.B. eine Straße einheitlich ohne surface attribute sauberer, als ein Flickenteppich. Das ist nicht “so ein Problem” sondern erstmal eine Meinung. Die kann man teilen oder nicht - so ganz einsam schein’ ich damit nicht zu sein.

Aber wir werden das hier nicht lösen … und es ist nichts, das OSM an den Abgrund bringen wird.

Gruß
Stephan

Ich als Radfahrer sehe das genau anders herum. Kein surface kann wirklich alles bedeuten - vom nagelneuen glatten asphalt bis zur letzten Buckelpiste.

Klar, auf ner Autobahn mag das vieleicht ein wenig übertrieben sein, überall surface=asphalt oder concrete zu taggen, aber alle anderen Straßen sind da keineswegs so eindeutig. Und das gilt eigentlich für alle erfassten Werte.

Ich würde z.B. gerne mal wissen, wie die Verbreitung des Schlüssels opening_hours=* durch StreetComplete zugenommen hat. Als ich das erste mal hier rein geschaut habe, waren in meiner Umgebung nahezu alle Geschäfte mit dieser Frage versehen (ich wohne im Innenstadtbereich). Inzwischen sehe ich keine einzige Frage mehr zu dem Thema!

Und ich muss auch aus Erfahrung sagen, dass es einige StreetComplete-Nutzer gibt, die sehr systematisch alle Fragen in ihrer Gegend abarbeiten und dadurch tatsächlich viel zum aktuellen Datenbestand beigetragen haben.

Ich verstehe echt nicht, wie man sich so an einer einzigen App aufhängen kann. Ich hab langsam das Gefühl, dass einige hier einfach nicht ertragen können, dass es andere Leute gibt, die gerne für OSM zuarbeiten wollen, aber keine Lust und Nerven oder sonstwas haben, sich in die Komplexe Welt des OSM-Kosmos einzudenken und stattdessen gerne auf Angebote wie StreetComplete zurückgreifen.

Es ist aber grade für das langfristige Fortbestehen von OSM essentiell, dass jeder, der möchte, ohne große Hürden mitarbeiten kann! Das Beispiel Wikipedia zeigt gut, was passieren kann, wenn man die Einstiegshürden zu hoch legt und das System so komplex macht, dass man erstmal ne zweistellige Zahl an Stunden investieren muss, um überhaupt einigermaßen fehlerfrei arbeiten zu können!

Nur zur Erinnerung: Die App hat bisher über 10.000 Downloads und ist im Play Store mit 4,6 von 5 Sternen bewertet. Diese App kommt an, und zwar ordentlich!

Grüße

Genau deshalb war die Frage von mir:
maxspeed:type gegen source:maxspeed

und die Aussage:

Umsomehr die APP ihre Daten einbringt, wird auch maxspeed:type steigen. Obwohl es im WIKI nicht dokumentiert ist (nur für GB als eigenes Ding), sollte doch in DE source:maxspeed genutzt werden.
oder:
Wir schmeißen in DE und anderen Länder das source:maxspeed über den Haufen und taggen alles “Weltweit” um nach maxspeed:type.

Keineswegs, dafür gäbe es sogar einen konkreten Anwendungsfall: Router könnten Beton-Autobahnen in Sommer an sehr heißen Tagen wegen “Blow Ups” meiden, oder zumindest die Fahrzeit verlängern, da mittlerweile bei solchen Strecken sehr häufig dann im Hochsommer auf einmal komplett max. 80km/h ausgeschildert ist.

Aber nur, wenn man weiß, wann die Betonfahrbahnen das letzte mal gewartet wurden :wink: Das Problem tritt nämlich erst auf, wenn man Elemente wie Fugen etc. über einen längeren zeitraum vernachlässigt.

Dazu kommen dann Autobahnen mit viel LKW-Verkehr, bei denen nur die rechte Spur betoniert ist… Da sind wir dann bei surface:lanes=* :smiley:

Aber prinzipiell liegen wir beide glaube ich auf einer Wellenlänge: Es ist besser, solche Infos pöapö zu erfassen, als sie gar nicht zu erfassen. Denn erst, wenn man eine gewisse Abdeckung erreicht, können die Auswerter sinnvoll damit umgehen.

Grüße

Ich hab dazu shcon oft meine Meinung gesagt, daher mache ich das hier knapp:

Das was StreetComplete hier ausdrücken will, hat mit source:maxspeed recht wenig zu tun. Im Falle maxspeed:type=DE:urban z.B. gab es vorher schlicht keine Möglichkeit, das so darzustellen.

Ja, es ist nicht die beste Option, dass das so eingeführt wurde, aber wir hatten hier im Forum schon Romane zu dem Thema zusammendiskutiert und es gab nicht einmal ansatzweise eine Lösung, die von allen getragen wurde. Dass die Entwickler irgendwann nicht mehr da drauf warten wollten, kann ich schon irgendwo verstehen.

Grüße

Das Problem mit Defaults habe ich in einem anderen Beitrag schon beschrieben. Zum einen bräuchte man erstmal weltweite Defaults. Länderspezifische Defaults, wie öfters zu sehen, würden im Extremfall zu einem 193 (Zahl der Länder auf der Erde) fachen Implementierungsaufwand für Software Entwickler führen die OSM nutzen wollen. Das wird keiner tun. Man wird sich auch nicht auf weltweite Defaults einigen können weil Gesetzgebung und finanzielle Mittel zum Bau einfach zu stark unterschiedlich sind. Es bleibt unterm Strich also nur noch das definitive angeben von Eigenschaften.
Das nächste Problem ist, das keine Software unterscheiden kann ob nun ein Default Wert gilt, oder ob die Information schlicht unbekannt ist. Anstatt das Feld einfach leer zu lassen müsste dann auch ein explizites “Default” gesetzt werden damit es für Software (und Menschen) eindeutig ist.

Der Gedanke der verschwendeten Ressourcen basiert auf der Idee, dass die Nutzer von Streetcomplete in der Zeit einfach etwas anderes mappen könnten. Aber wenn die Quest oder gar die ganze App nicht angeboten werden würde, würden Sie wahrscheinlich überhaupt nichts eintragen.

Sehe ich deswegen anders weil je mehr Leute eine solche App Nutzen, umso vollständiger wird der Datensatz. Bevor eine komplette Stadt gemappt ist, ist da zunächst einmal ein einzelnes Gebäude…
Auch ohne diese Apps würde es sowas geben. Ich selbst neige zum Beispiel dazu einzelne Häuser und Hausnummern zu mappen einfach weil ich sie beim nächsten Kartenupdate im Navi haben will. Ich möchte nicht das daraus eine “Verpflichtung” entsteht auch noch den Rest des Viertels zu mappen nur damit keine Detailinsel entsteht.
OSM ist eben ein wachsendes Projekt und es wächst schneller wenn mehr Menschen mitmachen und dafür sind Apps die das editieren vereinfachen eine hervoragende Möglichkeit.

Ich dachte ich hätte sachlich erläutert um was es mir geht und das es damit auch gut sein soll … über die resultierende unterstellende Interpretation möcht ich mich erst gar nicht weiter ärgern.

Über User mit systematischem Output via SC kann ich hier nicht berichten (sont würde meine Meinung vielleicht eine andere sein). Vielleicht gibt’s für sowas ja mal eine exemplarische Statistik über alle Editoren, um verschiedene Wahrnehmungen mit Zahlen zu untermauern.

Über die Notwenigkeit zu einem einfach zu handhabenden Zugang zur OSM Pflege für die Zukunft besteht sicher auch kein Dissenz - ob allerdings die Download Zahlen und Bewertungen der App allein sie qualifizieren?!?

Und wie gesagt - ich wills nicht weiter auswalzen, da ich für mich den Eindruck gewinne die Diskussion dreht sich im Kreis und sollte keinen Grabenkieg wert sein.

Gruß
Stephan