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.
müsste dann nicht sowohl das umtaggen von service= in vehicle:service als auch die Namespace Sache behoben sein? Problem ist, dass die Definition der service=Values für shop=car_repair unter
iD/data/presets/fields/service/vehicle.json
liegt und für highway=service unter
iD/data/presets/fields/
Zum schauen obs wirklich tut, kommst du vermutlich nicht drumherum lokal eine iD Instanz zu haben oder mindestens den build Prozess soweit laufen zu lassen, dass die Dateien generiert werden die iD dann wirklich verwendet. Sprich presets.json und fields.json
was sind “OpenStreetMapUS developers”, die da in dem von Frederik eingebrachten Twitter-Posting erwähnt werden und an einem von Facebook organisierten Meeting mit Mapbox und Radiant teilnehmen?
Weiter oben wurde das Beispiel service:vehicle:* erwähnt.
Ein anderes Beispiel wäre crossing=marked (highway=crossing) als Vorlage für einen Fussgängerübergang mit Zebrastreifen. Wie schaut dazu die analoge JOSM-Vorlage aus?