Übernimmt Mapbox die Tagging-Hoheit in OSM?

Ich denke auch, dass man etwas vorsichtig sein sollte bevor man kleine zarte Pflänzchen wie StreetComplete mit einer großen Keule erschlägt. Ich denke, dass eine eventuelle Regelung der Presets so aussehen könnte, dass die per Default verfügbaren Presets gewissen Standards genügen müssen. Die Möglichkeit, sich Presets aktiv nachzuzladen, wird vermutlich mehrheitlich von Leuten genutzt, die schon ein Grundverständnis vom Tagging haben. Und es gibt gute Gründe, nicht durch den Approval-Prozeß gegangene Tags zu akzeptieren (3D Mapping als Beispiel) und das nachinstallieren von “ungewöhnlichen” Tags zu ermöglichen
Das ganze sollte meiner Meinung nach auch nicht für jede Software gelten, sondern nur für auf osm.org verfügbare Editoren und Editoren mit einem gewissen Marktanteil…meinetwegen >5% der Nutzer.

Diese Diskussion habe ich im Zusammenhang mit dem OSM-Standardstil schon oft geführt. Für mich gibt es da drei wichtige Ansätze, die auch für Editoren umsetzbar wären:

  • Es gibt dokumentierte Arbeitsgrundsätze des Projektes, welche regeln, nach welchen Kriterien Entscheidungen gefällt werden. Dies kann man sowohl auf den Editor als Ganzes als auch auf die Presets beziehen.
  • Die Einhaltung dieser Arbeitsgrundsätze wird nicht ausschließlich von einer Einzelperson, sondern von mehreren Leuten überwacht.
  • Das Wichtigste ist, dass es Alternativen gibt. Das ist bei Editoren um Glück immer noch der Fall. Sobald dies in Gefahr ist, sollte man daran gehen, explizit die Entwicklung von Alternativen zu fördern. Das können sowohl komplette Neu-Entwicklungen als auch Forks sein.

Ich würde ausdrücklich zustimmen, dass irgendwelche bürokratischen Genehmigungs/Zertifizierungs-Verfahren kontraproduktiv wären und fast garantiert zu einem who watches the watchers-Problem führen würde (hinsichtlich demokratischer Kontrolle ist die OSMF ja nicht gerade ein Aushängeschild). Aber die Förderung von Alternativen ist durchaus etwas, was die OSMF aktiv unterstützen könnte - dahingehend zum Beispiel dass man sagen könnte: Wir würden gerne eine zweite Version von iD auf der Webseite anbieten, welche einen anderen Default-Preset-Satz enthält. Wir rufen dazu auf, so was zu entwickeln um das dann für die Integration in die Webseite anzubieten.

Der Ansatzpunkt sollte sein: Ein Editor, der grundlegende (!) Taggingregeln missachtet, verwirkt den Anspruch, auf der OSM.org-Hauptseite als Editor angeboten zu werden.

+1. Gerade ein Editor, der sich an Einsteiger richtet, denn er hat auch einen Bildungsauftrag. Was man zuerst gelernt hat, pflegt man für richtig zu halten, sobald man später mit etwas davon Abweichendem konfrontiert wird.

–ks

kreuzschnabel und Pfad-Finder haben für mich eigentlich ausreichend geantwortet. Die bisherige Praxis fand ich nicht so schlecht, aber man sieht eben auch, dass man ggf. einfach ein paar verbindliche Regeln vorgeben muss, um die Richtung des Projekts zu bestimmen. Sonst geben irgendwann Externe der Kurs vor und die OSMF steht hilflos daneben. Bisher wurden Änderungen beim Tagging z.B. im Wiki aufgeführt und abgestimmt. Nicht wirklich toll, aber sowas wie ein Konsens. Wollen wir in Zukunft, dass einzelne die Deutungshoheit übernehmen dürfen?

Ich will iD nicht aussperren, aber wenn ich Presets basteln kann, wie ich gerade lustig bin und damit das Tagging im großen Stil in OSM beeinflusse, dann ist das in meinen Augen eben gefährlich, da einzelnen Teilnehmern von OSM sehr viel mehr Macht zugesprochen wird. Mir ist klar, dass ich noch immer alle Tags setzen kann, wie ich will, aber gerade in iD werden wohl eher die Presets verwendet und als “Standard” wahrgenommen. V.a. von unerfahreneren Mappern.

+1

+1

Ich hab’ das (=pseudo-boolean namespaces) gerade mal probiertin ID 2.12.2 und raus kam: cousine=pizza;italian
, also das im opening beklagte Verhalten kann ich nicht sehen.

Geht’s hier vielleicht nicht um konkrete Probleme? Ich find’s immer besser wenn jemand erzählt, was er macht, anstelle zu erzählen, wem von denen, die was machen, man reinreden will.

OSM funktioniert halt auch ein bisschen so, dass die Dinge dynamisch sind, und wer befürchtet, dass das WIKI die Tagging-Definitions-Hoheit verlieren könnte der kann doch auch mithelfen, es lebendig zu halten.

Das Board und die DWG sind jedenfall gut beraten, sich das nicht ans Bein zu binden.

ja, die stehen auch im Eingangspost und sind verlinkt. Dieser große Code Block ist eine Kopie eines verlinkten Beispiels. Der Entwickler Bryan Housel selbst schreibt “On my “preference”, both namespaces and semicolons are fine, I don’t have a preference and iD handles both.”. Insofern steht die Tatsache, dass iD diese problematischen “Namespaces” unterstützt auch nicht in Frage.

Du meinst, ich solle einen Thread aufmachen und schreiben, was ich so mache?

wer es selber mal ausprobieren will, sucht mal nach “Autowerkstatt” und wählt dann unter “Raststätte” ein paar Werte aus.
Sieht dann so aus

+1

Eine wunderschöne Fehlübersetzung von „services“, worunter in GB sowohl Dienstleistungen allgemein als auch (als Pluraletantum) eine Autobahnraststätte verstanden wird.

–kd

Da fehlt einfach der Übersetzungskontext, ist also keinesfalls ein fundamentales Problem.

Ich bin auch kein Fan von iD und habe in der Vergangenheit schon mehrfach solche seltsamen Pressets “angemeckert”, z.B. als plötzlich überall Fußgängerbrücken mit crossing=table erfaßt wurden oder als Wege mit völlig verschiedenen Attributen ohne Rückfrage kombiniert werden mit Ergebnissen wie oneway=yes;no und highway=residential;tertiary;residential. Von Brian Housel kommt da immer zuerst irgendwas wie “ist nicht mein Problem, hat der Mapper so entschieden” bis man dann einen Patch liefert, der zeigt, dass das Problem eben doch in iD liegt.
Ich gebe als Entwickler aber auch zu bedenken, dass es oft alles andere als einfach ist, aus den wagen und ungenauen Wiki Texten überhaupt eine Regel abzuleiten, die sich programmieren lässt. Bei den Presets ist das noch relativ unkompliziert, aber bei Prüfungen muss man manchmal als Programmierer einfach mal “machen” und dann abwarten, ob die Community (oder auch nur ein User) sich beschwert. Insofern unterstelle ich Brian Housel zwar ein gewisses Desinteresse an Qualität, aber keine böse Absicht.

Das stimmt, Amerikaner haben für so viele Dinge nur Desinteresse übrig.

Das ist ja hier kein Schau-Laufen und ich hatte ja auch auf einen Post von Pfadfinder geantwortet und nicht von Dir, aber ja: Wenn Du Deinen Faden so aufbauen würdest: “Ich fühle mich in meinem Projekt X/in meinen Bemühungen Y durch Bryan behindert, weil…” dann wäre das überzeugender, und man müsste nicht dauernd abwägen, was Team-Dynamik ist und was inhaltlich motiviert.

Welche Regeln wären denn das genau?

Zum grössten Teil sind ihm die Sachen als PR vorgelegt worden und er hat sie einfach integriert (siehe die Beispiele aus meinem SOTM-Vortrag).

Falsches Tagging durch unzureichede Editor Presets ist weitaus gefährlicher als z.B. ein Bot der ein massenhaft falsch umtaggt. Beim Bot kann man das Problem zumindest gut erkennen und revertieren. Gegen einen Editor ist die Community vergleichbar machtlos, wie wenn ein Bot-Net mit gekaperten Accounts das Umtaggen durchführen würde.

Insofern ist es nicht einsichtig, dass man hohe Anforderungen bei mechanischen Edits stellt, ein Editor aber fast völlige Narrenfreiheit genießt.

Eine Zertifizierung des Editors wäre sicherlich zuviel verlangt, dass würde die Entwicklung nur behindern.

Eine grundsätzlich Forderung wäre Schaden für OSM zu vermeinen. Der Schaden kann dabei vielfältig sein, wobei die ersten beiden Punkte für alle Editoren und die weiteren nur für die Haupteditoren relevant sind:

  1. Direkte Beschädigung der der Daten: z.B. zerbrochende Relationen oder korrektes Tagging beschädigen (z.B. beim Merge)

  2. Erzeugen falscher Daten, wodurch auch vorhandene richtige Daten Ihre Aussagekraft verlieren.

  3. Verhinderung oder Beeinträchtigung, dass sich ein verbessertes Tagging durchsetzt, z.B. weil sich dem Benutzer veraltete Tags auf Basis von Taginfo vorgeschlagen werden. Man kann nicht erwarten, dass die Mehrheit der Benutzer beurteilen kann, dass die Vorschläge schlecht sind.

  4. Beeinträchtigung der Datenqualität dadurch, dass bestimmte Daten schwer oder nicht bearbeitbar sind und somit schlecht gewartet oder gar nicht erst erfasst werden.

  5. Verschwenden von Mapping-Ressourcen durch Ineffizienz

  6. Demotivation von Mappern, z.B. durch unzureichende Funktionalität

Das man auch einen anderen Editor wählen kann, hilft nur eingeschränkt. Die Benutzer werden zumeist nicht rechtzeitig beurteilen können, welchen Editor sie verwenden sollten, bevor sie den Aufwand betreiben, sich in die Bedienung des Editors einzuarbeiten. Wenn die Benutzer unnötigerweise nochmal umlernen müssen, bewirkt dies bereits Schaden nach Punkt 5 oder 6.

Sicher kann man Schäden nichthundertprozentig vermeiden. Wenn den Entwicklern die Schadenvermeidung aber nicht wichtig ist oder nicht ins Konzept passt, ist dies eher inakzeptabel.

Eine sinnvolle Forderung wäre auch, dass es ein neutrales Repository gibt, das nicht dem Hausrecht eines einzelnen Entwicklers oder einer einzelnen Organisation unterliegt. Dieses Repository sollte einerseits die Diskussionsplatform beinhalten, und andererseits sowohl dem Hauptentwickler als auch anderen Personen Pull Request ermöglichen, die dann nach neutraler Diskussion übernommen werden, ggf. auch mal gegen den Willen des Hauptentwicklers. Das Repository sollte von einer Gruppe von Personen aus verschiedenen Regionen verwaltet werden, um zu verhindern, dass die Erfordernisse bestimmter Regionen vernachlässigt werden.

Es wäre hinreichend, wenn dass neutrale Repository nur bestehen muss, wenn die Community dies für den jeweiligen Editor fordert.

Ich möchte gerne betonen, dass das im Fall von slhh nicht nur einfach so dahin gesagt ist, sondern auf sehr viel Interaktion mit Bryan auf Detailebene beruht: https://github.com/openstreetmap/iD/issues/created_by/slhh

Im Fall von iD liegt das Repository zwar in der openstreetmap-Organisation, allerdings ist bhousel effektiv der einzige noch aktive “Member” (das ist im Github Sprech hier die Person mit den weitestgehenden Berechtigungen, “Owner” wäre die openstreetmap-Organisation, die noch mehr kann).

Aus der Anfangszeit von iD haben mindestens noch tmcw, jfirebaugh und aaronlidman die gleichen Rechte - sind allerdings nicht mehr in der iD Entwicklung aktiv und mehrheitlich auch nicht mehr bei Mapbox, und spielen daher eigentlich keine Rolle mehr in der Diskussion.

Es gibt mindestens 5 weitere “Collaborators”, die Pull Requests prinzipiell auch mergen könnten. bhousel hat aber praktisch immer das letzte Wort, da er das Ausrollen neuer Versionen auf osm.org managed.

Prinzipiell ist das nicht großartig anders als in jedem anderen Open Source Projekt, es gibt halt immer einen benevolent dictator (das eine oder andere mal mehr mal weniger).

Usability hat bei iD einen sehr großen Stellenwert, alles was kompliziert ist oder den Anwender ablenkt, wird gerne (auch bewusst) ausgeblendet. Details aus dem Wiki stören da eher - daher enthält die iD Hilfe auch keinerlei Referenz auf das Wiki (!). Das hat alles Vor- und Nachteile. Beim Malen von krummen Gebäuden ist das ganz prima, anderenorts aber nicht immer ideal.