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