Zustand von iD

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.

geow · 2018-03-05T22:16:32.000Z

Nop:

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

iD ist inzwischen ziemlich gut und nicht nur ein Editor für Neueinsteiger, die Einstiegsdroge ist jetzt nicht selten maps.me mit 32% der User: https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_users_.28distinct_uids.29

Ich bin der Meinung, dass die Presets nur die eingeführten Definitionen aus dem OSM-wiki verwenden sollten. Dein Übersetzungsvorschlag scree=Geröll ist zwar gut gemeint, aber leider mehrdeutig und wird daher zwangsläufig zu Inkonsistenzen beim Erfassen führen.
Man sollte Beitragende nicht unterschätzen. Wer z.B. Landschaften kartiert, wird sich über die korrekten Begriffe der verschiedenen Bodenbedeckungen und Oberflächen früher oder später informieren.

Ich gebe dir aber Recht, dass die deutsche Übersetzung scree=Hangschutt noch verbessert/erweitert werden kann - ich überlege mir was Jedem Bergsteiger ist z.B. klar, was eine Schuttreiße ist.

Gruß
geow

PS: Inzwischen ist iD V 2.7.0 raus: https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#270
Wichtigste Neuerung ist die Unterstützung von WMS-Layern!

SimonPoole · 2018-03-06T07:45:49.000Z

geow:

…

iD ist inzwischen ziemlich gut und nicht nur ein Editor für Neueinsteiger, die Einstiegsdroge ist jetzt nicht selten maps.me mit 32% der User: https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_users_.28distinct_uids.29
…

Trau keiner Statistik, die …

Einerseits https://www.openstreetmap.org/user/SimonPoole/diary/43093 , anderseits ist der Anteil der maps.me Anfänger die in irgendeiner Form substantiell Mappen verschwindend (was auch für das Gesamtvolumen der Edits von maps.me Nutzer gilt).

Mit anderen Worten iD is klar die Hauptquelle für neue Mapper.

[Edit]
Noch schnell aktuelle Zahlen von ganz 2017 zum Thema, haben sich aber gegenüber früheren Auswertungen nicht geändert:


Editor        Gesamt  10 Edits       100 Edits     1000 Edits 

iD           135'211  96'170 (71%)   54'805 (41%)  15'187 (11%)
maps.me       77'844   7'708 (10%)      918 (1%)      149 (0%)

“Edits” sind Änderungen, nicht Changesets, also auch 1000 sind relativ wenig.

Die Zahlen sind Mapper die mit einem bestimmten Editor angefangen haben, sind also inklusive Edits die später mit einem anderen Editor gemacht wurden.

30303020 · 2018-03-07T10:11:01.000Z

slhh:

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.

Nein, nach meinen Beobachtungen richtet das Schaden an (s. https://forum.openstreetmap.org/viewtopic.php?id=61455)!

Hier ein Link zu einer betroffenen Relation: https://www.openstreetmap.org/relation/2764246. Die Buslinie war korrekt, aber nach dem Einfügen einige Straßenteile wurde sie komplett sortiert.

Nop · 2018-04-02T09:06:08.000Z

geow:

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

Ich habe das Experiment gewagt und einen PR für ein paar Presets eingestellt (u.a. Erweiterung der sehr mageren Tags für Hiking Route). https://github.com/openstreetmap/iD/pull/4912

Das war vor 15 Tagen, leider ist seither nicht die geringste Reaktion auf den PR erfolgt. Erhöht nicht unbedingt die Motivation nochmal was einzubringen.

Das ist besonders schade weil der PR eigentlich mit einem Klick zu integrieren wäre - je länger er rumgammelt desto wahrscheinlicher wird es, daß irgendwelche Konflikte mit anderen Änderungen entstehen und es entsprechend Arbeit macht ihn noch reinzunehmen.

bye, Nop

surveyor54 · 2018-09-02T20:02:22.000Z

hsimpson:

Hi,

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

Ich hatte jetzt den Fall, dass ein Kollege Straßen u. Wege vereinigt und dadurch die Routen zerstört hat. Angeblich hat ID nicht gemeckert.
Ich arbeite schon immer mit JOSM, da geht das Fenster auf mit den Entscheidungen (Behalten, Entfernen) und ist somit schon gewarnt. Mit ID kenne ich mich leider nicht aus.

Macht er hier etwas falsch?

Gruß
surveyoe54

Edit:typo

Galbinus · 2018-09-03T07:32:30.000Z

Was ist damit gemeint: “Route zerstört”? Was genau wurde beschädigt?
iD lässt inzwischen nicht mehr jede Vereinigung zwischen zwei Wegen oder Straßen zu.
Allerdings lässt sich z.B. kein Weg oder keine Straße löschen, solange sie noch Teil einer Relation ist. Erst wenn man die Relation gelöscht hat, kann man anschließend den Weg oder die Straße löschen. Anders ist es, wenn man zwei Wege oder Straßen vereinigt. Dort werden alle Relationen aus beiden Wegen/Straßen in den vereinigten Weg/Straße übernommen.

surveyor54 · 2018-09-03T07:45:51.000Z

Galbinus:

Was ist damit gemeint: “Route zerstört”? Was genau wurde beschädigt?
…
Anders ist es, wenn man zwei Wege oder Straßen vereinigt. Dort werden alle Relationen aus beiden Wegen/Straßen in den vereinigten Weg/Straße übernommen.

Beschädigt hätte ich schreiben sollen!

Wenn die Route abknickt und man vereinigt die Wegsegmente die geradeaus gehen ist die Route nicht mehr korrekt.

         b
         b
         b
         rrrrrrrrrrrrrrrr
         ar
         ar
         ar
         ar

Ich meine der normale Routenverlauf = “r”, wenn “a” mit “b” vereinigt wird, ist die Relation beschädigt.

Ich hoffe man versteht was ich meine.

Edit: Korrektur

Galbinus · 2018-09-03T08:01:55.000Z

Ja, das macht allerdings der iD immer noch ohne jegliche Warnung. Das wäre demnach noch ein wichtiger Verbesserungsvorschlag. Den iD ist nunmal der offizielle Standarteditor, mit dem alle neuen Maper erst einmal arbeiten. Und wenn man mit dem Mapen beginnt, hat man von Relationen überhaupt keine Ahnung und merkt gar nicht, was man da tut.