Zustand von iD

Nachdem ich iD bisher mehr oder weniger ignoriert hatte, habe ich ihn mir jetzt mal sehr intesiv angesehen, weil ich einen Ersatz für meinen individualiserten Potlatch2 brauche. Dabei gab es einige Aha-Momente, denn er war irgendwie ganz anders als ich es erwartet hatte.

  • die Grundbedienung empfand ich als ganz angenehm
  • an einigen Stellen enthält er sehr elegante Lösungen wie z.B. das teilweise Füllen von großen Flächen, die automatische Auswahl von lokal unterschiedlichen Eingabemasken für Adreßformate oder der integrierte Editor für Abbiegeverbote
  • ich hatte immer im Kopf daß iD besonders Anfängerfreundlich sein sollte, aber auf mich wirkt er mit den zahlreichen Funktionen und Diensten eher überladen (Mapillary, Openstreetcam, Spezialfunktionen direkt im Rechtsklickmenü, Relationseditor, laaaange Eingeabemasken)
  • aber was mir Sorgen bereitet sind die Presets und Übersetzungen. Bei den Presets für Wanderwege z.B. fehlen elementare und seit ewigen Zeiten dokumentierte Felder wie Wandermarkierungen oder Streckenlänge. Manche übersetzungen sind irreführend oder verwenden ungebräuchliche Fachsprache ( “Fabrikgelände” für landuse=industrial, “Geschäftsgebiet” für landuse=retail, “abgelegene Siedlung” statt Einzelgehöft für isolated_dwelling, “Hangschutt” für Geröll usw.). Für den einfachen Suchbegriff “Bergwerk” wird kein Preset gefunden (es gibt einen für “adit” aber mit exotischeren Alternativnamen). Manche Themen sind gar nicht abgebildet, z.B. Schutzgebiete und Nationalparks.

Wenn ich bedenke daß iD von 61% der Mapper benutzt wird, macht mir das echt Sorgen. Wenn Anfänger von unvollständigen Presets und irreführenden Bezeichnungen verwirrt werden oder in bester Absicht das Falsche anklicken, bekommen wir Tausende von knapp-vorbei-ist-auch-daneben Einträgen.

Ich habe für meinen Teil vor, pull requests für die Themen Reiten, Wandern und historische Gebäude zu machen, wenn ich mit meiner Individualiserung durch bin. Die oben genannten Übersetzungen habe ich schon verbessert.

Ich will hier aber auch nochmal an alle Experten und Poweruser appellieren, bei Gelegenheit mal ihren JOSM beiseite zu legen und sich Ihr Interessen- und Fachgebiet in iD anzusehen und ggf. Tickets einzustellen oder selbst Hand anzulegen wenn Presets unvollständig oder unrealistisch erscheinen oder eine Übersetzung Stirnrunzeln oder Erheiterung auslöst.

bye, Nop

Vielen Dank für Deinen ausführlichen Bericht!

Es ist sicher gut, wenn Du pull requests für Dinge erstellst, die unbedingt geändert werden sollten.

Ich habe allerdings im Hinterkopf, mehrfach gehört zu haben, dass die (der?) iD-Entwickler nicht besonders gerne auf Fehlermeldungen und Verbesserungsvorschläge eingehen (eingeht). Weiß jemand, ob das (inzwischen) falsch ist bzw. ob sich die Situation gebessert hat, sodass sinnvolle Fehlermeldungen bzw. Verbesserungsvorschläge zu iD tatsächlich eine realistische Chance haben, in naher Zukunft berücksichtigt zu werden?

Einfach ist es nicht, eine realistische Chance ist aber durchaus gegeben. Die Chance an Uneinsichtigkeit zu scheitern, ist aber nicht minder groß. Ein Problem scheint mir dabei auch die Beurteilung aus US-Sicht, also einem Gebiet mit einer wenig aktiven Community und damit entsprechend geringer Datendichte zu sein, und auch aus Sicht von jemandem, der nie mit JOSM gearbeitet hat. Dann kommt natürlich auch noch die Prioritätssetzung hinzu, der ich nur sehr eingeschränkt zustimmen würde.

Wegen dem von mir fett gemachten, benutze ich iD ab und zu. Man kann schnell abchecken ob es Bilder gibt oder nicht. In JOSM schmiert mir das Plugin regelmäßig ab. Ich nehme aber kaum Änderungen mit iD vor, weil die GUI für mich doch sehr grenzwertig ist.

Hi,

eins der größten Probleme von iD ist und blebt die nicht ausreichende Unterstützung von Relationen. Ein Sortieren von Mitgliedern ist nicht möglich (obwohl es sicher per drag-and-drop implementierbar wäre) und beim Aufteilen von Ways werden die Relationen teils nicht richtig behandelt, so wird z.B. eine no_u_turn - Relation auf beiden Ways belassen.

Grüße

Nach meinem persönlichen Eindruck wurden Verbesserungsvorschläge relativ rasch umgesetzt; z.B.
https://github.com/openstreetmap/iD/issues/3718
https://github.com/openstreetmap/iD/issues/3548

Da hast du prinzipiell Recht, die Übersetzung kann in Einzelfällen sicher optimiert werden. Ich glaube, der fleißigste deutsche Übersetzer, Manfred Brandl, hat sogar hier im Forum schon mal einen Aufruf zur Mithilfe gestartet. Also jeder sprachkundige Mapper, der den iD-Editor verbessern will, kann via Transifex mithelfen. Es ist sicher empfehlenswert sich dabei der eingeführten Definitionen aus dem OSM-wiki zu bedienen.

Bei Geröll für scree liegst du daher falsch, da Geröll (sic!) durch bewegtes Wasser transportierte und abgerollte Gesteinsbruchstücke sind. Scree=Hangschutt/Blockschutt wird idR nicht durch Wasser transportiert und hat daher typischerweise eckige Kanten. Somit kann Hangschutt kein Geröll sein, auch wenn das umgangssprachlich oft verwechselt wird: https://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dscree

Gruß
geow

Danke für Deine vorbildlich differenzierte Antwort! :slight_smile:

Solche Preset-Änderungen gehen meist recht schnell, insbesondere wenn ein Pull-Request vorliegt.
Manchmal scheitern sie aber an recht abstrusen Vorstellungen vom Entwickler und viele Vorschläge sind natürlich auch nicht wirklich sinnvoll.

Sowas sollte immer möglichst gut nachvollziehbar gemeldet werden. Mir ist kein diesbezüglicher Issue bekannt.
Ich denke das wird früher oder später gefixt.

Relationen sind leider so ein Thema, das vom Entwickler als recht unwichtig angesehen wird, wenn man mal von den Abbiegebeschränkungen absieht, die sein Arbeitgeber (mapbox) offenbar gerade haben will.
Auch dafür, dass z.B. die OSM-History wichtig ist, fehlt leider jegliches Verständnis. Naja, wenn man in leeren Gebieten mappt, mag er ja recht haben.
Ähnliches gilt für koinzidente Wege.

Dies betrifft dann aber nur PTv2 und da muss ich sagen, dass dies keine wirkliche Lösung wäre, da auch mit JOSM nur Experten damit umgehen können und dies nicht die Zielgruppe für iD ist. Wir brauchen da eine bessere Lösung, und dass wird nicht ohne Anpassung des PT-Schemas gehen. Wie diese Anpassung optimalerweise aussehen sollte, bin ich mir aber auch noch nicht ganz im klaren.

Nein, das ist genau die Frage. Wenn der Editor angeblich für Neueinsteiger gedacht ist und jedem Erstbesucher von OSM vorgeschlagen wird - ist es dann sinnvoller umgangssprachliche Worte zu verwenden, unter denen der Nutzer sich was vorstellen kann oder geologische Fachbegriffe von denen kein Mensch je gehört hat?

bye, Nop

Das verstehe ich nicht. Wieso betrifft das nut PTv2? Straßenrelationen sind davon ebenso betroffen, Wasserwege, Umleitungsstrecken und vieles mehr.

Weil “Straßenrelationen sind davon ebenso betroffen, Wasserwege, Umleitungsstrecken und vieles mehr.” nicht sortiert sein müssen.

Müssen nicht, aber es ist sehr zu empfehlen.

Auch Grenzrelationen und Multipolygone sollten sortiert sein.

Aber vermutlich funktionieren die auch, wenn sie es nicht sind, offenbar im Gegensatz zu PTv2, womit ich mich leider nicht auskenne, weshalb ich nun wieder still bin :slight_smile:

Weder MP noch Grenzrelationen müssen sortiert sein, es ist ja gerade eins der Probleme mit PTv2, dass die Sortierung im Gegensatz zu allem anderen benötigt wird.

Wie ist das bei anderen Routen? (Wander- und Radwege bspw.), ist da die Sortierung nötig oder nicht?
Praktisch ist eine Sortierung eigentlich immer. Wären geometrisch zusammenhängende Elemente stets der Reihe nach aufgelistet und auch vermerkt, wenn sie sich die Enden teilen, dann sähe man Lücken schneller und man könnte die Elemente auch der Reihe nach durchklicken …

Was mir beim Arbeiten mit iD neben bissele mehr Relationskomfort fehlt, sind zwei Sachen:

  • Man kann mit \ an Knoten übereinanderliegende Wege zwar anzeigen der Reihe nach, aber offenbar keinen davon zur weiteren Bearbeitung selektieren? Oder übersehe ich da was?
  • Man kann keine Eigenschaften kopieren, nur das ganze Element. Wenn man eine in knapp 1024 Wege zerstückelte Straße mit n zusätzlichen tags versehen will, muss man die n x 1024x per Hand eintippen …

Nötig nicht, weil sie sich beim Vorliegen aller Teilwege auch so in eine definierte Reihenfolge bringen lassen. Das funktioniert bei Haltestellen eben nicht.

Full ACK. Daher auch meine Verwirrung oben.

Ich bringe unzusammenhängende Relationen auch meistens in die korrekte Reihenfolge, sofern sie mir auffallen.

Mir fällt auch nur PT ein, welches eine Sortierung vorschreibt. Bei allen anderen ist es der Übersichtlichkeit halber schön, wenn sie sortiert sind, aber das Objekt ist nicht kaputt nur wenn es falsch sortiert wurde.

Die Sortierung ist bei Wander- oder Radrouten nur dann unnötig, wenn ein Sortieralgorithmus die Route selbständig sortieren kann. Sobal die Route Abzweigungen besitzt, z.B. eine Y oder X-Form hat, geht das nicht mehr automatisch bzw. ist nicht mehr eindeutig. Ohne Sortierung kann eine Auswertesoftware*** nicht einmal den Anfang und Ende der Route erkennen.

Beispiel: Welche Länge hat die Route in Metern, wenn die Route nicht sortiert ist?

Grüße
Andreas

***z.B. für Streckenlängenermittlung, Höhenprofil, Streckenbeschreibungen, Export als durchgängigen GPX-Track

Nicht praktisch != kaputt

Wie schrieb Nop in seinem Posting, nicht ganz zu Unrecht:

Einer der Gründe der überbordende Funktionsvielfalt ist ja gerade der Wunsch nach immer neuen und zusätzlichen Funktionen, wenn man sich JOSM wünscht, bekommt man halt auch JOSM.

Simon

PS: iD war nie besonders anfängerfreundlich. Es gab mal am Anfang etwas wirre Aussagen, dass der neue Editor “einfach” (simple) sein sollte, ohne genau zu definieren was das denn genau soll.

Unbestimmt, da keine wohldefinierte Route im OSM Sinn.

PS: solche Routen -könnt- man aber modellieren wenn man Rollen für Anfang und Ziel einer Route definieren würde

Rollen wie “excursion” oder “alternative” fand ich gelegentlich auch hilfreich, dann meckert der Validator allerdings etwas.

Sortieren ist kein Muss, aber ohne findet man im Relationseditor etwaige Lücken nicht.