Gerade was z.B. Radrouten und Co. anbelangt, sollte man auch mal eine gute Darstellung auf der Karte im Hinterkopf haben. Die sollte fix und verlässlich sein. Ich befürchte, für Radwege und Co. funktioniert eine rein stützpunktbasierte Geschichte nicht. … Ja und nur gpx… kommt sowas bei raus:https://www.spreewald-biosphaerenreservat.de/karte/#&g=4&k=26. Wenn ich als Datenverarbeiter das sehe, läuft mir ein kalter Schauer den Rücken hinunter… Auch darstellungstechnisch ist das gruselig… Man sieht übrigens, welcher der Wege mal aus OSM stammte: https://cycling.waymarkedtrails.org/#route?id=2196978.
Da lob ich mir die in OSM als Relationen erfassten Rad-Routen als Relationen… Solche Radrouten sind auch in der Realität in der Ausschilderung recht stabil. Ja und einmal in OSM gut erfasst, ist der Fehlergehalt recht gering (es sei den iD zerwürfelt aus ner Laune heraus die Reihenfolge). Auch ein gutes Radrouting funktioniert, siehe z.B. auch https://cycle.travel/map.
Kommt auf den Renderer an, und darauf, welche der Daten wegen derer der way gesplittet wurde, einen interessieren. Wenn man Abstriche bei der Aktualität macht, man man mit Vektortiles z.B. Straßennamengeometrien machen (die aufwendige Vorberechnung des ST_Union also “vor dem Rendern” machen bzw. beim Vorrendern) und braucht noch nicht so riesige Maschinen wie wenn es live und “sofort” gerendert werden soll, und daraus die Namen rendern.
Ich bin grundsätzlich aber auch schon seit dem Anfang der Meinung, dass man soviel es geht explizit eintragen sollte, anstatt es über properties indirekt auszudrücken, weil das zwar etwas mühseliger ist beim Zeichnen, und auch komplizierter für bestimmte Darstellungen (z.B. fester offset der Linie anhand der Linienstärke einer parallelen Linie, eigentlich braucht man dafür wahrscheinlich zusätzlich die properties), aber dafür einfacher und übersichtlicher ist, lagegetreuer und präziser bei der Form und die Topologie besser abbilden kann. Die Komplexität der realen Welt besteht zwar weiterhin, aber das Modell ist geometrisch näher und die Eigenschaften verteilen sich besser auf die Stellen wo sie auch hingehören, anstatt andere vermeintliche “Haupt”elemente zu überfrachten (insbesondere highways)
Szenario: Auf einem Hügel wird ein Windpark gebaut und zwei neue Anfahrtswege von Norden und von Süden angelegt. Ein noch wenig erfahrener Mapper trägt diese Wege ein, was natürlich gut und richtig ist. Er kann unmöglich auf dem Schirm haben, dass a) eine Wanderroute auf einem alten Schotterweg westlich um den Hügel herumführt, b) diese Wanderroute nur über zwei Stützpunkte definiert ist, einer nördlich, einer südlich, was bislang auch gereicht hat, und c) die zwei neuen Weg eine kürzere Verbindung zwischen den zwei Punkten ermöglichen, eventuell nur indirekt über weitere Wege, so dass die Relation in den heruntergeladenen Daten gar nicht vorhanden ist. Dennoch wird die Relation jetzt über den Hügel geroutet statt außenrum, obwohl sich der markierte Wanderweg gar nicht geändert hat.
Wer macht jetzt den Vorher-Nachher-Vergleich, um das festzustellen? Der Mapperkollege kann es nicht, er weiß ja gar nichts von der Relation, und sie wurde durch seine Neueinträge gar nicht berührt.
Das kannst du, wie oben gesagt, nur zuverlässig verhindern, indem du alle 20 oder spätestens 50 Meter einen Punkt in die Relation setzt, um später versehentlich entstehende Abkürzungen auszuschließen. Gut, kann man machen. Muss dann nur ausgeschlossen werden, dass die Punkte bei irgendeiner Bearbeitung gelöscht werden.
Es geht nicht um fehlerhafte Bearbeitungen, sondern um sinnvolle, die ungewollt das Punkt-zu-Punkt-Routing verändern, indem sie Abkürzungen ermöglichen, die beim Anlegen der Relation nicht berücksichtigt wurden, weil sie noch nicht da waren.
Ja, und wo wird das ältere Ergebnis zwischengespeichert, wie lange, …?
Und wer sagt, dass das ältere Ergebnis das korrekte, das gewollte widerspiegelt?
Wer entscheidet, ob das neue Ergebnis ein Fehler oder die Korrektur eines Fehler ist?
Die ‘neue’ Route wird durch eine Algorithmus ermittelt, nicht durch das Vorhandensein von Ways als Member in einer Relation.
Eine Diskussion der potentiellen neuen Probleme durch Stops und Stützpunkte beim Editieren, bei der QS, beim Rendern, … ist für mich noch nicht abgeschlossen und sollte mMn neben den Vorschlägen und deren Vorteilen zusammen mal dokumentiert werden.
Die Probleme mit dem PTv2 kennen wir (z.T. = “split-ways” auch durch Tools verursacht), ein Re-Design wird neue Problem mit sich bringen.
Will OSM das GIS vom Amt für Tiefbau sein? Die Brücke also zentimetergenau am Widerlager beginnen lassen und das Tempo 40 Schild dort, wo es am Luftbild erscheint, auch wenn drunter ein Schild, “in 25m” hängt, das am Luftbild aber nicht erkennbar ist, genauso wenig wie die Aufschrift “40 km/h Zone” übrigens… Wozu eigentlich OSM-Carto, wenn es eh 20 oder 80cm Luftbilder gibt? Das geeignete consumer-GPS-handheld das nicht Minuten für eine einzelne Messung braucht, auf dem man sich am Bilschirm dort sieht, wo man laut Luftbild tatsächlich ist, das kommt sicher in den nächsten 20 bis 50 Jahren auf den Markt.
PS: War wirklich tun mit einem Straßenabschnitt, der auf 10m einen Hunderter erlaubt? So schnell beschleunigt kein mir bekanntes Fahrzeug (links 50, rechts 40)! Ich plädiere für “fallen lassen”.
(wie soll man “links 50” verstehen? Aber der Reihe nach…)
Wenn im Wechsel 90-100-90 km/h beschildert ist, dann braucht’s nur a≈14.66m/s², und der Tesla S ist mit etwa 10m/s² schon mal nah dran. Bei 50-100-50 sieht’s natürlich ganz anders aus, das ist der a-Wert medizinisch nicht mehr vertretbar.
Bei Abkürzungen ist es ganz einfach… dadurch ändert sich die Gesamtlänge der Strecke und kann durch die größe der Veränderung erkannt werden…
Löschen von Punkten… Gegenfragen wie verhindert man das Löschen von Wegstücken bei den jetztigen Relationen?
Wie weisst du das bei jetztigen Relationen? Ich hab die Relationen im MVV im Bereich von 400-900 die ich erstellt hab alle mit Routing und Raten erstellt… es gibt keine Referenz auf die man sich beziehen könnte ob diese Relationen noch richtig oder überhaupt richtig sind. Kein Gpx, Shape, Routenplan…
Zu Hinterfragen, wieso so viel gesplittet wird, finde ich gut. Sparsamkeit ebenfalls.
Vielleicht habe ich die bisher 4 Seiten nicht gründlich genug gelesen, frage mich aber, wieso man nicht Konzepte miteinander kombiniert:
Überwiegend sind Splits, die ich vornehme(n musste), eindeutige Schnittpunkte zwischen zwei Linien. D.h. es braucht da kein Routing, sondern lediglich das Suchen von Punkt-Schnittmengen zwischen zwei Linien, um Splits überflüssig zu machen. Um selbst diesen Aufwand überflüssig zu machen, könnte man neben den Linien die Punkte zum Übergang auf die nächste Linie in eine Routenrelation aufnehmen – das kann im Prinzip der Editor übernehmen und bei Uneindeutigkeit nachfragen.
Das Datenmodell gibt das (mAn) her; Änderungen wären in Editoren, QA-Tools und Renderern nötig.
Generell: Ein zwei OSMler haben es hier angemerkt. Ich nehme eine Tendenz wahr, dass das zum Erstellen einer Karte aus meiner Sicht notwendige Abstrahieren der Realität in den Hintergrund rückt. Ein bisschen Schade.
Nochmal meine Frage: Von wem wird das erkannt? Wer prüft das nach einer (jeder) Bearbeitung?
Vielleicht mal mit Zeichnung. Hier mein hypothetischer Berggipfel. Der Wanderweg läuft über die Punkte 1, 2, 3, 4 westlich darum herum.
Jetzt wird am Gipfel ein Windrad errichtet und eine Zufahrt neu angelegt, die ein Mapper einzeichnet, wobei die Knoten 5 und 6 neu entstehen:
Ein Router wird den Weg jetzt über 1-2-5-6-3-4 führen. Um das zu unterbinden, muss zwischen 2 und 3 noch ein Stützpunkt 2a eingebaut werden. Wer merkt das und macht das?
Mapper X berührt die Relation überhaupt nicht und fasst weder einen ihrer Punkte noch einen der bislang gerouteten Ways an. Von ihm oder seinem Editor zu erwarten, hier eine Warnung oder gleich eine Reparatur vorzunehmen, dürfte nicht ganz trivial sein.
Der Editor hat die Relation möglicherweise nicht mal in den heruntergeladenen Daten, wenn nur der Bereich zwischen 5 und 6 geladen ist. Das ist der große Unterschied zur jetzigen Routenerfassung, da kann der Editor einfach die Mitgliedschaften der bearbeiteten Objekte abfragen. Im Beispiel oben nützt ihm das nichts.
Sicher, aber man hat die Segments nicht einfach so abgeschafft.
Das beliebteste Feature von iD in diesem Forum ist bekanntlich genau so was.
Das andere Problem ist, je grösser der Abstraktionsgrad der Bearbeitungen ist, desto aufwändiger ist die Implementierung, du hast in den 2 Absätzen ein oder zwei Dutzend Fraujahre verbraten.
Von wem wird das jetzt erkannt? Und wer kann das überprüfen?
Ich könnte nicht eine Relation auf OSM Type=Route überprüfen, weil ich keine Route von vorne bis ans Ende kenne. Ich kenne vielleicht Teile… aber nichts ganz.
Geht eine Relation kaputt kann ich nur raten wie es war… es gibt keine Unterlagen zu einer Route… Wie z.b. ein gpx das ich dagegen halten könnte… Um eine Relation richten zu können.
OSM ist in dieser Hinsicht das letzte was man gebrauchen kann… In der Praxis holt man sich lieber wo anders ein gpx… da hat man mehr davon… weil aus einer kaputten Relation eine fehlerfreie gpx Datei zu bekommen ist zu viel Arbeit.
So sind viele Relationen kaputt und unvollständig die meiste Zeit ihres Bestehens.
Die Frage verstehe ich nicht. Das von mir beschriebene Szenario kann nur dann eintreten, wenn man eine (Wander-)Route ausschließlich über eine Folge von Wegpunkten definiert, zwischen denen frei geroutet wird.
So, wie wir Wanderrouten derzeit erfassen, als Folge von Ways, kann es nicht eintreten. Dazu müsste Mapper X bewusst die Relation anfassen.
Genau das tut er oben nicht, trotzdem ist sie betroffen.
Das ich nicht Lache… das passiert regelmässig… dass Löcher reingerissen werden. Gerade mit ID wird da oft und gern mal an Stück geteilt/gelöscht und dann anders zusammengefügt.
Das ganze ist auch das nächste Problem das Routen Relationen wenn sie groß sind schnell mal > 50 versionen haben. Weil jedes Teilen eines Weges, jedes Reparieren und zerstören eine neue Version erzeugt.
Ich weiß. Aber das ist nicht das Szenario, das ich in #79 beschrieben habe, und es lässt sich leicht vermeiden (weil dabei die Relation angefasst wird und der Editor das leicht feststellen kann).
Zum dritten Mal: Wenn wir anfangen, Wanderrouten nicht mehr über Ways, sondern nur noch über Stützpunkte zu erfassen, dann kann der von mir oben beschriebene Fehler zwischen zweien dieser Stützpunkte passieren, ohne dass die Relation berührt wird oder auch nur im Editor geladen ist, und ist damit nicht trivial vermeidbar.
Dazu musst du dir die (alte, korrekte?) Gesamtlänge irgendwo speichern. Ist dieses “speichern” Aufgabe eines QS-Tools oder wer mach das und wo?
Verhindern kann man das nicht, nur bei einem QS-Lauf prüfen. Wegstücke die aus Relationen gelöscht werden hinterlassen eine Lücke.
Korrekt, aber es gibt Kriterien, wie eine Relation formal korrekt aussehen muss. Die inhaltliche Prüfung muss eigentlich immer ein(e) MapperIn machen.
Wie erwähnt, gibt es formale und inhaltliche Kriterien für Korrektheit.
Derzeit kann man die formale Korrektheit des Fahrweges prüfen:
sie enthält keine Lücken,
nutzt Einbahnstraßen nicht unerlaubterweise in der Gegenrichtung, bzw. kann darauf hinweisen, dass gegebenenfalls ein oneway:psv=no fehlt
nutzt Straßen nicht, wenn access=no dran steht, bzw. kann darauf hinweisen, dass gegebenenfalls ein psv=yes fehlt
nutzt keine highway=construction, ein Grund, die Relation bzgl. Dauer der Baustelle zu prüfen?
…
wenn man davon ausgeht, dass alle Wege in der Relation wie vom Mapper gewollt genutzt werden sollen.
Das “Problem” mit den stop-position und Stützpunkten und Routing-Engine
Lücken gibt es damit nicht, sehr gut, wünschenswert
daher sieht es auf Karten immer OK, weil geschlossen aus
leitet den Bus um die Einbahnstraße dieses Wegstück herum, ob ein oneway:psv=no am Weg fehlt kann nicht erkannt werden
leitet den Bus um dieses access=no Wegstück herum, ob ein psv=yes am Weg fehlt kann nicht erkannt werden
leitet den Bus um die Baustelle herum … auf welchem (korrektem oder falschem) Weg auch immer
…
Mein Problem mit dem Anwerfen einer Routing-Engine?
Wo wird die korrekte Länge des Fahrweges gespeichert, wer ermittelt sie, wer trägt sie ein? Für spätere QS notwendig? Siehe oben.
Die Routing-Engine arbeitet im Verborgenen, das Ergebnis müsste für die Mapper visualisiert werden: im Editor, auf einer Karte, selektiv: nur für diese Relation
Das Ergebnis der Routing-Engine entzieht sich einigen formalen Prüfungen, es sei denn, das Ergebniss der Engine ist eine Liste von benutzten OSM-Ways?
Das Ergebnis der Routing-Engine routet um Fehler am übrigen Datenbestand herum (access=no mit fehlendem psv=yes, Einbahnstraße falsch herum, …)
Was passiert aus einer einfachen Kreuzung (mit exakt einem Punkt als Stützpunk in Relationen) nach Editieren wegen Verkehrsinseln (dann vier Punkte) und Nichtanpassen der Relationen?
Routing-Chaos?
Wie erkennen wir das? Mal abgesehen von dem “die Länge der Route ändert sich”, für das ich noch keine Lösung (gesehen) habe.
Die Länge einer (Überland-)Route ändert sich übrigens auch durch Lageverschiebungen von Nodes in Kurven. Ab wie viel Änderung der Meter bzw. Prozent wäre ein QS-Hinweis angebracht?
Überzeuge die Rendering-Engines davon eine Routing-Engine anzuwerfen
Das Ziel: Haltestellen und Stützpunkten und Routing-Engine ist auch für mich attraktiv. Ich sehe nur noch zu viele ungeklärte Punkte: neue Probleme an neuen Stellen, die uns dem Ziel eines einfacheren ÖPNV-Mapping nicht näher bringen?
Edit: Sorry, beteilige mich hiermit massiv am Kapern des Threads. Wir sollten bzgl. Routen-Relationen einen neuen Thread aufmachen.
Wie wäre es wenn die Personen, die hier so nach Routen-Relationen nur mit Punkten schreien, mal konkrete Beispiele präsentieren. Ich sehe da bisher wenig Verständnis für die angesprochenen Probleme. Insbesondere würden sich etliche ÖPV-Betriebe über einen anständige Routingsoftware für Busse freuen. Was im GTFS aus OSM an Shapes vorhanden ist, ist häufig fehlerhaft bis grottig. Selbst beim Zügen wundere ich mich manchmal, an welcher Stelle die Gleise gewechselt werden.
Ganz besonders interessant finde ich die Frage nach der Darstellung in der Editor-Software , was diese Idee an zusätzlicher Unterstützung von der Editor-Software benötigt und wie das alles Ressourcensparend umgesetzt werden kann. JOSM ist ein Offline-Editor also bitte keine externe Daten nachladen.
Beim Löschen schon, beim Verschieben oder wenn ich den Knoten aus dem highway trenne nicht mehr. TMC-Point Relation sind z.B. wesentlich stabiler mit Wegen als Mitgliedern, als nur Knoten und nicht zu vergessen, wir reden bei diesen Beispielen von einer Kreuzung aber nicht von einer Route quer durch einen Landkreis oder mehr.
Aber so wie es ist… haben immer weniger Bock drauf… mich eingeschlossen.
z.B. diese Linie “Bus 530” wieder zum x-ten mal zu fixen weil die mal wieder zerschossen wurde… ganz schön zum reparieren, weil hier der Bus öfters die gleichen Wegstücke nimmt… und das in 5 Varianten kaputt in dieser Linie.
Ich fix das nicht mehr… könnts euch was überlegen.
Woher hast Du diese Information? In meinem Gebiet sind es seit 10 Jahren, zwei aktive Personen, die sich um die Relationen kümmern. Da hat sich bis heute nichts geändert.
Welcher Editor-Software wird denn benutzt? iD kannst Du mindestens seit vier Monaten für das Aufspitten auch ohne Schleifen nicht verwenden und das trotz bezahltem Entwickler, von komplizierteren Fällen mal ganz zu schweigen und auch von den ganzen Route-Relationen welche nicht so gut überwacht werden wie z.B. route=road.
Ich gebe den Einwänden von FraukeLeo Recht: Ein Zerschießen, ohne dass ein Element der als Punkte erfassten Relation angefasst wurde. Zudem kann ich nicht erkennen, wieso ein auf Punkten basierendes System weniger anfällig fürs “Zerschießen” sein soll. Wie schnell passiert es, dass jemand beim Verändern von Straßenlinien Kreuzungspunkte löscht und neu setzt… das würde dann - so wie ich es verstanden habe - bei dem Vorschlag mit Punkten die Wanderroute zerschießen.
