Dass Routing quer über Flächen gewöhnlich nicht funktioniert ist ja bekannt. Aber dass gewöhnlich bei Multipolygonen auch der Rand nicht genutzt wird ist mir erst jetzt aufgefallen. (z.B. hier http://www.openstreetmap.org/#map=19/51.21618/6.75770))
Das ist technisch verständlich, hat aber üble Folgen. Bahnsteige mit Treppen sind gewöhnlich Multipolygone. Auch die Router, die highway/railway=platform als begehbar betrachten, sehen hier garnichts begehbares. Das kann in Fahrplanauskunftssystemen auf OSM-Basis dazu führen, dass ganz woanders umgestiegen wird. Der Fehler wird so praktisch unsichtbar.
Weide
PS: Die VRR-Auskunft neigt dazu, einen an kleinen Bahnhöfen umsteigen zu lassen. Vielleicht ist das schon sowas… (Es sind sicher zum Teil auch die kürzeren Wege in kleinen Bahnhöfen.)
Nein, das war leider schon immer so. Wenn man aus Soest kommend nach Köln will, wirft er dich manchmal nicht (logischerweise) in Unna, sondern in Holzwickede raus. In Holzwickede musst du dann aber erst durch die Unterführung und außerdem hat sich der Zug schon in Unna stark gefüllt.
Bezüglich des gesamten Routing-Problems habe ich ja schon vor Jahren was auf der Mailingliste geschrieben. Leider hat kein Router die Idee bis heute umgesetzt. Irgendwann vergeht auch die Lust an dem Thema.
Hängt vielleicht vom Alter ab. Ich kenne das noch so, dass jeder Bahnhof pauschal eine “Umsteigezeit” hatte und die Zeiten zwischen Umsteigebahnhöfen (Bahnhof und Busbahnhof etc.) anhand des Luftlinienabstandes der Zentralpunkte ermittelt wurden. Erst “jetzt” geht die Tendenz dahin, tatsächliche Fußwege von Steig zu Steig zu ermitteln.
Die EFA (und auch andere Fahrplanauskunftssysteme) erlauben priorisierte Umsteigebahnhöfe.
Es kann natürlich sein, dass der VRR inzwischen auch Fußwegzeiten einrechnet und nicht mehr schätzt. Dann müssten allerdings auch die Länge des Zuges und die H-Tafel beachtet werden, denn die Zuge halten ja nicht mitten auf dem Bahnsteig. Allerdings ist eine Fahrplanauskunft etwas so Wichtiges und Komplexes, dass man nicht mal eben an so einer wichtigen Stellschraube dreht.
Ich werde jedenfalls weiterhin die Mittelachse als Weg auf den Flächen eintragen, wenn die Leute es nicht wollen, können sie es ja löschen. Es gibt größere Datenprobleme, als 3-4 Extranodes und ein Way.
Die haben eine eigene Datenbank mit Knoten für die Steige. Zwischen denen wird mit OSM-Daten geroutet. Unsere ÖPNV-Daten werden nicht als solche benutzt.
Ich weiß, ein ähnlicher Verein ist ein Kunde von mir Ich habe nur weiter gedacht, wie sie derartige Daten aus OSM gewinnen könnten.
Ich muss meine alten Mails zum Routing über Flächen mal raussuchen. Da gibt’s ein paar tolle Ideen, die ich damals noch nicht umsetzen konnte oder wollte, weil mir die kartographische Ästhetik wichtiger war.
User:maxbe hatte das schon vor 2 Jahren hier im Forum erarbeitet, implementiert und detailliert beschrieben. (Ja, kaum zu glauben, hier im Forum wurden auch mal andere Sachen als Tagging und Reverts diskutiert, wirkt heute alles wie aus einem Paralleluniversum).
Cool, ich habe ebenfalls mit virtuellen Wegen gearbeitet. Hatte die Idee aus einem Spiel, was in Python programmiert war. Worin hat er es denn implementiert? Wurde es veröffentlicht?
Es wurde im Wiki veröffentlicht Falls Du den Quellcode meinst: Nein, der wurde nicht veröffentlicht. Ich halte es nicht für sonderlich hilfreich, zu erzählen, dass man erst dieses, dann jenes und das Programm hier über eine geeignete Datenbank laufen lassen muss. Es hätte ja niemand ähnliche Voraussetzungen. Da setzt sich ein guter Programmierer besser hin, liest die Beschreibung und tippt sein eigenes Programm, als dass er Programme eines schlechten Programmierers runterlädt und dann damit kämpft das Zeug in seiner Umgebung zur laufen zu bringen. Eine osm2pgsql Datenbank und gleichzeitig eine pgrouting-Datenbank wird er nicht haben, das ist doch recht exotisch. pgrouting ist auch ganz lustig zum basteln, weil man sämtliche postgis-Möglichkeiten hat. Es ist aber nicht unbedingt der Router der Wahl fürs produktive Massengeschäft mit Kunden, die nicht mal ne Minute auf ein Ergebnis warten wollen
Flächenrouting ist hier aber gar nicht das Problem. Es kann vielleicht in ein paar Prozent der Fälle helfen, wenn die Bahnsteige überwiegend quer im Weg liegen. Weide schreibt ja in #1 ganz richtig, dass es in erster Linie ein Problem der Multipolygone ist. Viele Router werten die nicht aus und routen dann nicht mal am Rand der Fläche, sondern ignorieren den Bahnsteig einfach. Verständlich, wenn man den Aufwand dafür bedenkt, aber blöd für Bahnhöfe… Insofern hilft Flächenrouten vielleicht doch was: Bevor man sich an Flächen macht, sollte man sich um MPs kümmern, sonst fallen die schönsten Plätze weg.
Danke für die Sources, ich gucke mal drüber. Finde das Thema ansich interessant - wie gesagt, damals habe ich das eher kartographisch betrachtet und fand diagonale Linien eher unattraktiv. Ich würde die erzeugten Ways übrigens aus der DB rausholen, zurück in meinen OSM-Datenstrom fließen lassen und z.B. in osm2po oder einem anderen Router weiterverwenden
osm2pgsql nimmt hier ja eine Menge Arbeit ab, weil es recht viel Logik mitbringt, welche die Flächen reparieren kann. Die meisten Routing-Engines, die ich kenne, arbeiten nicht ganz so komplex. Sieht man ja auch an og2ogr - die Implementierung von OSM ist rudimentär, was ja auch von den Programmieren bestätigt wird.
Abschluss: Ich wünsche mir eigentlich, dass Straßen als Flächen ohne Hilfslinien gemappt werden - dann kommen die Routing-Leute unter Zugzwang und müssen sich Gedanken über eine bessere Lösung machen
Die Prozentzahl steigt aber. Quelle der Probleme sind da die notorisch länglichen Fußgängerzonen. Auf den Parallelstraßen fahren dann oft die Busse. Deren Haltestellen sind dann von der anderen Seite der Fußgängerzone aus ohne Flächenrouting zu weit weg. Das betrifft dann auch nicht nur das Haltestellenrouting … das ganze Fußgängerrouting wird in der Nähe solcher Fußgängerzonen lustig.
Das bedeutet aber im Umkehrschluss für mich: Wenn man unnötige MP - also die ohne Löcher - durch normale Flächen ersetzt, bring das auch schon was, oder?
Seh ich auch so. Es macht die Probleme nicht weg aber seltener … aber es ist so oder so ne gute Sache. Auch viele MPs mit Löchern kann man durch einfache Flächen ersetzen. Ganz Schweden wäre vermutlich ein einziges riesiges Wald-MP, wenn man es nicht auftrennen würde. Dann kann man die namenlosen Waldgebiete auch so geschickt auftrennen, dass einfache Flächen übrig bleiben.
Ist das eigentlich wirklich so schwierig mit den MPs? Beim mkgmap hab ich im Gedächtnis, dass man sowas angeben kann wie: “Wenn eine Relation type=multipolygon und highway=platform oder pedestrian oder … hat, dann nimm highway=pedestrian für alle Member an”.
Das hab ich mir nicht gut genug überlegt… Es kann unangenehme Folgen für das Flächenrouting haben … sinnvolle Wege können die Fläche dann abseits der Punkte verlassen…
Ich habe nur weiter gedacht, wie sie derartige Daten aus OSM gewinnen könnten.
