[Talk-de] Einführung eines neuen Tags (globaleID)

[Gerhard Hermanns]

Hi,

zunächst einmal: Ich finde es großartig, dass sich da etwas zu 
entwickeln scheint (ein Hoch auf den VRR  :-)  )

Ich habe den Thread nur überflogen. Falls das Folgende also schon 
erwähnt wurde oder nicht passt, einfach ignorieren ...

Ich möchte hier kurz einen Querverweis machen auf einen aktuellen Thread 
im OSM-Forum, wo es um ein paar Ideen bzgl. des ÖPNV-Schemas geht [1]. 
Der User Weide hat hier eine Vorversion [2] zu etwas erarbeitet, was mal 
ein Proposal zu einem überarbeiteten public_transport-Schema werden könnte.

Die meisten der Punkte betreffen ÖPNV-Routen, aber es gibt auch 
Ideen/Ergänzungen z.B. zu "platform". Möglicherweise gibt es hier 
zumindest an einigen Punkten Synergien? Es wäre schade, wenn diese 
beiden Arbeiten parallel existieren würden ohne voneinander Notiz zu 
nehmen ...


Grüße
Gerhard (Seoman)

[1] http://forum.openstreetmap.org/viewtopic.php?pid=349000#p349000
[2] http://wiki.openstreetmap.org/wiki/User:Weide


Am 23.07.2013 11:40, schrieb Tracy Kasperczyk:
> 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 <osm at spickermann-d.de>:
>
>> Am Mon, 22 Jul 2013 16:43:25 +0200
>> schrieb fly <lowflight66 at 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 at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

-- 
Gerhard Hermanns, Dipl.-Phys.

Universität Duisburg-Essen
Fakultät für Physik
Physik von Transport und Verkehr
Lotharstraße 1
47057 Duisburg

Office: MD 262
Phone:  +49 203 379-3901
Fax:    +49 203 379-6564
E-mail: gerhard.hermanns at uni-due.de