Übernimmt Mapbox die Tagging-Hoheit in OSM?

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

@SunCobalt, danke dass Du das Thema, mal wieder hochholst.

@MKnight: interessantes Beispiel, kann ich derzeit bei mir nicht nachvollziehen, (wahrscheinlich ist bei mir irgendetwas anders eingestellt). Das hängt aber sicher irgendwie mit der Prüfregel zusammen, aus der resultiert, dass Vorschläge für das Hinzufügen von wikidata:brand Merkmalen usw. gemacht werden.

Wenn dann dieses wikidata:brand einmal am Objekt dransteht, dann wird der Umstand zur Verbindung von facebook noch offensichtlicher (auch bei mir im Browser & ublock stehen dann zwei Zeilen “facebook.com” und “graph.facebook.com”), die wohl zum Einblenden der Logo benutzt werden.

Weil mir diese Einblendungen nicht gefielen, hatte ich dieses Thema mal aufgemacht, “keine Werbung in description - iD-Editor Logo brand”: https://forum.openstreetmap.org/viewtopic.php?id=67011

Man kann das zwar rausblocken, aber mit diesem derzeitigen Status bin ich weiterhin nicht zufrieden.
Denn a) würde ich anstatt des herausgeblockten Logo (leere Stelle) dort trotzdem lieber das allgemeine Piktogramm einer Objektgruppe sehen wollen.
Gezeigt am Beispiel bei zwei Objekten mit Merkmal shop=car_repair
Einmal mit wikidata:brand und mit Logo:
https://www.openstreetmap.org/edit?way=313666050#map=19/50.99318/11.31999
Und einmal ohne wikidata:brand und mit allgemeinen Piktogramm für eine Autowerkstatt:
https://www.openstreetmap.org/edit?way=255665270#map=19/50.98059/11.32088
und b) sollte die Logik lieber anderes herum implementiert sein, also standardmäßig keine Logo zeigen und wen die Logo interessieren, dem könnte die Möglichkeit geschaffen werden dies bei Checkbox in einem der ID-Editor Menüs zu aktivieren