Sparsamkeitsgebot Way-Splits

[Hungerburg (Asa Hundert)]

@aighes

Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören.

Meinst du https://wiki.openstreetmap.org/wiki/Relation:street ? Als Lösung für Probleme aus Relationen scheint eine Relation immer noch das Beste! Sie löst aber auch andere Probleme: In Boston (USA) ist das verbreitet, nicht zuletzt können damit die separat erfassten Bürgersteige wieder an die Straße gebunden werden.

PS: Ob diese regionale Eigenheit mit dem MIT zu tun hat?
PPS: Allerdings sieht es nach Stichproben ein wenig danach aus, dass auch dort die Zusammensammler den Splittern hinterherhinken.

[GerdP]

Die type=street bzw. type=associatedStreet Relationen wären schön, wenn sie die einzige Möglichkeit wären, einen Namen anzugeben. So aber sind sie für den Datenverarbeiter eine Quelle für Sonderfälle (z.B. unterschiedliche Namen in den Membern, einzelne Teile, die in der Relation fehlen usw.)

[westnordost]

Ich habe diesen Thread mal auf OSM Slack US gepostet.

Ein paar Kommentare von dort:

Max Erickson wies darauf hin, dass es schon ein Proposal gibt um Routen-Relationen zu vereinfachen so wie es Frederick angedeutet hat: https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations . Offenbar wurde es auch schon auf einer Mailingliste diskutiert (habe jetzt keinen Link)

Bryan Housel warf ein, dass für einige Busrouten, insbesondere solche mit keinen festen Haltestellen bei denen man quasi überall entlang der Route ein- und aussteigen kann wenn man den Busfahrer bescheid gibt die genaue Route eben doch wichtig ist.

Ein längerer Beitrag von Minh Nguyen, hier mal als Zitat aber halbautomatisch ins deutsche übersetzt:

Eine typische Stadtbusroute folgt einer bestimmten Route über bestimmte Straßen. Sie ist möglicherweise nicht zu 100 % zeit- oder entfernungsoptimiert, basierend auf den tagesaktuellen Bedingungen. Solane man keine Insider-Verbindung zum Verkehrsbetrieb hat, weiß man wahrscheinlich nicht genug über die Faktoren und Überlegungen, die in die Planung der Route eingeflossen sind, um den Prozess in einem dynamischen Routing-Profil genau nachzubilden. Das Beste, was man tun kann, ist, die Route zu approximieren, was für die Berechnung der voraussichtlichen Ankunftszeit (ETA) in Ordnung sein mag - die kommen sowieso immer zu spät, oder? - aber für visuelle Zwecke könnte das irreführend sein. Trotzdem kann man die tatsächliche Route persönlich überprüfen, indem man mit dem Bus fährt oder in einigen Orten nach aufgemalten Wegweisern an Telefonmasten Ausschau hält.

Viele ländliche und einige vorstädtische Bus-Firmen haben immer noch die Anweisung, (nur) Mitfahrer auf der Strecke mitzunehmen die den Bus herbeiwinken. Eine Route wird hier tatsächlich durch Straßen und Kreuzungen definiert; es gibt keine festen Haltestellen, von denen man sprechen könnte. Paul Johnson wies darauf hin, dass einige Systeme Routen als unscharfe Korridore behandeln, nicht als scharfe Linien: https://lists.openstreetmap.org/pipermail/talk-us/2015-March/thread.html#14351. Sollten Datenkonsumenten mit zwei völlig unterschiedlichen Datenmodellen für diese beiden Fälle umgehen müssen?

Intercity-Routen und einige städtische Express-Routen sind durch Haltestellen und nur lose durch Straßen definiert. Eine Expressroute hat zum Beispiel Haltestellen, die weit genug auseinander liegen, dass der Fahrer einen gewissen Spielraum hat, um einen Stau zu umfahren, was auf einer konventionellen Route nicht möglich wäre. Übrigens bin ich in San Francisco manchmal mit einem Expressbus gefahren, der auf einem breiten geschützten Radweg fuhr, um den Berufsverkehr zu umfahren. Yeehaw!

Aber in all diesen Fällen hat die Route immer noch eine formale Definition über bestimmte Straßen, auch wenn der Fahrer ihr nicht zu 100% folgt.

Es ist wirklich einfach für einen Mapper, handwaving darüber zu betreiben, was Router tun sollten, besonders wenn der Mapper sich nicht allzu sehr um Routing kümmert. Map-Matching und Via-Point-Routing sind mächtige Werkzeuge, aber sie sind keine Magie.

Aus dem Forumsthread habe ich den Eindruck gewonnen, dass einige Mapper desillusioniert darüber sind, wie kompliziert es geworden ist, die Karte zu mappen und zu pflegen. Ab und zu ist es gesund, einen Schritt zurückzutreten, den Expertenmodus zu deaktivieren und sich an den Presets und den Arbeitsabläufen für Anfänger zu erfreuen. Die Karte wird schon wieder.

[miche101]

@westnordost

Busrouten, insbesondere solche mit keinen festen Haltestellen bei denen man quasi überall entlang der Route ein- und aussteigen kann wenn man den Busfahrer bescheid gibt die genaue Route eben doch wichtig ist.

Könnte man auch über Routing machen, Vorschlag war von mir… die Route optimal zu machen. Dann kann der Datenverwerter… die Route aus der Relation nehmen wenn vorhanden und gut… oder Routing anwenden.

Gegenbeispiel: Rufbus/taxi… hier gibt es teilweise überhaupt keine feste Route, was ein hinzufügen einer Route unmöglich macht. Zum Beispiel weil der Bus/Taxi zur gleichen Zeit an zwei verschiedenen Orten sich befindet laut Fahrplan. (MVV Ruftaxi 8000, 8200, 8300, 8400, 8500, 8700, 8800). Routing kann das auch nicht für den Renderer lösen, hier kann man nur die Haltestellen in der Relation sammeln. Wenn aber die stops bekannt werden für diese Fahrt könnte man sich dass dynamisch Routen lassen…

[westnordost]

Im Thread of Slack gibt es noch weitere Antworten:

Minh weist darauf hin, dass es einige Renderer gibt, die fest davon ausgehen, dass alle Segmente der Route entsprechend in der Route-Relation vorhanden ist. Neben Transport-Map, ÖPNV-Karte auch z.B. Trufi/OpenTripPlanner.

Erwähnt wird auch ein Projekt der Uni Freiburg https://github.com/ad-freiburg/pfaedle/, das offenbar das Errechnen einer Route aus Stützpunkten zum Ziel hat.

[miche101]

@westnordost

Trufi/OpenTripPlanner.

Bei Trufi werden als Nebenprodukt Relationen erstellt… Ziel hier eine GTFS Datei zu erstellen.

Bei OpenTripPlanner arbeit mit GTFS Daten und benötigt keine ÖPNV-Relationen aus OSM.

@westnordost

Erwähnt wird auch ein Projekt der Uni Freiburg https://github.com/ad-freiburg/pfaedle/, das offenbar das Errechnen einer Route aus Stützpunkten zum Ziel hat.

Bei pfaedle werden Shape Daten für GTFS Dateien erstellen… Benötigt auch keine ÖPNV-Relationen aus OSM.

Dreh- und Angelpunkt sind hier die GTFS-Daten, weil hier auch die Timetable enthalten ist… was Routing mit Bus erst ermöglicht

Gruß Miche

[aighes (Henning)]

@Hungerburg

@aighes

Bspw. name=Schulstraße sollte quasi eine collection (=relation) aus den Wegsegmenten sein, die zu dieser Schulstraße gehören.

Meinst du https://wiki.openstreetmap.org/wiki/Relation:street ? Als Lösung für Probleme aus Relationen scheint eine Relation immer noch das Beste! Sie löst aber auch andere Probleme: In Boston (USA) ist das verbreitet, nicht zuletzt können damit die separat erfassten Bürgersteige wieder an die Straße gebunden werden.

Ja, so in der Art, aber halt nicht nur auf Straßen begrenzt sondern für alle Eigenschaften. Dann kann ich die Geometrie(=way) beliebig splitten. Idealerweise würde man das Nachführen von splits und mergern der API überlassen und nicht auf den Editor zu hoffen.

Als Auswerter kann ich dann die für mich interessanten Eigenschaften an die Geometrie heften und mergen, was verbunden ist und identisch in durch meine Brille betrachtet identisch ist.

[westnordost]

Guillaume Rischard erwähnte, dass er auch genau über das Thema ein Vortrag auf der SotM 2019 gehalten hat. Da der Talk sowieso auf Englisch ist, hier der komplette Kommentar von ihm aus OSM Slack auf Englisch. Das erwähnte Proposal ist ja übrigens auch von ihm:

Bus relations with ways do break too often. I think we’d be better off mapping stops accurately with gtfs identifiers, and keeping the rest in gtfs, and doing routing on demand. I’ve had decent results with osrm.

But if we do need to keep bus routes in osm, then without ways.

I gave a lightning talk on my work in Heidelberg, https://www.youtube.com/watch?v=SdNu-Mz79xg&t=1057s

Wer übrigens mal reinschauen möchte auf OSM Slack, hier ist der Link: https://slack.openstreetmap.us/
OSM Slack ist offen für alle, der Chat-Space wird nur finanziert vom local chapter in den Vereinigten Staaten.