[Entwurf] Gemeinsame Position zur Zukunft des iD-Editors

Hallo in die Runde,

ich bin kein Hacker oder sowas, ich will das Auto fahren und nicht mit dem Schraubenschlüssel daunter liegen müssen.
Ich will den Computer einschalten, OSM aufrufen und mit dem Mappen beginnen.
Es ist schon schlimm genug, dass man Farbcodes von Paint-Net abtippen muss.

Potlch 2 kann nicht viel und schaltet ab, wenn man vergrößern müsste.

JOSM ist viiiiiiiiiiiiiiiiiiiel zu technisch; wer nicht Ingenieur ist, findet dort nicht zu recht.
Dazu hat JAVA mit einen Wurm aufgeladen, der meinen PC völlig blockiert hatte.
Der Techniker hatte EURO 100,-- kassiert, um meinen PC wieder gangbar zu bekommen.
Also JAVA ist bei mir nicht mehr vorhanden. Somit ist JOSM völlig außen vor.

Und wenn tausende “JOSM, JOSM über alles!” sagen. Mit mir nicht!

Mir graut es sehr, wenn ich hier lese, welche Zusatzprogramme man für JOSM noch alle benötigt.

Ich will mich nicht zu JOSM zwingen lassen!!

Firmenlogos gehören allerdings nicht in OSM.
Und schon gar nicht Verbindungen zu facebook, twitter und Co.!

Und einen “Knopf” für Relationen vermisse ich auch immer noch.
Nach Relationen hacken tue ich jedenfalls nicht.

Doch ohne iD werden dann sehr viele Mapper ihre Arbeit an OSM beenden.

Michael!

Ich glaube nicht, dass hier irgendwer iD abschaffen will.

Schliesse mich den nicht repräsentativen Kritikern an.

Hallo,

Ich lehne es ab, iD abzuschaffen oder ihm den Status des Standard-Editors auf openstreetmap.org zu entziehen. Das wäre effektiv ein Aussperren neuer Mapper und manche bestehende, aktive Mapper (z.B. WegefanHB) würden uns dann auch fehlen. Das Problem an iD ist dessen Projektmanagement/Projektleitung und deren Entscheidungen, die von Respektlosigkeit geprägt ist.

Viele Grüße

Michael

Du hast das Ganze total missverstanden.

iD soll weiter “leben” nur nicht in der Version, die gerade aktiv ist. Da die “offiziellen” Entwickler von iD sich immer mehr einen Sch… um die Community scheren, ist ein Fork sinnvoll - und auch machbar.

Gruss
walter

Natürlich. Es geht auch nicht darum, iD abzuschaffen. Natürlich muss ein einfacher Editor bleiben, mit dem auch weniger technisch orientierte Mapper klarkommen.

Es geht darum, iD auf Gemeinschaftsstandards zu verpflichten und der Community unterzuordnen. Es geht darum, dass iD nicht als Werkzeug missbraucht wird, um Standards zu ändern oder neu einzuführen (indem z.B. iD ungefragt Änderungen am Mapping vornimmt, von denen man hinterher sagen kann „ist schon xyz-mal so gemacht worden“).

Ich persönlich wünsche mir zum Beispiel, dass iD nicht alle Anfänger geradezu dazu einlädt, an alle Ecken TRs und access-Tags zu setzen, ohne genau verstanden zu haben, was das in der Auswertung bedeutet (z.B. das beliebte access=yes an hw=track, das der unbedarfte iD-Nutzer als „ist nicht gesperrt“ auffasst, das de facto aber „für sämtliche Verkehrsarten frei“ heißt und alle defaults außer Kraft setzt).

–ks

Dann geht doch bitte diesen Weg.
Soll die Gemeinschaft die Standards definieren und soll definiert werden, dass sich Editoren daran halten müssen. Editoren sollten meiner Ansicht nach ähnlichen Regelungen unterliegen wie mechanische Edits.

Aber ihr versucht hier gerade, die aktuellen iD-Maintainer loszuwerden, in der Hoffnung, dass danach alles besser wird.

Ich stimme mit vielen Punkten aus dem Eingangsposting überein. Auch mir sind die vielen Alleingänge ein Dorn im Auge.

Die Sache mit dem Fork bringt mich aber ins Grübeln. Ich höre das erste Mal vom “Fork von Frédéric Rodrigo”. Kann einer was dazu sagen?

Wenn ich mich recht entsinne stehen die iD-Hauptentwickler bei einer Firma (war es Mapbox) in Lohn und Brot und bekommen die Aufgabe in ihrer Arbeitszeit an iD zu arbeiten. Und ich finde, generell machen sie einen guten Job, was das angeht. Von den Funktionen hat sich iD enorm weiterentwickelt in den letzten Jahren. Würde an einem Fork auch so intensiv weitergearbeitet werden in der Zukunft? Manch andere OSM-Projekte sind ziemliche Onemanshows und siechen dahin. Ich hätte starke Bauchschmerzen, die Hauptentwickler rauszujagen und zu sagen, es wird schon gehen.

Na ja, ein bisschen aus der Erfahrung das die aktuellen iD-Maintainer nicht so offen sind für Kritiken und Anregungen.
IMHO ist es auch eine bessere vorgehensweise erstmals den aktuellen iD-Maintainer deutlich zu machen das dies ein Communityprojekt ist und das sie sich bitte an deren Regeln halten sollen.
Erst wenn das scheitert würde ich ein Fork befürworten.

In meinen Augen hatte ID von Anfang an eine Schieflage. Er wurde mit Gewalt als Standardeditor für die Hauptseite von OSM gepusht, obwohl er anfangs technisch bei Weitem nicht ausgereift genug dafür war (z.B. unbenutzbar langsam in Firefox). Auch wenn ich die genauen Hintergründe nicht kenne, ist sowas nur mit Politik oder Vitamin B zu erklären.

Für die aktuelle Diskussion sollte man sauber zwischen zwei Themen trennen:

  1. der Editor ID als Programm steht nicht im Fokus der Kritik und kann so unverändert in Gebrauch bleiben. Es muß also nichts entfernt oder aufgegeben werden.
  2. die Voreinstellungen (Presets) und Fehlermeldungen weichen teils erheblich und sehr eigenwillig von dem ab, was als üblich gilt, dokumentiert ist oder bei Diskussionen als Ergebnis herauskommt und der Input der Community wird ignoriert. Dazu kommen noch irreführende Übersetzungen als Problem. Dieser Teil ist so nicht tragbar und müßte durch eine größere, internationale und community-bedachte Gruppe gepflegt werden.

Wichtig dabei ist zu wissen, daß die beiden Teile ziemlich gut von einander trennbar sind und es keinen wirklichen technischen Grund gibt, warum das dieselben Leute machen müssten. Von daher werden die Hauptmaintainer nicht von ID ausgeschlossen, lediglich die Pflege der Voreinstellungen übernimmt jemand anders. Ich habe für meine Webseite bereits vor einer Weile einen Fork von ID gebaut, ein paar für mich unnötige Features entfernt und vor allem die Voreinstellungen so umgebaut und ergänzt, daß die Tags für das Wandern und Reiten leicht zu finden sind. Ich kann also aus praktischer Erfahrung sagen daß es kein Problem darstellt, es müßte aber für die OSM Hauptseite kontinuierlich gepflegt werden.

Das größte Problem sehe ich darin, einen fertigen Community-ID auf die OSM Hauptseite zu bekommen - das ist wieder Politik. Von daher begrüße ich diese Initiative. Vielleicht sollte man sie gezielt international ausweiten. Soweit ich mitbekommen habe, werden Vorschläge aus Deutschland sowieso nicht gerne aufgenommen, weil “die Deutschen sowieso alles viel zu kompliziert machen”. :slight_smile:

Es sind demnächst Vorstandswahlen. Die Kandidaten sollten sich zu dem Thema äußern. Die Community (setze ich hier gleich mit den OSMF-Mitgliedern) wählt dann einen neuen Vorstand, welcher dann das Problem löst.

Doch, genau das ist das Ziel. Selbst wenn es theoretisch möglich wäre, dass die Maintainer weiterentwickeln; wenn ein Fork durchgesetzt wird, werden sie dem Projekt sofort den Rücken kehren und sich einen neuen Job suchen.

Es ist trotzdem nicht das Ziel, es ist höchstens eine mögliche Konsequenz. Wenn du behauptest, genau das sei beabsichtigt, ist das eine Unterstellung. Für mich ist selbstverständlich, dass sich die in iD angewendeten Presets und Taggings dem in der Community Üblichen unterzuordnen haben, und wenn sie das nicht tun, dann muss man es ihnen klarmachen oder es jemand anders machen lassen.

Was schlägst du alternativ vor? Alles so lassen, wie es läuft, und die iD-Maintainer bestimmen demnächst, was in OSM wie getaggt wird? Geht auch nicht.

–ks

Darf man sich outen - ohne aufgespiest zu werden?

ID ist so erfrischend einfach, wenn man einfach mappen will. Die Spezialschluessel sieht man nur, wenn man hinguckt. Wenn man sich nicht jedesmal in detailversessene Mappingaktivitäten einlesen will, gibt der Editor erfrischende Vereinfachungen her.

Beispiel: Auf dem Weg ist eine Schranke. Man sucht in ID nach Schranke und setzt den Punkt. Dann wird man noch gefragt, wer da durch darf. Nicht mehr.

Bei JOSM hat man ständig den Eindruck, man muesste noch definieren, ob die Schranke nach oben oder zu Seite öffnet (lift_gate, swing_gate), aus welchem Material der Schlagbaum besteht und soweiter und soweiter.

Zumindest ich verbrauche da jedesmal sehr viel Energie - denn auch das Entscheiden, etwas nicht zu mappen, ist ja eine aktive Entscheidung.

Und ehrlich gesagt ich wuensche mir mehr davon - nicht weniger. ich will einen Bach in die Karte eintragen können und den auch ueber eine Strasse ziehen wo ein intelegientes Programm nicht davon ausgeht, dass Strassen normalerweise von Bächen ueberschwemmt sind, sondern klar ist, dass die irgendwie ueberbrueckt werden - und nur in Spezialfällen abfragt, ob das anders ist.

ich will ein Waldgebiet an einem See vorbeifuehren können und ein intelligentens Programm haben, dass weis, dass normalerweise in Seen kein Wald wächst - und nur in Spezialfällen das anders getaggt werden kann.

Und diese Beispielsreihe kann ich weiter fortsetzen.

Dass das nur geht, wenn den Entwicklern die Möglichkeit gegeben wird, die Usuability vor die Taggingreligion zu setzen, ist doch klar. Dass das am besten in einem gut moderierten Prozess geschieht, sollte genauso klar sein.

Das die Gruppen, die sich speziell fuers Tagging interessieren, allerdings nicht die einzige Referenzgruppe sein kann ist auch klar.

Verbleibt bei mir das komisch Gefuehl, etwas zu mögen, was durchaus seine problematischen Seiten hat.

@tox-rox Weg eines Goldstandartes finde ich, wenn man gleichzeitig nach radikalen Vereinfachungsmöglichkeiten sucht, sehr vielversprechend.

Um wieder auf das Beispiel zu kommen: Fuer mich ist eine Schranke an einem Waldweg vorallem ein Hinderniss fuer bestimmte Nutzungsarten. Mir fällt keine Anwendung ein, wo es fuer mich wichtig sein könnte, zu wissen wie sie öffnet. Und dass ID hier mir eine einfache Möglichkeit gibt, mich nicht drum zu kuemmern ist toll. Denn die Nutzer alleine mit der Frage “was mache ich denn, wenn mir das egal ist” zu lassen, ist auch nicht gerade gut. Mir ist schon klar, dass ich durch ID jetzt massenweise eigentlich “falsche” Einträge in die Datenbank schreibe (Schranke gibt es ja nicht ohne Details). Aber die Usability rechtfertigt auch irgendwann solche Vereinfachungen.

Die Posts von woodpeck + Nakaner bestehen größtenteils aus (durchaus begründeter) Kritik an den Maintainern selbst, verknüpft mit der Forderung nach einem Fork.

Also nochmal ganz klar: Absicht von woodpeck + Nakaner ist es, die iD-Maintainer loszuwerden.

Meiner Meinung muss das Problem dadurch gelöst werden, dass der OSMF-Vorstand Regeln für Editoren aufstellt. Wenn sich die iD-Maintainer anpassen, ist’s ok. Wenn nicht, muss man die hier geforderten Maßnahmen durchziehen.

Hallo,

es ist nicht meine Absicht, die iD-Hauptentwickler vom Hof zu jagen, sondern sie von den Verpflichten zu entlasten, die sie nicht zur allgemeinen Zufriedenheit erfüllen können.

Wiederholt sind Entscheidungen der iD-Maintainer auf den Mailinglisten Talk und Tagging diskutiert worden. Mehrmals war die Meinungslage auf den Mailinglisten eindeutig (einstimmig oder fast einstimmig). Zwei deutliche Beispiele:

Fast einstimmige Diskussionen auf Mailinglisten sind die Art, wie bei OSM Entscheidungen getroffen werden, wenn nicht abgestimmt wird.

Ich will die Maintainer nicht vollständig entmachten, aber ihre Macht einschränken. Es sind eigentlich Dinge, die mit dem Tagging zu tun haben, bei denen es regelmäßig Krach gibt. Was liegt näher, als sie von dieser Aufgabe zu entlasten?

Der Begriff “Fork” ist unpassend. Die iD-Ausgabe von Frédéric Rodrigo sollte eigentlich “iD Community Consensus Edition” (iD Community-Konsens-Ausgabe) heißen. Es ist ein iD-Editor mit ein paar wenigen Patches. Fork ist nicht der richtige Begriff, es ist ein Softwarepaket, das ein Distributor geringfügig modifiziert. Frédéric hat das geändert, was auf https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions kritisiert wird. Der Quellcode ist unter https://github.com/frodrigo/iD zu finden. Ihr könnt ihn unter http://id.openstreetmap.fr/ nutzen.

Ich schlage vor, seine Ausgabe zu nutzen, bis die Taggingvorlagen und Validatorregeln in unabhängige Projekte unter Community-freundlicher Kontrolle überführt sind. Die Verwendung von Frédérics Ausgae ist eine Übergangslösung. Falls das nicht deutlich genug aus meinem Text hervorgeht, dürft ihr das gerne korrigieren.

Dem kann ich nicht widersprechen. Die Herausforderung ist hier, dass die Maintainer der OSM-Hauptseite auf GitHub die iD-Ausgabe wechseln. Ein einfach hingeklatsches Pull-Request wird wahrscheinlich abgelehnt werden. Wenn jedoch nationale Communitys Druck machen, aber erst recht, wenn der Vorstand sie anweist, einen anderen iD zu nutzen, ist ein Wechsel der iD-Ausgabe (oder zumindest kein einfaches Ausrollen neuer Releases der Bryan-Quincy-Ausgabe) zu erwarten. Die Maintainer der Hauptseite wollen niemanden gegen sich aufbringen und so ist es nachvollziehbar, dass sie nicht entscheidungsfreudig sind.

Ich möchte jetzt erst einmal wissen, ob mein Vorschlag die Meinung der deutschen Community gut genug abbildet. Ich habe absichtlich nicht direkt den Weg in die englischen Kanäle gewählt, weil mir dort sofort amerikanischer Wind entgegenbläst. Es steht anderen nationalen Communitys (hallo linksrheinischer Nachbar) frei, selbst etwas Ähnliches wie wir zu tun. Wenn sich die Diskussion hier gelegt hat und ich die Änderungsvorschläge eingearbeitet habe, werde ich den Text ins Englische übersetzen.

Zur Erinnerung: Es sind schon weltweite Importe eingestampft worden, weil große nationale Communitys für ihr Gebiet widersprochen haben. Selbst ein gewisser britischer Mapper, der bislang Ja zu jeder Firma in OSM gesagt hat, ist mittlerweile nicht mehr über das Verhalten der iD-Maintainer begeistert. :roll_eyes:

Solch einen Vorschlag habe ich zeitweise in Erwägung gezogen, aber aus zwei Gründen verworfen:

  1. Es betrifft auch alle anderen Editoren und wirkt gegenüber neuen Entwicklern nicht wirklich einladend.
  2. Die Diskussion solch einer Richtlinie wird sich, wenn es richtig flott geht, über ein halbes Jahr hinziehen, wahrscheinlich dauert es aber eher zwei Jahre. Zwei Jahre, in denen die iD-Maintainer weiter schalten und walten können. Währenddessen werden gewissen Gruppen sich massiv und vermutlich auch erfolgreich dafür einsetzen, die Regeln weichzuspülen. Am Ende haben wir ein Dokument, das eine wirkungslose Absichtserklärung/Selbstverpflichtung ist.

Viele Grüße

Michael

… was mich ja mal zu einer Bemerkung provoziert hatte, dass sie dabei ihre journalistischen Standards gefährdet.

Bryan’s Punkt ist doch, dass die Diskussionskanäle der “Community” von Trollen gekapert sind und er an solchen Diskussionen kein Interesse hat.

Darauf muss man doch auch mal eingehen und hier nicht schon wieder das Bild zeichnen, es gäbe hier “die community” und da die paar Querulanten.

Es ist halt schwierig, und dass es nicht “den Mapping Standard” gibt, weder im Wiki noch sonstwo, ist ein Ausdruck davon, und daran könnte man doch ganz unabhäbgig mal arbeiten, ohne sich jetzt willkürlich paar Sündenböcke rauszupicken.

Forderungen nach einem Branch-Wechsel für ID auf der Hauptseite sollten nur Leute stellen, die sowas selber online haben und glaubhaft machen, dass das mehr als ein Eintagsfliege ist.

Das an sichselbst ist nicht verkehrt. Sicher als userinterface für Leute die sich nicht in JOSM reintaufen möchten. Das Problem erscheint wenn der Editor dan z.B. alle diese Tags ohne weiteres auf das Objekt setzt, ohne rücksicht zu nehmen auf welche Tags als standard gesehen werden oder nicht.

Eine Schranke wäre vielleicht nicht der beste Beispiel, aber wenn der Benutzer mit iD einen road=unclassfied zufügt, dann angibt das eigentlich jeder den benutzen darf und iD dann den ganzen motz an foot=yes, bicycle=yes, motor_vehicle=yes usw. auch auf das Objekt setzt, dann ist das nicht wie es sein soll. Das ist überflüssig und leitet bloß zu mehr daten die runter geladen und z.B. von routern ausgewertet werden müssen.

Ein anderes problem ist das iD automatische änderungen macht wenn das Object geändert wird. Änderungen die nicht im allgemeinen von der Community unterstützt werden.
Dafür kann der benutzer von iD nichts, und es ist keinen direkten grund direkt den gebrauch von iD zu sperren, aber sicher um die Maintainer mal an zu sprechen.

Vielleicht ist es nicht dein Vorsatz, dann aber nimmst du es willentlich in Kauf, was auf’s selbe rauskommt. Denn genau das wird passieren.

Es ist eine Kopie vom Original. Die Änderung sind solche, die die anderen Maintainer erklärtermaßen nicht haben wollen. Und diese neue Version soll auf osm.org installiert werden. Natürlich ist das ein Fork.

Die “Übergangslösung” hält solange, bis sich die Original-Maintainer anpassen oder bis sie das Projekt verlassen. Letzteres wird ganz schnell passieren.

Natürlich betrifft es auch andere Editoren, und das ist auch gut so. Die Regeln müssten sinnvoll und flexibel sein, so dass Entwickler nicht abgeschreckt werden.

Die Gefahr ist natürlich realistisch, wenn man sich z. B. das Debakel um die Organised Editing Guidelines anschaut. Aber dann müssen wir zusehen, den Vorstand geeignet zu besetzen und eine vernünftige Editor-Policy durchzusetzen.

Ich würde es vorziehen, wenn du auf Polemik verzichten könntest. Wenn die Community festlegt, wie etwas zu taggen ist, dann ist das keine „Religion“, sondern Konvention. Auch dass wir Autobahnen highway=motorway nennen und nicht fid7e8=hhdje61, ist Konvention. Beides geht technisch, aufs erste hat man sich geeinigt.

Und Usability gehört nie und nimmer vor Taggingkonvention gesetzt! Weil nur die Konventionen unsere Daten auswertbar machen und halten.

Nochmal: Niemand hat etwas dagegen, dass iD einfach zu bedienen ist. Das kann und soll gern so bleiben.

Es geht hier gegen die Angewohnheit der iD-Entwickler, ohne Diskussion und Konsens Dinge einzuführen, die nicht etabliert sind und nirgends kommuniziert wurden. Das fängt schon mit diesen furchtbaren _1-Tags an (setzt du an ein amenity noch ein amenity, taggt iD das zweite als amenity_1=* – oder hat es jedenfalls mal gemacht, es gibt noch genug Beispiele davon in der Datenbank). Das wurde nie diskutiert und wird nirgends ausgewertet, es wird einfach mal so eingebaut. Das ist keine Art, sich mit einer Software an einem Communityprojekt zu beteiligen, oder?

Und ich behaupte, dass iD auch dann, wenn es sich an etablierte Taggingstandards hält, so einfach bedienbar bleiben kann und nicht zwingend kompliziert wird. Von da her ist „einfach“ und „kompatibel“ kein Widerspruch.

–ks

Das muss alle Editoren betreffen, sonst hat man immer wieder die selbe Diskussion. iD ist ja “nur” die Spitze des Eisbergs.