Sparsamkeitsgebot Way-Splits

Communities Deutschland (Germany)
81

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.

Gruß Miche

82

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.

83

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.

84

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.

85

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.

86

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.

87

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.

88

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.

89

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.

90

Ihr müsst mir ja nicht glauben, aber nach 12 Jahren OSM Erfahrung wird das im großen und ganzen… nix. Vielleicht für euer Dorf oder Stadt vielleicht… aber durchgängig kann man das vergessen. Nicht mal für ganz Deutschland.

91

Na ja, meine Begeisterung lässt schon mal recht schnell nach und hält sich längere Zeit in Grenzen, wenn ich Buslinien mit 39 Varianten sehe.

Es gibt halt Dinge, die ein Editor bitteschön richtig machen sollte (split-of-way mit lokalem Einsortieren) und die er bitteschön lieber nicht machen sollte (globales Sortieren einer nicht linearen Wegereihenfolge: Wege werden mehrfach befahren).

92

Ich bezweifele ja gar nicht, dass die aktuelle Relationen-Methode störanfällig ist. Ich gebe allerdings FraukeLeo Recht, indem ich die vorgeschlagene Alternative für mindestens ebenso störanfällig halte. Wenn man schon die Mammutaufgabe angehen wollte, das bisherige System komplett umzustellen, dann sollte damit auch eine tatsächliche und deutliche Verbesserung verbunden sein. Und die kann ich nicht im Ansatz erkennen.

93

Die Veränderung muss nicht groß sein…
Bei Bus z.b. nur dass die Wegeliste optional ist. Und eine zusätzlich Role in der Haltestellenliste die Role “via” um den Router Korrektur Infos zu liefern.

Bei anderen Routen vermisst man z.B. bei Themen Routen die POI die zu dem Weg gehören. Hier wird nur der Weg abgebildet… das Thema wird nicht erfasst in der Relation… Als stops… oder POI… Viewpoint… hier bräuchte man auch noch rollen dann noch mit einzutragen.

Schön wäre es zumindest für jede Relation eine statische gpx Datei zu haben, --egal wie alt-- in der die Route gespeichert wird… damit wenn die Relation kaputt geht darauf zurück zu greifen zu können.

94

Prinzipiell heute schon machbar: GPX Track nach OSM hochladen, und dann irgendein Tag erfinden, unter dem dieser Track dann abrufbar ist, z.B.

ref:gpx=https://www.openstreetmap.org/user/Operadora/traces/3653624

oder direkt auf das GPX verlinken, was auch immer besser funktioniert: https://www.openstreetmap.org/trace/3653624/data

Weil das hier im Forum noch nicht thematisiert wurde, Quincy hat kürzlich seinen “Ausstand” bekanntgegeben. Es gibt im Moment keinen bezahlten Entwickler mehr.

95

ich pflichte den beiden ebenfalls bei.

96

Mal was grundsätzliches.

Bis Samstag dachte ich, die Möglichkeit zur präzisen Abbildung der tatsächlichen Verhältnisse sei eine Stärke von OSM. Eine komplexe Kreuzung wie https://osm.org/go/0Dezov85d-?m= ist auf der Karte 1:25000 halt sternförmig ohne weitere Details. In OSM kann ich so weit reinzoomen, dass ich genau sehe, welche Wege direkt vom Stern abgehen und welche erst 20 Meter später abzweigen und von welchem Weg sie abzweigen, und muss dann gar nicht lange suchen. Wenn ordentlich gemappt wurde versteht sich.

Das andere Beispiel von einem Wanderweg, der 20 Meter weit einer Bundesstraße folgt, hatte ich oben auch schon genannt. Es ist hilfreich, solche Details auf der Karte zu sehen, bevor man hinkommt. In OSM kein Thema, weil man theoretisch beliebig weit zoomen kann. Außerdem kann die Sprachausgabe (ich weiß nicht, wer so was beim wandern benutzt, aber warum nicht) dann sagen “folgen Sie der B 4711 nach links für 20 Meter, dann rechts auf den Schotterweg” statt einfach nur “sehen Sie zu, wie Sie auf die andere Seite kommen, da gehts irgendwo weiter” (mehr kann die gedruckte Karte nicht sagen).

Genaues Arbeiten hat nutzungstechnisch nur Vorteile, mit detailgenauen Daten findet man sich draußen besser und schneller zurecht. Deshalb hab ich mich immer bemüht, präzise zu arbeiten, aber das bedeutet halt auch, hin und wieder aus einer Bundesstraße ein wenige Meter langes Stück rauszuteilen und in die Relation zu packen.

Seit Samstag 13:08 Uhr weiß ich, dass das, womit ich mir so viel Mühe gebe, “Irrsinn” ist, der “ins Verderben” führt. Andere mahnen, dass ich zwar nicht pfuschen soll, aber möglichst viel generalisieren muss (heißt wohl: Details weglassen, zum Beispiel an der Achteck-Kreuzung die späteren Abzweigungen mit auf den Kreuzungs-Node zu ziehen). Und kann zu meiner Entschuldigung nur vorbringen, dass ich, wenn ich mal zwei Way-Abschnitte sehe, die völlig grundlos geteilt sind, diese verbinde und damit Pluspunkte sammle :slight_smile:

Ich verstehe aber immer noch nicht, was am Aufteilen eigentlich so furchtbar ist. Ja, es ist ein bisschen mühsam, wenn man eine gesamte Straße bearbeiten will (zB um die ref zu ändern) und erstmal viele Teilstücke einzeln selektieren muss. (Es nervt allerdings noch viel mehr, wenn Flächen drangeklebt sind.)

Also: Was genau ist denn der Nachteil kurz aufgeteilter Way-Abschnitte, worin besteht das befürchtete Verderben? Sind die Nummern für Ways irgendwie knapp geworden, so dass wir haushalten müssen? Oder was soll das “Sparsamkeitsgebot” im Titel heißen?

97

Nun, in der Disskussion hat man sich etwas zu sehr auf Routen-Relationen verrannt… Denn schon muß man bei diesen unterscheiden zwischen solchen, die über 2-3 Jahre hinweg gesehen recht dynamisch sind (=Busrouten) und solchen, die sich in der Regel kaum ändern, und wenn, dann ist es einmal und dann ist mindestens die nächsten 5-10 Jahre Ruhe… Wanderwege und Radrouten gehören dazu. Bei diesen würde ich mir eher ein richtig gutes Fehlerprüftool wünschen, wie es vergleichbar für die Knotenpunktnetze gibt.

Andererseits kann ich die Intention des Ausgangspostings gut verstehen.
Es gibt absolut vermeidbare und unnötige Way-Splits. Siehe mein Beitrag #18
Andererseits denke ich, daß bei vielen Dingen ein adäquater Punkt reichen würde… Da fallen mir viele Dinge ein… Schön ausgebaute Parkbuchten entlang einer Straße, mit 1,3 Stellplätzen in Innenstädten, unterbrochen von bepflanzten Inseln, teilweise mit Bäumen… reicht es da nicht einen Punkt im Verhältnis in der Mitte zu setzen mit der Angabe der Anzahl der Stellplätze und Angabe rechts und/oder links der Wegerichtung, anstelle die Straße zu splitten und parking:lane zu setzen?
Ich denke da auch an den zwanghaften Drang, Radwegattribute möglichst an die Straße zu setzen anstelle eines separaten Weges, wo es in der Realität auch passt… Auch viele traffic_calming fallen für mich darunter. Da ließe sich sicher noch einige mehr finden.

Schlußendlich wird man aber ob eines sinnvollen und verwendbaren Routings und auch einer sauberen verlässlichen Kartendarstellung um einen gewissen Grad an Splitten der Wege nicht drum herum kommen. Für eine gute und sinnvolle Auswertung von Routen sehe ich im Moment keine Alternative, als die, die jetzt angewendet wird.

Vielleicht wird es sich auch als nötig erweisen, Kategorien zu entwickeln, bei welchen Dingen eine Splittung zwingend erforderlich ist… In den Abschnitten https://wiki.openstreetmap.org/wiki/DE:Key:highway#Attribute und https://wiki.openstreetmap.org/wiki/DE:Key:highway#Andere_Merkmale sind für mich durchaus einige dabei, wo ich ein Trennen als nicht nötig erachte. Mich würde aber auch mal interessieren, wie sehr die im Ausgangsbeitrag genannte Situation real in der Fläche ist…

Sven

98

Es ist die Liebe zum Detail

Eine Straße wird mitten im Verlauf zur Einbahn. Der Punkt wo das passiert ist nicht dort gemappt, wo das Schild steht, sondern 12m daneben. Also wird die Nichteinbahnstraße an der Stelle gesplittet und der abgespaltene Teil zur Einbahn erklärt. Voilà, das ginge anders auch. Ich habs mit Bauchweh so belassen; nicht ganz freilich, weil so war es möglich, die Gehsteigsituation korrekt abzubilden. Das geht meist ohne splits, und wenn, dann bleibt eben ein Gehsteig ungemappt.

Hier die 12m Tempo 50-100-40 - https://www.openstreetmap.org/way/548874681 - mapillary gibts nichts, aber google streetview - https://www.google.com/maps/@47.2892819,11.4705759,3a,75y,19.36h,95.61t/data=!3m6!1e1!3m4!1sCGwp1atOt2966GgHbgQIUw!2e0!7i13312!8i6656

Tatsache ist: den neuen Teil nun an die bestehende Einbahnstraße zu hängen, das würde die Tempolimits nicht mehr “sauber” abbilden lassen. Wollte man das aber durchziehen, dann müssten man den Nichteinbahnteil noch einmal splitten, denn der 50er steht 10m weiter weg von der Kreuzung in die andere Richtung. Und den Feldweg daneben müsste man auch splitten, weil das Schild “Fahrverbot ausgenommen Landwirtschaft” steht auch 10m weg von der Kreuzung. Auch das Einbahnschild steht nicht mitten auf der Kreuzung sonder 5m in die Straße hinein. Da müssten man den Punkt schieben, an dem der Split stattfindet.

Danw wäre alles schön “lagerichtig”, wie das weiter oben im Thread bezeichnet wurde - Ich würde dazu sagen: “digital versiegelt”.

99

Danke, diese Fragen sind für mich seit Beginn des Threads auch noch nicht beantwortet.

100

Zustimmung! So was ist wirklich Quatsch. Es hat auch keinen Nutzen für niemanden.
Ich hab nur etwas rot gesehen, als präzise Erfassung von Wanderrouten ebenso angeprangert wurde. Und das hat definitiv einen Nutzen.