Zustand von iD

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

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

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

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.