Übernimmt Mapbox die Tagging-Hoheit in OSM?

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.

wenn ich die vehicle.json so abändere


{
    "key": "service", 	# vorher vehicle:service
    "type": "semiCombo",
    "label": "Services",
    "options": [
        "dealer",
        "repair parts",
        "tyres",
        "electrical",
        "glass",
        "body",
    ]
}

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

Nur nebenbei, mir waren die Arten des Erfassens von Dienstleistungen auch aufgefallen und ich hatte damals dieses Diskussionsthema aufgemacht:

https://forum.openstreetmap.org/viewtopic.php?id=62137 - “Definition von Dienstleistungen (Fahrradladen vs Autohaus)”

Es hatte sich nicht viel daraus ergeben. Von daher bin ich froh, wenn Ihr das hier nochmal angeht :slight_smile:

Zur Frage, ob an iD ehrenamtlich oder als Teil der Arbeit für Mapbox gearbeitet wird, gibt es klare Hinweise:
https://twitter.com/quincylvania/status/1084932787067645954?s=21

Das sagt natürlich noch nichts über inhaltliche Vorgaben aus.

Und auch nicht, dass er von MB bezahlt wird.

Laut Linkedin arbeitet er seit Dezember 2018 für die Firma Gritgen an iD…als Job. Von der Firma habe ich noch nie etwas gehört.

Zum Thema: https://github.com/openstreetmap/openstreetmap-website/pull/2122#issuecomment-456900749

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?

Simon hatte Radiant schon erwähnt. Hier gibt es einen Artikel von Radiant, was hinter diesen in iD implementierten MapRules steckt: https://medium.com/radiant-solutions/maprules-custom-tagging-presets-and-validation-rules-for-openstreetmap-581f8fa6df3d

Bryan Housel (bhousel) und Quincy Morgan (quincylvania), also die zwei iD-Hauptverantwortlichen:
https://github.com/openstreetmap/openstreetmap-website/pull/2122#issuecomment-456926088

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?