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