Übernimmt Mapbox die Tagging-Hoheit in OSM?

Sowohl Frederik und auch ich wurden an der SOTM 2012 in den Vorstand gewählt, die Nachricht, dass Mapbox die Mittel von der Knight Foundation zugesprochen wurden war praktisch unmittelbar danach, m.a.W. wir wissen nicht wirklich was von den Vorgängen vor der Wahl (ich wurde zwar einen halben Tag oder so vorher informiert, dass das ganze passiert, aber das war rein passiv und wir hatten auch keinen Einfluss auf was in der Pressemitteilung stand, die uns auch nicht vorgelegt wurde). Es sind aber diverse der Vorstandsmitglieder die -vor- den Wahlen im Vorstand waren, noch aktiv, speziell Mikel, die könnte man natürlich fragen :-).

Siehe https://wiki.openstreetmap.org/wiki/Foundation#History_by_year_of_election

Edit: http://newschallenge2.tumblr.com/post/25423109382/making-data-available-new-contribution-tools-for ist anscheinend was DevelopementSeed damals eingegeben hat, wenn ich es richtig verstehe war das im Juni 2012.

Wenn auch nicht völlig ausgeschlossen, so sind die 2 Systeme soweit auseinander, dass es vermutlich nie passieren wird (gibt ja ein Prgrämmschen von mir, dass aus den iD Presets JOSM kompatible produziert, was für Statistikzwecke halbwegs gut funktioniert). Bekanntlich wird ca. die Hälfte der Objekte in den iD Presets durch taginfo Abfragen generiert, insofern sind die Presets ja schon so “benutzerdefiniert” :-).

Jeder Editor kann machen was er will - aber ich bin auch der Meinung, daß ein Editor mit so fragwürdiger Preset- und Taggingfinding einer einzelnen Person nicht der Default für OSM sein dürfte.

Aus den vorherigen Posts klingt es so, als ob eine alternative Version von ID unrealistisch viel Aufwand wäre. Dem ist nicht so. Grundsätzlich erlaubt es ID, einen eigenen Satz von Presets zu laden und den Editor beizubehalten. In der Praxis ist es nicht ganz so einfach, weil die Presets nicht sauber getrennt sind und immer wieder Abhängigkeiten haben und Code angefaßt werden muß. Aber der Aufwand ist vertretbar. Ich habe für meine Karte eine Custom-Version von ID gebaut, mit passendem Stil und eigenen Presets - allerdings spezialisiert und für einfachere Bedienbarkeit mit stark reduziertem Umfang von Presets (z.B. Abbiegerelationen ganz entfernt).

Es wäre also technisch durchaus möglich, eine Version von ID mit “Community Presets” zu bauen und zu pflegen, ohne ID nachzuprogrammieren. Den größten Aufwand sehe ich in der Pflege, weil ID häufige Updates raus bringt. (Ich habe mir das bei meiner Version gespart, da ID bisher keine für mein Thema interessanten neuen Features gebracht hat).

Bleibt nur das Problem was man dann damit tun würde. Der Mapbox-ID hat den Daumen auf der Standardeditor-Einstellung, so daß kaum ein User die Community-Version sehen würde. Ich erinnere mich, daß ID damals massiv gepusht wurde und zum Standardeditor erklärt wurde, obwohl er technisch noch völlig unreif war (z.B. hat er nicht in Firefox funktioniert). Von daher glaube ich kaum daß die Admins der Hauptseite einen “Community-ID” akzeptieren würden.

Wenn wir Mapbox / Bryan Hounsel mal zeigen wollen, wo der Hammer hängt, müssten wir VIELE Github-Konten aufbieten.
Das gleiche gilt übrigens auch für openstreetmap-carto, wo fast alle Deutsche / Ösis, die früher mal beteiligt waren, aufgegeben haben.

Was ich ganz vergessen habe anzumerken: ich glaube nicht, dass sich Mapbox selbst im Augenblick auch nur ein kleines bisschen fürs OSM Tagging interessiert (vermutlich was das letzte von Interesse die automatische Wikidatafizierung) oder OSM überhaupt irgendein wichtiges Thema ist.

OSM ist jetzt nur eine Datenquelle von vielen in einem nicht so wirklich interessanten Geschäftsgebiet und grosse Teile der jetzigen Führungsmannschaft hatten meines Wissens überhaupt nie Kontakt mit “uns”.

Wenn man überhaupt bezüglich externem Einfluss aufs Tagging Bedenken haben müsste, dann wäre ich eher um Radiant Solutions besorgt. Wenn voraussehbar HOT, Mapbox, Telenav etc strategische Zusammenarbeit mit denen verkünden, dann haben wir ein Problem.

Der Teil will mir nicht aus dem Kopf. Das bedeutet, dass OSM und die OSMF nicht weiß, wer bei dem Standardeditor auf der OSM-Website das Zepter in der Hand hat. Der Editor hat Zugriff auf Nutzerdaten und -sofern zugestimmt- auch auf Positionsdaten des Browsers. Sollte man nicht wissen, an wen man sich wenden könnte, wenn solche Daten mal durch einen Fehler oder sonstwas geleakt werden? Übernimmt die OSM(F) nicht eine gewisse Verantwortung und/oder Pflichten, wenn sie [ohne Hinweis] eine Software auf ihrer Homepage einbindet?

Da wird nichts von außerhalb eingebunden. Bryan erstellt regelmäßig einen Pull Request für neue iD Versionen und diese Änderungen werden dann Teil der OSM Webseite. Bryan kann eine neue Version auch nicht selbst aktiv schalten, das macht TomH.

Das ist aber auch nicht anders als bei jedem anderen Editor (mal davon abgesehen das es der “Standardeditor” ist), sprich es werkelt auch via die API und hat nicht einen speziellen Zugriff auf Benutzerdaten.

Bryan war mal klar für die Entwicklung von iD angestellt (straight from the horses mouth), in der Zwischenzeit macht er auch anderes für MB deshalb ist es nicht mehr so wirklich klar.

Ich habe auch nicht geschrieben, dass die Einbidnung von ausserhalb nötig ist, um Pflichten für Software auf meiner Homepage übernehmen zu müssen. Wenn auf meinem Server ein Wordpress-Plugin spinnt und Viren an meine Besucher verteilt, habe ich ein Problem.

Nicht ganz. JOSM muss ich mir aktiv runterladen. Da kann OSM jetzt nichts dafür, wenn da was schief läuft. Potlatch, naja, da ist es etwas einfacher den Verantwortlichen zu bestimmen.

Ich verstehe dein Problem nicht so ganz. iD tickt da exakt wie Potlatch, d.h. die Sysadmins der osm.org-Seite haben die komplette Kontrolle über die Software und können jede Änderung genau nachvollziehen über die Pull Requests. Hier ist Potlatch sogar schlechter, weil nur kompiliertes Actionscript gemerged wird.

ich würde das ungern weiter vertiefen, weil das zu sehr vom eigentlichen Problem wegführt und die Prüfung der Herkunft der Software nur ein Teilaspekt bei einer Abwägung ist, ob man eine bestimmt Software einsetzt. Problematisch ist ja der Umgang mit Presets. Zwar wäre es für mich von Interesse, ob das kritisierte Verhalten bei der Einführung neuer Tags ein privates Problem von Bryan ist oder einer Strategie von Mapbox entstammt und ich denke, dass es bei einer Lösung des Problems helfen würde, die Motivlage zu kennnen, aber wenn man ausser den Ausführungen von Simon nichts bekommen kann, würde ich das jetzt erstmal so hinnehmen.

“verantwortlich” ist so oder so die OSMF auch für die anderen mehrere Dutzend Dependencies die die Website hat. Siehe die typischen OSS Lizenzen (im Falle von iD https://github.com/openstreetmap/iD/blob/master/LICENSE.md)). iD ist auch nicht eine Auftragsarbeit der OSMF, es gibt also auch keinen Vertrag mit irgendjemand, genauso wie für 99% der ganzen Website.

Warum muss ein online-Editor auf OSM überhaupt alles können und dürfen?
Wer gern spezielleres eintragen will kann doch auf andere Editoren zurückgreifen - es gibt sie doch.
Auch das so viele Apps für Datenänderungen zugelassen sind - wie lange haben wir über Fehleintragungen bei wheelchair diskutiert. Ist es richtig, dass einfach massiv Schlüssel/Werte eingetragen werden und dann gesagt wird: “Es wird ja sehr viel verwendet”?

Was soll eigentlich mit diesem Thread erreicht werden?

Zunächst einmal nur Sensibilisierung dafür, dass möglicherweise über einen viel verwendeten Editor durch die Hintertür die Taggingpraxis verändert wird, ohne dass die Community Möglichkeit hatte, sich da einzuschalten. Und Sensibilisierung dafür, dass hinter dieser Veränderung der Taggingpraxis möglicherweise kommerzielle Interessen einen großen Geodatendienstleisters stehen.

Man kann auch mit iD alles Mögliche eintragen, indem man weiter unten die Sachen per Tastatur in die Key-Value-Tabelle einträgt, Autovervollständigung sei Dank reichen dafür meist wenige Buchstaben. Ich arbeite fast nur so, weil ich das meiste, was ich brauche, eh mehr oder weniger auswendig kenne … Was ich noch nicht auswendig kenne, schlage ich im Wiki nach … Die Presets im oberen Teil verwende ich zwar gelegentlich auch, aber eher selten …

Ich bin eh überall die “Meckerziege”, also kann ich mir den Schuh hier auch anziehen und mich hinter SunCobalt. Ich finde den Post richtig und wichtig, auch wenn mir persönlich iD total egal ist.

Ich kann mir auch aus 10 Mailinglisten, einem Forum, irgendwelchen github-Foren und Twitter Informationen zusammensuchen. Das macht die Sache aber nicht besser und die Zeit für OSM wird auch nicht mehr. Fakt ist doch, dass er ein ernstzunehmendes Problem angesprochen hat und die Form ist mir da relativ egal.

Ich finde, es kann nicht sein, dass einzelne Editoren eigene Presets so ÄNDERN, wie sie es gerade wollen. Sie können gerne Presets definieren mit im allgemeinen akzeptierten Tags, aber der Rest sollte über die (verbesserungswürdigen) aber etablierten Prozesse laufen. Dass hinter iD Mapbox steht, wusste ich nicht, macht die Sache aber noch problematischer - egal, wie sehr Mapbox selbst die Entwicklung steuert.

Wenn der Entwickler schon darauf hingewiesen wurde, ist mir auch sehr egal, ob er überhaupt mitdiskutiert. Es ist Sache der OSM Spielregeln vorzugeben und sich nicht Mapbox zu unterwerfen weil iD so beliebt ist. Wir sollten ein Ziel definieren und dann den Weg dahin mit den Entwicklern der Editoren abstimmen. Schafft es die OSMF jetzt nicht, eine klare Linie vorzugeben, öffnet das jedem Tür und Tor, seine eigenen Vorstellungen auszuleben und die OSM-Institutionen (=Wiki,…) auszuhebeln.

Ich halte das insgesamt für eine bedenkliche Entwicklung und finde gut, dass SunCobalt dies hier anspricht!

Die OSMF hat bislang keine Vorgaben in dieser Sache gemacht. Weder hat sie verfügt, dass der ID-Editor der Default-Editor auf openstreetmap.org sein soll, noch hat sie irgendwelche Regeln erlassen, nach denen die Community sich bei der Festlegung von Tags richten soll.

Zwar ist die OSMF theoretisch die Betreiberin der Webseite, und wenn der OSMF-Vorstand verfügen würde, dass der ID-Editor jetzt nciht mehr auf openstreetmap.org angepriesen werden soll, dann könnte man das durchsetzen (je nachdem, wie ungeschickt man es macht, würde man dabei vielleicht den einen oder anderen Server-Admin verlieren). Oder die OSMF könnte Regeln erlassen, was ein Editor tun muss oder nicht tun darf, um auf der Webseite gelistet zu werden, und daraus dann Forderungen an ID ableiten. Da fängt es allerdings schon an - man kann kaum von einem Editor fordern, dass er sich immer nach dem Wiki richten muss, denn allen guten Mühne zum Trotz steht da oft auch Mist drin. Wonach also muss sich ein Editor richten… nach dem “Community-Konsens”? Und wie wird der bestimmt?

Bislang gibt es keinen “Zertifizierungsprozess”, den neue Software durchlaufen muss, die die API anspricht, d.h. Tür und Tor sind tatsächlich offen, und jeder kann seine eigenen Vorstellungen ausleben. Siehe zum Beispiel “StreetComplete”, das bei seiner Erfindung ja durchaus für Kritik gesorgt hat, inzwischen aber, so scheint mir, für viele ein geschätztes Tool ist und die meisten Kinderkrankheiten überwunden hat.

Wünschst Du Dir eine Welt, in der sowas wie StreetComplete erst eine Genehmigung vom OSMF-Vorstand bekommen muss, bevor es veröffentlicht werden darf? Das ist durchaus ein möglicher Standpunkt, für den sich Argumente finden lassen, aber es lassen sich auch welche dagegen finden.

Ich persönlich würde eher dazu neigen, zu sagen, dass alles erstmal erlaubt ist, bis man es explizit verbietet, weil es Schaden anrichtet.

Bei ID ist die Situation halt speziell, weil ID nicht nur ein Editor ist, den jemand auf seiner Bastelwebseite betreibt, sondern weil ID als Standard-Editor auf openstreetmap.org verlinkt ist. Bezieht sich Deine Forderung, eine klare Linie vorzugeben, nur auf derart “offiziell beworbene” Anwendungen?

Bye
Frederik

Das ist ein Mangel. Es sollte eine Arbeitsgruppe geben, die klare Tagging-Regeln erarbeitet (eine Art “Gold-Standard”). Dies natürlich zusammen mit der Community und nicht Zwanghaft für alle Tags. Aber eine Abdeckung von circa 90% sollte langfristig schon erreicht werden.