Übernimmt Mapbox die Tagging-Hoheit in OSM?

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?

Das wurde jüngst geändert. Vorher wurde crossing=zebra von iD gesetzt, genauso uneindeutig dokumentiert (laut Wiki eigentlich eher crossing_ref=zebra).

Mir ist ggf. dazu auch etwas passendes aufgefallen.
Es scheint, als ob ein neuer Verweise zur WikiBase hinzukam.
Habe aber ein neues Thema aufgemacht, weil es für mich interessant ist und ich nicht genau weiss, ob es hier dazu passt, siehe:
iD Editor - Verweise zur OSM-wiki und nun zur OSM-wikidata (WikiBase) - https://forum.openstreetmap.org/viewtopic.php?id=65202

Vor 10 Monaten schrieb ich hier

Neben Unverständnis für die Frage war eine Antwort, dass

Jetzt steht im Wiki, dass iD ohne den Nutzer zu informieren Nutzerdaten an Facebook überträgt. Vielleicht kann jemand sagen, warum keine Informationspflicht oder Meldepflicht besteht. Als nicht Experte würde ich da auch keine rechtliche Pflicht rauslesen. Dann bliebe noch die Frage, ob es in einem Projekt wie OSM nicht eine moralische Pflicht gibt, die Betroffenen zu informieren.

btw das oben verlinkte Meeting war am 12.09… Ich finde nichts darüber, ob das mittlerweile behoben wurde

es gab kürzlich noch weitere Neuigkeiten zu iD, Frederik hat Quincy Morgan auf der SotM nach seinem Auftraggeber gefragt, und die Antwort war Critigen LLC, so dass es also neben Mapbox auch Critigen sein könnten, die ggf. Einfluß auf die iD-Entwicklung nehmen möchten :wink:

Ich habs gerade in meinem Adblocker gesehen:

graph.facebook.com/DeutscheBank/picture?type=large

Zum Reproduzieren:
https://www.openstreetmap.org/edit?editor=id&node=255595602#map=19/50.97863/11.32995

  • Fehlermeldung via “Aktualisieren” “wegklicken”
  • Profit

Critigen ist eine Beratungsbude, die Wahrscheinlichkeit, dass sie von sich aus ein paar $100’000 pro Jahr in ein weiter nicht verwertbares Projekt stecken ist ~0 (wenn das so wäre würden Sie es wenigstens werbemässig bis zum geht nicht mehr ausschlachten, was sie aber auch nicht tun).