Zustand von iD

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.

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

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.

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

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.

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.

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

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

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.

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 :slight_smile: 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!

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.

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.

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

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

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.

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

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.

Etwas OT:

Du meinst anstatt von “Erst wenn man die Relation gelöscht hat,…” vermutich entweder “Erst wenn man den Weg aus der Relation entfernt hat,…” oder “Erst wenn man die Information gelöscht hat, dass der Weg zu einer Relation gehört,…”

Auch dann ist es ist nicht ganz vollständig. Für den Fall wenn man den Weg markiert hat, ja dann gibt es keine Löschoption weil der Löschknopf ausgegraut ist. Für den Fall wenn man einen einzelnen Punkt (der zum zu löschenden Weg gehört) markiert, dann bekommt man diesen Punkt dagegen mühelos gelöscht und somit kann man auch alle weiteren Punkte vom zu löschenden Weg nacheinander entfernen. Dementsprechend ist danach natürlich auch die Relationsinformation entfernt und man hat entweder eine Lücke in der Relation oder es fehlt ein Wegstück am Anfang oder Ende der Relation.

Ja, so ist es