Übernimmt Mapbox die Tagging-Hoheit in OSM?

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.

Was meinst Du damit? Beim iD wird bei jedem angebotenen Attribut auf den dazugehörigen OSM-Wiki-Beitrag verlinkt. Man kann also jeweils direkt nachschauen, was man da gerade auswählt und ob die gedachte Verwendung dem entspricht, was aktuell im OSM-Wiki beschrieben wird.

Deshalb hatte ich ja auch von “iD Hilfe” geschrieben, das ist unter dem “?” Icon oder Tastenkürzel “H” zu finden.

Übrigens wird an der Verlinkung zum Wiki gerade herumgeschraubt, wie man hier sehen kann: http://preview.ideditor.com/master - den direkten Link zum Wiki-Artikel gibt es im Moment nicht, es wird nur zum Wikibase-Artikel verlinkt.

Ich glaube, das stimmt so nicht. In der Hilfe (im Kapitel “Objekteditor”) findet sich folgender Text:

(“OpenStreetMap Wiki” und “Taginfo” sind Links)

Seit wann das in der Hilfe steht weiß ich aber auch nicht.

Korrekt ist: im OSM Datenmodell kann man prinzipiell Schäden nicht vermeiden.

Zum Rest: dass ist zwar alles nett, aber wenn man das so umsetzen würde, hätten wir genau 0 Editoren.

iD hat sich m.E. an gewisse Grundregeln zu halten und dazu gehören auch die im Wiki festgelegten Tagging-Regeln. Insofern kann ich

nur unterschreiben.

Dass iD bzw. sein Maintainer sich nicht immer ans Wiki hält, hatte ich schonmal festgestellt: https://forum.openstreetmap.org/viewtopic.php?id=64264. In diesem Thema habe ich zwei Issues verlinkt, die beide durch Bryan abgelehnt wurden. Er hat darauf verwiesen, dass das Tag bereits vor Einführung in iD sehr häufig genutzt wurde. In einem der Issues wurde ihm nachgewiesen, dass das Tag zwar tatsächlich vorher existierte, die Nutzung aber erst seit Einführung in iD sprunghaft angestiegen ist. Insofern hat Bryan hier ein Tag für defacto gültig erklärt, obwohl das Wiki von der Nutzung abrät. Dies wäre ein Beispiel wo aus meiner Sicht die OSMF einschreiten muss.

Ich hatte folgenden Commit im Kopf: https://github.com/openstreetmap/iD/commit/011f351bb7e2c9df18bf6c9c39ea4e617bd6bcb1
(Pull request)- dort ist der Link zum Wiki rausgeflogen. Würde mich aber nicht wundern, wenn man deinen Link auch noch rausnehmen könnte - Bryan hält generell (auch an anderer Stelle) wirklich rein gar nichts vom Wiki.

Gott behüte, dass verschiebt nur die Macht von den Editor-Maintainer zu den Wiki-Fiddlers (und da hab ich es doch lieber bei ersteren).

Die allermeisten Dinge, die von iD in Form von Presets angeboten werden, sind eher unstritige, statische Dinge, die ich jetzt weniger in Gefahr sehen würde, durch Wiki-Änderungen beeinflußt zu werden. Selbst wenn, wäre es einfacher sich ins Wiki einzuarbeiten und sich dort dann mit den “Wiki-Fiddlers” rumzustreiten, als zu versuchen, iD Maintainer zu werden. Am wichtigsten finde ich aber die Funktionstrennung von Editor-Maintainer und Preset-Definition, wer auch immer das dann macht. Das reduziert die Möglichkeiten alleine Dummheiten zu machen doch deutlich.

+1

Theoretisch ja, die Praxis zeigt sich aber eher, dass die meisten Änderungen am Wiki unter dem Radar passieren (auch unproblematische), und es Monate wenn nicht Jahre dauert bis (bin jetzt ganz nett :-)) nicht besprochene Änderungen und solche ohne eindeutigen Konsens entdeckt werden. Die Änderungen an iD und generell allen gebräuchlichen Vorlagensätze sind aber einfach zu verfolgen und finden auch nicht im Geheimen und versteckt statt.

Presets sind wirklich sehr gut dokumentiert: https://github.com/openstreetmap/iD/blob/master/data/presets/README.md
Wenn ich mir so anschaue, wer da alles schon beigetragen hat, sehe ich auch nicht, dass das eine unüberwindliche Hürde sein soll: https://github.com/openstreetmap/iD/commits/master/data/presets

Einige von iD genutzte Sachen sind ja bereits an anderer Stelle zu finden:

Ob das auch mit Presets ginge, müsste man mal eruieren.

gut, nehmen wir mal an, ich möchte das in diesem Thread thematisierte Problem der Pseudo-boolean-namespaces bei service:vehicle korrigieren wollen. Du hast recht, die Doku ist gut.

Der problematische Eintrag findet sich hier: service:vehicle
Laut dieser Doku, Unterpunkt Combo/Dropdown fields * bedeut das
type": “multiCombo” = multiCombo - Dropdown field for adding yes values to a common multikey (e.g. recycling: → recycling:glass=yes, recycling:paper=yes, etc.)

ich würde jetzt also “multiCombo” in “semiCombo” ändern, sprich
semiCombo = Dropdown field for adding multiple values to a semicolon-delimited list (e.g. sport= → soccer;lacrosse;athletics;field_hockey)*

Und das als Pull-Request einreichen und damit wäre das Problem gelöst. Ich würde Wetten auf den Ausgang des Versuchs abschliessen :wink:

Deinen zweiten Punkt finde ich recht interessant. Nicht ganz perfekt, da das auf Github liegt und nicht im Wiki. Aber wenn das dann nicht von Bryan selber gewartet werden würde, wäre ein Großteil der Kritik entkräftet

oh, hier sieht man auch schön, wo das Problem herkommt. Wenn jemand service= auswählt, zieht iD diese Liste möglicher Werte: parking_aisle, driveway, alley, emergency_access, drive-through .

bei einem shop=car_repair, können mit service= aber ganz andere Werte eingeben werden z.B. laut Wiki: dealer, repair parts, tyres, electrical, glass, body ".

Geht jetzt aber nicht mehr, da iD die service= Values nicht kontextabhängig verwalten kann. Also wird der Tag von service= in service:vehicle umbenannt, um ein iD Problem zu umschiffen (unabgesprochene Änderung Nr. 1) und zusätzlich die Werte als namespace eingeführt. (unabgesprochene Änderung Nr 2).

Das Problem ist nicht das iD nicht die Werte für service separat verwalten könnte, sondern das ein multicombo Eintrag ohne Werte dazu führt, dass taginfo abgefragt wird für die Werte, und -taginfo- speichert nicht genug Kontext für (zumindest nicht für alle) tags so das man die Werte weiter eingrenzen könnte:

https://taginfo.openstreetmap.org/keys/service#values

Es gibt aber keinen Grund wieso man nicht separate Dateien mit multiCombos mit den entsprechenden Werten machen könnte, zumindest keinen Grund den ich kennen würde.