[Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Stefan
someone561 at gmx.de
Fr Jan 3 08:57:31 UTC 2014
Hallo,
ich frage mich, ob nicht ein Problem ist, dass Kreuzungen immer
detaillierter im vorhanden Namensräumen gemappt werden. Eine
Verkehrsinsel zu mappen in dem man zwei Highway als oneway mappet ist
zwar üblich, aber es handelt sich ja nicht wirklich um Einbahnstraßen.
Also streng genommen ein mapping für Router und Renderer. Das gleich
gilt für die beiden baulich getrennten Spuren. Eigentlich ist das ja
eine logische Straße.
Sollten wir veilleicht überlegen, ob die ganzen Dinge an Kreuzungen wie
z.B. Verkehrsinseln, Abbiegespuren, Abbiegeregeln, Ampeln, Fahrad- und
Füßgängerübergänge in einen eigenen "Kreuzungen" Namensraum sollten und
wir im highway Namensraum nur zwei sich kreuzende Highways hätten.
Dies würde Routen aller Art leichter machen, da diese nicht durch die
verschiedenen Ways einer Kreuzung geführt werden müssten.
Ich habe in den detailliert gemappten Kreuzungen auch immer das Problem,
wo genau ändert sich der Straßenname, wo genau ändert sich der Typ von
secondary zu residential, wo ändert sich die Beleuchtung (lit=yes), ....
Außerdem wäre die Abfrage: "Wie viele Einbahnstraßen hat Hamburg?" ohne
Aufwendige Berechnung möglich. Aber auch z.B. Abfragen, nach der
Gesamtlänge einer Bundesstraße wären leichter zu beantworten.
Viele Grüße
Stefan
Am 21.12.2013 14:50, schrieb Tirkon:
> Leider hat sich auch nach einigen Jahren immer noch kein
> durchgreifendes und praktikables Konzept ergeben, wie der ÖPNV in OSM
> integriert werden könnte. Das Oxomoa Schema bzw seine
> Fortentwicklungen sind zwar ein erster Ansatz, die meisten Eigenheiten
> zu erfassen. Allerdings hat die breite Mapperschaft Probleme, dieses
> Modell nachzuvollziehen. Selbst Spezialisten mappen hier nicht
> einheitlich. Insbesondere aufwendig gemappte Kreuzungen mit ÖPNV
> Routen mag der gemeine Mapper zwecks Maintaining nicht mehr anfassen.
> Die Editoren Potlatch und ID ignorieren ÖPNV Relationen weitgehend.
> Sie warnen nicht, wenn jemand ein Straßenelement aus solch einer Route
> löscht, und sie somit unterbricht.
>
> Das Problem könnte entschärft werden, wenn es einen brauchbaren ÖPNV
> Editor gäbe. Ich möchte hier die Idee diskutieren, einen Routenplaner
> (Navi) Algorithmus für die Erstellung (nicht nur) von ÖPNV Routen zu
> nutzen. Wie man dort einen Start- und Zielpunkt eingibt, gibt man für
> den ÖPNV einfach den Ort der Anfangs- und Endhaltestelle an und lässt
> routen. Durch das Ziehen der Route bringt man diese dann auf den
> tatsächlichen Fahrweg.
>
> Ein Routenplaner, der dieses Vorgehen auf OSM Basis bereitstellt, ist
> http://map.project-osrm.org/
>
> Die Vorteile liegen auf der Hand. Eine Route lässt sich in Sekunden
> bis Minuten zusammenstellen. Das Aufsuchen von Mikrowegen (ein Meter
> Länge) oder z.B. an Brücken stellt damit kein Problem mehr dar. Fehler
> in OSM, die ein Routen über diese Strecke unmöglich machen, könnten
> mit dem Routenplaner Algorithmus gefunden und eingekreist werden. Denn
> der Routenplaner würde sich weigern, über eine solche Fehlstelle zu
> routen. Indem man die Zwischenpunkte immer weiter bis zu wenigen
> Metern an die verweigerte Stelle heranschiebt, könnte man diese
> dingfest machen.
>
> Der Routenplaner Algorithmus könnte für Zugverbindungen auch auf
> Schienenwege erweitert werden.
>
> Auch das Reparieren von Routen (auch nach dem Editieren aufwendig
> gemappter Kreuzungen) würde damit wesentlich erleichtert. Hierzu
> könnte der Routenplaner Algortihmus Vorschläge zur Schließung der
> entstandenen Lücken machen, die man durch Ziehen dann auf die richtige
> Route bringt.
>
> Das Konzept würde sich nicht nur für den ÖPNV, sondern auch für
> jegliche andere Routen wie (Rad-)Wanderwege nutzen lassen.
>
> Das größte Problem an dem Konzept ist allerdings das seltene Update
> der Routenplaner, das allerdings bei dem genannten OSRM Projekt
> vergleichsweise aktuell ist.
>
> Zum Testen würde für's Erste eine Export Funktion für OSRM hilfreich
> sein, die eine berechnete Route als JOSM-taugliche Relation type=route
> ausgibt. Damit könnte man neue Routen erstellen.
>
> Als erstes Demo habe ich die Route "Bus VEJ 411 Georgheil->Norden
> (Verkehrsverbund Ems Jade)" nachgestellt. Die Erstellung hat gerade
> mal wenige Sekunden gedauert. Allerdings nutzt OSRM keine
> highway=service, so dass die hierüber angefahrenen Haltestellen außen
> vor bleiben mussten. Dennoch würde eine solche Erstellungsmethode viel
> Zeit und Mühen einsparen sowie Fehler vermeiden.
>
> Die OSM-Relation der Route:
> http://www.openstreetmap.org/relation/1921181
> Die Route bei OSRM:
> http://www.osrm.at/5Ue
>
> -------
> Als weitere Erleichterung könnte IMHO die Unterteilung einer
> Haltestelle in Plattform und Haltepunkt aufgeben werden. Die Angabe
> der Plattform (z.B. Ort des Haltestellenschildes) wäre ausreichend. Um
> den Haltepunkt zu errechnen, bräuchte lediglich das Lot auf die Route
> gefällt werden. Dass dies möglich ist, beweist der OSM Inspector in
> seinem Adress Layer. Beispiel:
> http://tools.geofabrik.de/osmi/?view=addresses&lon=6.85091&lat=51.21682&zoom=18&opacity=1.00&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads
> Falls als Plattform eine Fläche oder Linie angegeben ist, wird das Lot
> aus deren Mitte gefällt.
>
> Fällen eines Lotes bei Wikipedia:
> https://de.wikipedia.org/wiki/Lot_%28Mathematik%29#F.C3.A4llen_des_Lots
>
> Was meint ihr?
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
Mehr Informationen über die Mailingliste Talk-de