Zustand von iD

geow · 2018-03-04T21:06:04.000Z

Nop:

Bei den Presets für Wanderwege z.B. fehlen elementare und seit ewigen Zeiten dokumentierte Felder…

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

Nop:

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

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

Chrysopras · 2018-03-04T21:15:47.000Z

slhh:

Chrysopras:

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.

Danke für Deine vorbildlich differenzierte Antwort!

slhh · 2018-03-04T23:57:00.000Z

geow:

Nach meinem persönlichen Eindruck wurden Verbesserungsvorschläge relativ rasch umgesetzt; z.B.

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.

hsimpson:

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.

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.

hsimpson:

eins der größten Probleme von iD ist und blebt die nicht ausreichende Unterstützung von Relationen.

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.

hsimpson:

Ein Sortieren von Mitgliedern ist nicht möglich (obwohl es sicher per drag-and-drop implementierbar wäre)

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.

Nop · 2018-03-05T08:26:39.000Z

geow:

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

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

glglgl · 2018-03-05T08:43:20.000Z

slhh:

hsimpson:

Ein Sortieren von Mitgliedern ist nicht möglich (obwohl es sicher per drag-and-drop implementierbar wäre)

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.

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

SimonPoole · 2018-03-05T08:51:20.000Z

glglgl:

…

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.

glglgl · 2018-03-05T09:07:20.000Z

SimonPoole:

glglgl:

…

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

SimonPoole · 2018-03-05T10:23:12.000Z

glglgl:

SimonPoole:

glglgl:

…

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

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.

MitteloberrheinischerWaldameisenschreck · 2018-03-05T11:31:30.000Z

SimonPoole:

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 …

glglgl · 2018-03-05T12:59:30.000Z

MitteloberrheinischerWaldameisenschreck:

Wie ist das bei anderen Routen? (Wander- und Radwege bspw.), ist da die Sortierung nötig oder nicht?

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

Praktisch ist eine Sortierung eigentlich immer.

Full ACK. Daher auch meine Verwirrung oben.

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

aighes · 2018-03-05T13:03:02.000Z

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.

Andreas_Binder · 2018-03-05T14:46:07.000Z

glglgl:

MitteloberrheinischerWaldameisenschreck:

…(Wander- und Radwege bspw.), ist da die Sortierung nötig oder nicht?

Nötig nicht, weil sie sich beim Vorliegen aller Teilwege auch so in eine definierte Reihenfolge bringen lassen…

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

SimonPoole · 2018-03-05T14:51:58.000Z

Nicht praktisch != kaputt

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

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)

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.

SimonPoole · 2018-03-05T15:00:08.000Z

Andreas Binder:

Beispiel: Welche Länge hat die Route in Metern, wenn die Route nicht sortiert ist?
http://up.picr.de/32010373be.png

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

seichter · 2018-03-05T16:32:14.000Z

SimonPoole:

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.

Andreas_Binder · 2018-03-05T18:35:58.000Z

SimonPoole:

Andreas Binder:

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

Unbestimmt…

Ja, “Unbestimmt” ist absolut korrekt!

Nur Anfang und Ende zu taggen würde spätestens bei Schleifen nix mehr bringen und Du verlangst vom Anwendungsprogramm, dass es durch Routing den Routenverlauf errät. Mit einer einfachen Sortierung der Route entsteht das Problem erst gar nicht und diverse Auswertesoftware verlassen sich auf die Sortierung, (z.B. https://hiking.waymarkedtrails.org oder https://www.xctrails.org):

32012592bh.png386×608 21.1 KB

https://www.openstreetmap.org/relation/2955954

Manuelles Sortieren von Wander-/Rad/MTB/Langlaufrouten ist meiner Meinung nach aber nur dann nötig, wenn die Sortierung nicht durch einen Algorithmus beim Auswerter (z.B. waymarkedtrails und co) gelöst eindeutig werden kann, d.h. in der Regel erst ab Routen mit Abzweigungen oder Schleifen.

Seichter:

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

Ich finde es auch nicht als Muss für den Mapper, aber als Muss für einen Editor, dass er beim Splitten von Wegen die Routen nicht beschädigt. Das Muss für den Mapper würde schon deran scheitern, dass ich außer Josm gar keinen Editor kenne, der so was kann

=> Ein Kann für den Mapper, ein Muss für den Editor

Grüße
Andreas

Edit: Sortierung beim Auswerter hervorgehoben

slhh · 2018-03-05T19:17:24.000Z

Andreas Binder:

Manuelles Sortieren von Wander-/Rad/MTB/Langlaufrouten ist meiner Meinung nach aber nur dann nötig, wenn die Sortierung nicht durch einen Algorithmus gelöst eindeutig werden kann, d.h. in der Regel erst ab Routen mit Abzweigungen oder Schleifen.

Solch eine Mischung ist sehr problematisch. Ist die Route nicht komplett, kann nicht unbedingt festgestellt werden, welcher Fall vorliegt, und somit nicht, ob der Editor automatisch sortieren soll, oder es nicht tun darf, da in der Reihenfolge Information gespeichert ist.

Wenn man Routen mit Abzweigungen Mappen will, sollte man ein geeignetes Datenmodell dazu definieren. Dies sollte besser nicht auf einer manuellen Sortierung der Wege beruhen.

Seichter:

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

Wenn in der Reihenfolge keine Information steckt, kann der Relationseditor, der diese Sortierung braucht, auch selbst automatisch sortieren. Ein grafischer Routeneditor würde diese Sortierung ggf. nicht brauchen.

iD versucht übrigens die Wege beim Einfügen neuer Member automatisch zu sortieren. Da meist aber nicht die ganze Route geladen ist, funktioniert dies nur sehr lokal. Letzteres dürfte den Schaden für PTv2 Routen auch sehr in Grenzen halten.

hsimpson · 2018-03-05T19:40:37.000Z

slhh:

hsimpson:

Ein Sortieren von Mitgliedern ist nicht möglich (obwohl es sicher per drag-and-drop implementierbar wäre)

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.

Hier beißt sich aber auch wieder die Katze in den Schwanz. Wie soll man eine breite Masse für das ÖPNV-Mapping gewinnen, wenn nicht mal der meist verwendete Editor die grundlegenden Werkzeuge dazu bietet?

Wenn man nicht mal eben ohne Installation eines speziellen Tools auf dem heimischen PC (wo man auch erstmal durchsteigen muss) eine Buslinie bearbeiten kann, wird das ÖPNV-Mapping immer ein “Experten”-Gebeit bleiben…

Grüße

Andreas_Binder · 2018-03-05T19:46:35.000Z

slhh:

Andreas Binder:

Manuelles Sortieren von Wander-/Rad/MTB/Langlaufrouten ist meiner Meinung nach aber nur dann nötig, wenn die Sortierung nicht durch einen Algorithmus gelöst eindeutig werden kann, d.h. in der Regel erst ab Routen mit Abzweigungen oder Schleifen.

Solch eine Mischung ist sehr problematisch. Ist die Route nicht komplett, kann nicht unbedingt festgestellt werden, welcher Fall vorliegt, und somit nicht, ob der Editor automatisch sortieren soll, oder es nicht tun darf, da in der Reihenfolge Information gespeichert ist.

Ich glaube, hier hast Du mich falsch verstanden (oder ich hab es zu ungenau geschrieben). Nicht der Editor soll mit einem Algorithmus einfache Fälle automatisch sortieren, sondern die Auswertesoftware, z.B. https://hiking.waymarkedtrails.org/.

Vor der Ermittlung der Streckenlänge oder vor der Erstellung eines Höhenprofils soll geprüft werden, ob die Route bereits sortiert ist (d.h. einen durchgehenden Linienzug bildet) und wenn nicht soll automatisch sortiert werden. Wenn die automatische Sortierung nicht zu einem durchgehenden, nicht kreuzenden Linienzug führt, dann soll die Auswertesoftware einen Fehler melden (was waymarkedtrails.org ja auch macht)

Und automatisch Sortieren geht nur in einfachen Fällen => Wenn der Mapper die Route manuell sortiert, können die Auswerter (waymarkedtrails und co) auch mit komplexeren Routen wie https://www.openstreetmap.org/relation/2955954 was anfangen.

Grüße
Andreas

slhh · 2018-03-05T21:51:29.000Z

Nop:

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

Wir sollten immer sicherstellen, dass der Preset sowohl über umgangssprachliche als auch Fachbezeichnung gefunden wird (ggf. durch zusätzliche Suchbegriffe) und auch für jedermann hinreichend eindeutig definiert ist.
Die Bezeichnung “Geröll” dürfte dies nicht erfüllen. Vielleicht könnte
“Hangschutt, Geröllhalde” und bei Flüssen etc. “Geröll, abgerundet” verwenden.