Übernimmt Mapbox die Tagging-Hoheit in OSM?

+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.

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.