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.
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:
Direkte Beschädigung der der Daten: z.B. zerbrochende Relationen oder korrektes Tagging beschädigen (z.B. beim Merge)
Erzeugen falscher Daten, wodurch auch vorhandene richtige Daten Ihre Aussagekraft verlieren.
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.
Beeinträchtigung der Datenqualität dadurch, dass bestimmte Daten schwer oder nicht bearbeitbar sind und somit schlecht gewartet oder gar nicht erst erfasst werden.
Verschwenden von Mapping-Ressourcen durch Ineffizienz
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.
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.
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.
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.
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.
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
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:
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.