StreetComplete - die nächste suboptimale App

na soweit ich weiß, macht ja sizusagen nicht die App/der Editor einen edit, sondern du bzw. dein Account. Das geht über die OSM API und der Editor sagt mit created_by lediglich Bescheid wer er ist. Da könnte man auch einfach JOSM reinschreiben obwohls nicht stimmt.

Aber Nakaner hat im Github Issue Thread ja nun auch schon angedeutet, dass er die DWG/OWG um eine Sperre bitten wird, wenn das Problem nicht beseitigt wird. Weiß nicht ob es da schon einen etablierten Weg gibt, aber OWG/DWG könnten evtl. edits mit dem Tag created_by=X blockieren. Das würde eine App aber auch nicht daran hindern da dann einfach einen neuen Namen zu verwenden wenn sie es darauf anlegt.

Hallo,

Ich habe westnordost vorher auf Github nochmal ermahnt, sich schleunigst um die Problemlösung zu kümmern und eine vorübergehende Sperre der App (nicht ihrer Benutzer, denn diese sind nicht schuld) angedroht, wenn ich innerhalb von 48 Stunden keine Fortschritte/Bemühungen erkenne. Das heißt nicht, dass es bis dahin behoben sein muss. Wenn aber die Behebung nicht in Angriff genommen wird und stattdessen die Zeit in andere Dinge im Code gesteckt wird, die weniger wichtig sind, halte ich eine Sperre als Druckmittel für angemessen. Mir tut es selber leid, mit der bösen Keule zu drohen, aber wenn das Problem seit drei Tagen bekannt ist und in zwei Tagen wir so weit sind wie vor drei Tagen, dann …

Wir hatten letztes Jahr mal den Amenity-Editor bis zum Release der nächsten Version gesperrt, ohne seinem Entwickler vorher eine Reparaturfrist einzuräumen. Da war aber der Schaden weitaus größer und mit dem Länge-Breite-Vertausch-Bug von JOSM vor Urzeiten vergleichbar.

Wenn die App OAuth nutzt, werden deren Schlüssel deaktiviert. Das ist letzten Herbst beim Amenity Editor geschehen.

Überlegenswert wäre eine Richtlinie mit Empfehlungscharakter, die weniger streng als die Import-Richtlinie ist und im Kern aus einem “Zertifizierungsprozess” (pfui, ich hasse dieses Wort, aber Review ist Englisch) besteht, bei dem erfahrene Leute einer Anwendung attestieren, dass sie bestimmte Kritierien besteht (z.B. korrekte Tag-Behandlung beim Umdrehen von Ways, angemessener Umgang mit Relationen, …). Es sollten aber nur freie Anwendungen zertifiziert werden. Wer nicht zertifiziert ist, muss damit rechnen, dass seine Anwendung bei ausreichend schwerwiegenden Problemen mehr oder minder unangekündigt vorübergehend gesperrt wird. Das würde die Nutzer stören und gerade bei Anwendungen die sich an Nicht-Mapper richten und keine OSM-Erfahrung verlangen, zu schlechten Bewertungen führen (“Die scheiß App stürzt ab, wenn ich etwas speichern will”).

Ich spreche mich jedoch ausdrücklich gegen eine Genehmigungspflicht aus, weil diese jegliche Innovation hindert und nicht im Interesse des OSM-Projekts ist.

Viele Grüße

Michael

Seh ich auch so, der Schaden und Aufwand wäre viel größer als bei gelegentlchen Problemen einzugreifen. Dass man ja einfach über den oauth schlüssel sperren kann hab ich garnicht bedacht :slight_smile:

Auch nicht ganz richtig, denn einige Dienste nutzen einen Sammelaccount, über den alle Änderungen der Nutzer laufen, z.B. die Wheelmap. Frage mich, warum so etwas überhaupt zugelassen wird.

https://www.openstreetmap.org/user/wheelmap_visitor

Im Dezember hat sich der Autor der App schon positiv zur Idee “Kill Switch” geäußert, d.h. ein zentraler Schalter, der die App global deaktiviert. Vielleicht kann man die aktuelle Version ja auch am Upload von Änderungen hindern, so wie damals die 0.1.

https://forum.openstreetmap.org/viewtopic.php?pid=621351#p621351

naja war ja nur um den technischen ablauf zu illustrieren, klar kann man das dann auch verhumbeutelt über einen account laufen lassen :slight_smile:

Es ist nicht erwünscht, weil es die folgenden Nachteile hat:

  • bei Vandalismus/Copyrightproblemen kann man die problematischen nicht von den normalen Usern trennen
  • Rückfragen sind nicht möglich

Im konkreten Fall der Wheelmap haben wir da bislang immer ein Auge zugedrückt, weil man dort ja nur sehr, sehr begrenzt Edits machen kann, und das Potential für Vandalismus relativ gering ist. Wenn man mit der Wheelmap umfassendere Änderungen machen will, muss man sich ja anmelden, das geht dann nicht mehr über den “visitor”.

Bye
Frederik

Hui, was ist hier denn los.

Zum Thema Genehmigungspflicht ganz allgemein: Das ist in der Tat zurzeit so, dass nach meinen Information es keine gibt und dass generell nur in Notfällen (Programm macht OSM Daten kaputt) ein Programm gesperrt wird. Darüber habe ich mich auch gewundert, ich meine, dass dieser gutmütige Ansatz bisher so relativ problemlos funktioniert hat, finde ich bemerkenswert. Im positiven Sinne.

Puh, du hast vielleicht eine falsche Vorstellung davon, wie schnell Softwareentwicklung so geht. Erstensmal bin ich Vollzeit beschäftigt, SC mache ich also in meiner Freizeit. Die Version von StreetComplete, wie sie jetzt ist, hat mich anderthalb Jahre Arbeit gekostet. Und so viel drin ist da ja, wie du siehst, noch nicht.

Für die Implementierung brauche ich erstmal einen Plan, wie genau das umgesetzt werden soll, insofern sei da nochmal auf das Ticket verwiesen, ich kann da noch Input gebrauchen.

Zum Thema “böse Keule” und drohen: Ja, liest sich nicht schön. Aber ist schon okay, das kann man auch ganz sachlich und unemotional behandeln. Wenn das Feature so wichtig ist, dass die App geblockt werden soll, solange es noch nicht implementiert ist, dann stirbt ja auch niemand daran.

Unabhängig davon bin ich ehrlich gesagt grad etwas überstrapaziert von all dem Feedback (Bugs und Feature Requests) den ich seit etwa einer Woche bekomme. Vorher fast ein halbes Jahr fast nix, jetzt plötzlich pro Tag dutzende von Mails zu SC, von 5 auf 70 offene Tickets auf GitHub.

Evtl hast du ja das hier überlesen:

Ist alles eine Frage der Prioritäten. Ich würde mich in deiner Situation derzeit um nix anderes bemühen, als dieses Problem zu beseitigen.

Gruss
walter

@nakaner: +1

Eine Sperre um dieses nervende Verhalten der App zu verhindern, halte ich für durchaus angebracht. Zudem ist ja (mir) unklar, wie eine eventuell zügige Korrektur seinen Weg zu den Endusern findet. Bis die freiwillig updaten, vergeht ja auch noch einige Zeit.

Bin einer der “bösen” Münchner User - hab mich auch schon gefragt warum keine Changesets gebaut wurden, mir waren die Implikationen für Qualitätsmanagement nicht so ganz klar - hab die Nutzung jetzt erstmal auf Eis gelegt.

@westnordost: Klasse app! m.M. nach die “bequemste” Art, OSM edits on-the-go zu machen und insb. auch für Nutzer ohne großen Buy-in nutzbar.

Dem kann ich nur zustimmen! Ich halte StreetComplete nicht nur für die bequemste, sondern auch für die schönste App für die mobile Datenerfassung.

Kopf hoch @westnordost: bin gespannt auf Version 0.6, die das Problem mit den CS löst!

Anstatt den Oauth key zu widerrufen könnte man ja auch schauen, ob eine Sperrung von Versionen <= x möglich ist. Dann könnten Nutzer von einer neueren Version die App normal nutzen, andere mit einer veralteten Version hingegen nicht.

Ich bin auch der Meinung, dass der Zugriff über die aktuelle Version möglichst schnell gestoppt werden sollte. In meiner Region gab es zwar noch keine Changesets darüber, aber wenn jemand durch die Stadt geht und dutzende CS mit je einer Änderung erzeugt, würde mich das schon ziemlich stören.

westnordost müsste sich halt einen neuen OAuth-Schlüssel holen, bevor er die neue Version freigibt. Das ist nichts Bürokratisches, sondern erfordert nur das Ausfüllen eines Formulars. Das ist im Wiki beschrieben. Es ist einfach. Ich habe es selbst schon gemacht, als ich mit JOSM über die Dev-API editieren wollte (Änderungssätze für ein Revertskript erzeugen).

Ich hatte mit ihm schon Mailkontakt, bevor ich hier nachgelesen hatte. Es wurde zwar schon genug drüber diskutiert, aber ich geb jetzt doch noch meinen Senf dazu:

Wie man hier sehen kann: http://tyrasd.github.io/latest-changes/#15/48.1298/8.3376

Hat er mit der App auch bei der Reaktivierung von einem in letzter Zeit inaktiven Nutzer geholfen :wink:

Finde den einfachen Ansatz wenn man unterwegs ist kurz was einzutragen echt super, mir fehlt ja oft die Kreativität zu checken, was in gut gemappten Regionen noch fehlt.

Edit: Krass, hab mal ein paar Städte angeschaut, z.B. Tübingen, da sind ja echt extrem viele im Lande mit der App unterwegs!
(Bzw. einige wenige recht fleißig)

So, ich habe mir jetzt einmal auführlich überlegt, wie ich das implementieren würde. Nachdem ich im GitHub Ticket nicht allzu viel Feedback bekommen habe, hier einmal zusammengefasst. Wer große Bedenken dagegen hat, der möge jetzt sprechen oder für immer schweigen.

Grundsätzlich sind drei Modi zu unterscheiden: Automatisch (Online), Automatisch im Wifi und Manuell (Offline).

Für jeden Aufgabentyp wird ein eigenes Changeset erzeugt. Dieser Changeset hat je nach Aufgabentyp als Kommentar eine kurze Beschreibung, zum Beispiel “Added street surfaces” (also statt pro Aufgabe).
So ist nach wie vor am Kommentar des Changesets sofort die Natur der Änderungen zu erkennen, gleichzeitig reduziert sich die Anzahl der einzelnen Changesets deutlich.

Zunächst für den automatischen Modus: Gelöste Aufgaben werden sofort innerhalb ihres jeweiligen Changesets hochgeladen. Existiert noch keiner oder ist dieser schon geschlossen worden, wird dieser on-the-fly erstellt.
Der Changeset wächst also während der “survey” des Benutzers und wird schließlich von der App geschlossen, nachdem der Benutzer 10 Minuten keine Aufgaben dieses Typs mehr eingetragen hat. Diese Dauer kann nach Bedarf angepasst werden, wird aber nie über 1 Stunde betragen, da er nach einer Stunde automatisch vom OSM Server geschlossen wird. Tatsächlich wird dieser Fall recht häufig eintreten, denn es ist wahrscheinlich, dass nach dieser Wartezeit die App selbst garnicht mehr läuft.*
(Die App muss sich also persistent pro Aufgabentyp die zugehörige changeset id und die Zeit des letzten Lösen einer Aufgabe dieses Typs merken.)

Der “Automatisch im Wifi” Modus verhält sich wie der Name schon sagt im Wifi wie der automatische Modus und außerhalb des Wifis wie der manuelle. Das heißt, kommt man (zurück) in ein Wifi, werden die gelösten Aufgaben zwar sofort hochgeladen, aber die zugehörigen Changesets erst nach der Wartezeit geschlossen.

Manueller Modus: Der manuelle Modus ist ein bischen wie man es von einem klassischem Editor kennt. Es wird nichts automatisch hochgeladen und wenn der Benutzer den “Hochladen” Knopf drückt, wird sofort für jeden Aufgabentyp ein Changeset geöffnet, die Änderungen übertragen und der Changeset geschlossen. Das bedeutet, wenn ein Benutzer ständig auf diesen Knopf drückt, dann sind die Changesets eben auch klein. Das hat er da selbst in der Hand, wie bei jedem anderen Editor auch.
Es wäre natürlich möglich, auch im manuellen Modus die Changesets nicht sofort zu schließen sondern erst nach der Wartezeit, ich denke aber das läuft zuwider der Erwartung der Benutzer, dass nach Druck auf den Hochladen-Button wirklich alles abgeschlossen ist (würde aber natürlich zu weniger Changesets führen).

  • technisch wäre es möglich, dies auch nach Ableben der App zu machen (Android AlarmManager). Das ist etwas komplexer und kann später implementiert werden.

Hallo,

Welche Vorteile erhoffst du dir davon, dass es mehrere Modi gibt und nicht nur den manuellen? Das erhöht doch nur deinen Implementierungsaufwand? Der Nutzer weiß wahrscheinlich am besten, wann er ein stabileres Netz erwartet, um die Daten hochladen zu können.

Dumme Frage eines Nicht-Nutzers deiner App: Kann die App Objekte in OSM anlegen? Dann solltest du ein automatisches Hochladen über wackelige Netzwerverbindungen vermeiden. OSM kennt keine Transaktionen, sprich wenn die Transaktion abbricht, erfolgt kein Rollback, sondern das, was geschrieben wurde, bleibt persistent und der Rest ist weg. Was geschrieben wurde, kannst du nur umständlich herausfinden. Wenn man dann einfach ein zweites Mal blind hochlädt, erzeugt man Objekte doppelt.

Viele Grüße

Michael

Hallo BeKri,

Ich bemühe mich bisher immer, Sachliche Titel zu verwenden (gut, ab und an gehen auch bei mir die Nerven mal durch) und ich fahre damit bisher immer ziemlich gut. Es gibt genug Leute hier im Forum, die alles zumindest überfliegen und wenn nötig ihren Senf dazu geben (danke dafür). Von daher hatte ich bisher nie ein Problem, dass meine Probleme nicht gehört wirden wären.

Es ist vielmehr so, dass reißerische Titel dem Niveau des Threads schaden und damit auch der Antwortqualität. Von daher schneidest du dir damit auch ein Stück weit ins eigene Fleisch.

Grüße

Nein

Das ist nicht ganz richtig. Ein Changeset ist an sich keine atomare Transaktion, aber ein Diff upload innerhalb eines Changesets ist eine.

Der erste Eindruck dieses Entwurfes ist sehr zufriedenstellen.

Die Feinheiten und Notwendigkeit dieser drei Modi beginne ich langsam zu erkennen (halt nur dann hochladen, wenn es nötig und auch technisch möglich ist und dabei Datenvolumen sparen) und hab da auch keine grossen Bedenken.

Alles was dabei hilft, die Anzahl der CS zu minimieren, ist äußerst hilfreich. Und wenn dann mal einer manuell ein Dutzend kleine CS hochlädt, ist das auch nicht so schlimm - das machen unsere Kollegen (und ich) auch gelegentlich so.

Auf jeden Fall ein Schritt in die richtige Richtung.

Gruss
walter

Die Darstellung ist so nicht richtig. In “jedem anderen Editor” bei OSM wird nur ein CS erzeugt, egal wie oft man auf den Speichern Knopf drückt.

So sollte sich auch Dein manueller Modus verhalten: Keine mehrfachen CS bei mehrfachem Speichern.

bye, Nop