Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen.
Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität. Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Gehen wir von drei typischen Benutzern aus: Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss. Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und sucht Wege über Rolltreppen zum Bahnsteig. Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um zum Bahnsteig zu kommen, er braucht entsprechende Wege. Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen wir diese Teile in einer Relation zusammen. Wir brauchen also die Plattformen und alle Treppen, Rolltreppen und Aufzüge einzeln. Der VRR will auch Echtzeitanpassung für Rolltreppen und Aufzüge. Wenn diese außer Betrieb sind, z.B. durch Wartungsarbeiten, dann muss das im Routing berücksichtigt werden. Wir brauchen da noch eine eindeutige Identifikation. Die OSM Modellierungen dieser Verbindungselemente sind im OSM Wiki beschrieben. Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen ist das irreführend. Wir brauchen also zusätzlich Flächen. Generell wollen wir alle öffentlich begehbaren Flächen in den Bahnhöfen darstellen und deshalb wollen wir sie erfassen. Über den VRR und die Verkehrsbetriebe haben wir Zugang zu den Bahnhöfen. Wir bekommen auch Erlaubnisse zum Messen und Fotografieren und oft auch Einblick in Pläne. Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das sind bekannte OSM Objekte ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position) Als letztes Datenelement brauchen wir die Eingänge. Die gibt es auch als OSM Objekt (http://wiki.openstreetmap.org/wiki/Entrance). Damit bestimmen wir, ob ein Bahnhof überhaupt barrierefrei ist oder nicht. Er ist dann barrierefrei, wenn es zu jeder Plattform einen Eingang gibt, von dem aus ein Rollstuhlfahrer auf die Plattform kommt. Wenn wir Indoor-Karten erstellen wollen, brauchen wir eine vollständige Gebäudemodellierung. (Link..) Soweit sind wir aber noch nicht. Wir werden berichten, wenn wir mit dem Konzept fertig sind. Generell gehen wir bei der Datenerfassung extrem vorsichtig vor. Wir wollen niemand etwas kaputt machen. Wir sind schon seit einiger Zeit mit der Münchner OSM Gruppe in Kontakt und haben viel gelernt. Speziell achten wir auf folgende Punkte. · Wegelemente die bereits vorhanden sind müssen erhalten bleiben, da sonst die OSM Router Probleme bekommen · Relationen die Linienverläufe des ÖV darstellen dürfe nicht verletzt werden · Die Erweiterungen dürfen das Kartenbild der OSM Karte nicht stören. Wir kontrollieren unsere Erweiterungen in Keep Right zum größten Teil. Wir sind jederzeit bereit Fehler sofort zurück zu bauen, wenn wir was falsch machen und das uns jemand meldet. Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man ist immer noch besorgt, dass Daten, die in die Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen. Mit dem VRR bekäme OSM einen sehr großen Nutzer. Er ist der größte Verkehrsverbund in Deutschland. Die Fahrplanauskunft hatte im Frühjahr dieses Jahres 54 Millionen Fahrten pro Monat gerechnet. Der VRR will aber nicht nur die OSM Daten nutzen sondern ebenfalls Daten der Community und der Öffentlichkeit zur Verfügung stellen. Zur Zeit könnten das alle Haltestellen und Haltepunkte, aber auch alle Linienwege, sein. Wir können gerne eine technische Diskussion aufnehmen, wie diese Daten in die OSM Datenbank fließen können. Man muss allerdings bedenken, dass Haltestellen und Linienwege sich oft ändern. Änderungen auf Grund von Baustellen sind zeitlich befristet und hier muss geklärt werden, ob und wie das einfließen kann. Es ist nicht nur so das der VRR in Zukunft auf OSM umstellen möchte, es werden sondern noch weitere Verkehrsverbünde und Betriebe diesem Beispiel folgen. Im Folgenden erläutern wir die Objekte und Tags, die wir bei den Modellierungen benutzen. Wir sehen den Bahnhof als ein Bauwerk an, dabei gibt es einfache Bauwerke und sogenannte Gebäude. Zu den einfachen Bauwerken gehören die Schienen, der Haltepunkt, die Plattformen, die verbindenden Elemente (Treppen, Fahrstühle und Rolltreppen) und die Eingänge. Zu Gebäuden zählen wir noch weitere Flächen, wie Tunnelflächen. Einfache Bauwerke: Objekt: Schiene (Type: Way) Schienen werden von uns nicht angefasst. Das einzige was wir machen, wenn zu wenig Schienen eingezeichnet sind, wie es bei U-Bahnlinien der Fall ist, dann erweiteren wir diese möglichst nach der genauen Lage. Objekt: Haltepunkt (Type: Node auf dem Way Schiene) - railway = stop (vorher haben wir station getaggt, es war uns nicht ganz klar was der unterschied zwischen Station und Stop in diesem Fall ist) - public_transport = stop_position - train = yes - ref = 1 (Gleisnummer) - name = Ostbahnhof München Wir wollen damit den genauen Haltepunkt des Fahrzeuges auf der Schiene kennzeichnen. Objekt: Eingang (Type: Node) - entrance = yes oder - railway = subway_entrance (wenn es ein U-bahn Eingang ist) oder - entrance = main (wenn es sich um den Haupteingang handelt) Wobei für uns die Eingangsunterscheidung unrelevant ist. Objekt: Plattform (Type: Flächen) - area = yes - name = Untertürkheim, Bahnsteig 1 - public_transport = platform - railway = platform - ref = 1 (Gleisnummer) - layer = ... - level = .... - train = yes In den vorhandenen Daten sind Bahnsteige aus Routinggründen häufig zweigeteilt. Um diese wieder zu vereinigen, werden sie durch eine Relation zusammengefasst. Wir benutzen die Relation stop_area. Falls dies nicht gewünscht wird könnten wir auch eine eigene Relation anlegen. Tags die schon vorhanden sind werden nicht von uns gelöscht. Verbindende Elemente: Objekt: Treppe (Type: way) - highway = steps - level = 0,1 Treppe bekommen bei uns immer das Level von dem aus sie beginnen zu dem Level wo sie hinführen. Tags die schon vorhanden sind werden nicht von uns gelöscht. Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Steps Objekt: Rolltreppe (Type: way) - highway = steps - escalator = yes - level = 0,-1 Rolltreppe bekommen bei uns immer das Level von dem aus sie beginnen zu dem Level wo sie hinführen. Tags die schon vorhanden sind werden nicht von uns gelöscht. Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Escalator Objekt: Aufzug (Type: way) - highway = elevator - level = -1,0 Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Elevator Tags die schon vorhanden sind werden nicht von uns gelöscht. Gebäude mit weiteren Flächen: Objekt: Tunnel (Type: Fläche) - area = yes - tunnel = yes - level = ... - layer = ... - building = yes (es handelt sich um ein Indoor-Elment und soll in der Karte angezeigt werden) - designation = Unterführung Es werden die Fußwege auf den Tunnelflächen ebenfalls, erstellt bzw. wenn diese schon vorhanden sind, dann werden diese nicht gelöscht bzw. verändert. Objekt: Bahnhofshalle (Type: Fläche) - name = München Ostbahnhof - railway = station - building = yes - area = yes Werden meist so gelassen wie sie in OSM schon von vielen Usern gepflegt und angelegt wurden. Um uns mit den unterschiedlichen Modellierungsarten vertraut zu machen und um unseren Kunden aussagekräftige Beispiele zu liefern, haben wir bisher folgende Bahnhöfe modelliert: Bochum Hbf Bockum-Hövel Bönen Bösensell Buldern Dortmund Hbf Drensteinfurt Duisburg Hbf Dülmen Düsseldorf Hbf Düsseldorf Flughafen Düsseldorf-Benrath Ennepetal Essen Hbf Gelsenkirchen Hbf Hagen Hbf Haltern am See Hamm(Westf) Holzwickede Kamen Köln Hbf Köln Messe/Deutz Köln-Mülheim Leverkusen Mitte Müllheim(Ruhr)Hbf München Ostbahnhof (München) München Vaterstetten (München) Sankt-Martin-Straße (München) Kirchheim (Stuttgart) Untertürkheim (Stuttgart) Schwabstraße (Stuttgart) Vaihingen (Stuttgart) Winnenden (Stuttgart) Freiburg Hbf (Freiburg) Mit freundlichen Grüßen Tracy (taoxue) i.A. Mentz Datenverarbeitung GmbH Am 23. Juli 2013 10:49 schrieb Wilhelm Spickermann <o...@spickermann-d.de>: > Am Mon, 22 Jul 2013 16:43:25 +0200 > schrieb fly <lowfligh...@googlemail.com>: > > > Hat sich das denn jetzt aufgeklärt oder geht das weiter ? > > taoxue hat vorhin mit mir Kontakt aufgenommen und ich habe dazu geraten, > die Sache hier in der Liste zu besprechen. Ich denke, dass wir > akzeptable Lösungen finden können, aber die Sachen müssen jetzt in der > Liste geklärt werden. > > Wilhelm > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de