[osm-bnsu] Einladung: How-To Treffen bei infoware am 15.09.2011

[Roland Olbricht]

> Soweit ich Roland Olbricht vom ÖPNV-JOSM-Plugin richtig verstanden habe,
> möchte er durchaus etwas sehr interessantes vorstellen, was sich mit dem
> VRS-Teil optimal verknüpfen lässt.......

Ja, hatte ich eigentlich vor. Leider werde ich es aus beruflichen Gründen 
nicht schaffen, am 15.09. zu kommen. Wenn möglich, würde ich den Punkt dann 
auf dem Spetember-Stammtisch ansprechen.

Im Gepräch mit Marcel Hövelmann ist die Idee aufgekommen, einen einfachen 
ÖPNV-Editor zu entwickeln oder doch zumindest eine Anleitung für Taggen ins 
Wiki zu stellen. Da das ÖPNV-Tagging weder im Konsens noch einfach ist, stelle 
ich das vereinfachte Schema erst mal zur Diskussion, stelle es dann aufs Wiki 
und fange erst dann mit der Implementierung an (auch im ÖPNV-JOSM-Plugin, 
siehe in den Plugins unter "public transport").

Zusammenfassung:

=Physisch=

==Haltestellen==
Mindestens eines der Merkmale
a) einen Bus-/Bahnsteig (railway=platform)
b) ein Haltestellenmast (highway=bus_stop)
c) ein Wartehäuschen (highway=bus_stop + shelter=yes, besser 
public_transport=shelter?)
d) eine Halteposition (public_transport=stop_position)

==Schienen==
a) eigener Bahnkörper (railway=rail)
b) Gleise mit Straßenraum (railway=tram)
c) Spezialfälle: Schwebebahn, H-Bahn, Seilbahnen 
(railway=monorail,funiculaire,...)

==Busspur, O-Bus==
a) Busspur (highway=service + access=no + bus=yes, besser highway=busway?)
b) Spurbus, sehr selten (highway=bus_guideway)
c) Spezialsysteme: Phileas, Translohr und Co. (railway=other?)

=Verkehrsangebot=

a) Alles, was auf Schienen fährt (type=route + route=rail)
b) Alles, was der Straße fährt (type=route + route=bus)
Insbesondere keine weitere Differenzierung, da subway vs. light_rail vs. tram 
vs. S-Bahn ständig verwechselt werden.
c) Tag für Betriebszeiten (auf der Relation)
d) Tag für Taktdichten (auf der Relation)
e) Relation, die alle Linien einer Tarifgemeinschaft einschließt.
f) Tag, ob alle Züge überall halten, oder ob es Eilzüge gibt.

Taggen würde ich Linien auf jeden Fall. Es ist relativ wenig Aufwand (5-15 
Minuten pro Linie), es sind recht langlebige Daten (in Wuppertal z.B. 15 Jahre 
fürs Busnetz, in BNSU typiischerweise einige Jahre), und es ermöglicht hübsche 
Projekte wie öpnvkarte.de (und auch mein Overpass PT Diagrams :) ).

Details:

=Physisch=

==Haltestellen==

Jeder Ort, an dem ein öffentliches Verkehrsmittel hält, hat zumindest eines 
der Merkmale:
a) einen Bus-/Bahnsteig (railway=platform)
b) ein Haltestellenmast (highway=bus_stop)
c) ein Wartehäuschen (highway=bus_stop + shelter=yes, besser 
public_transport=shelter?)
d) eine Halteposition (public_transport=stop_position)
Damit das Mappen einfach wird, reicht es, wenn mindestens eines der Merkmale 
a)-d) gemappt wird (selbst wenn mehrere vorhanden sind). Bis auf den Bahnsteig 
können die übrigen Merkmale wie folgt automatisch abgeleitet werden:

a) Dies ist die genauest mögliche Information über eine Haltestelle. Wenn 
diese nicht gemappt ist, wird es auch nicht abgeleitet, da für die Karten und 
Linienbänder nur Nodes benötigt werden.

b)/c) ein Haltestellenmast oder Wartehäuschen. Dies kann zur Abstraktion 
"Warteort" zusammengefasst werden. Wenn es nur einen Bahnsteig gibt, wird die 
Bahnsteigmitte (Schwerpunkt des Polygons bzw. des nicht geschlossenen 
Liniensegments) als Warteort genommen. Wenn es nur eine Halteposition gibt, 
wird die Halteposition von der Straße 10m herunterprojiziert, wobei die 
Fahrtrichtung (ggf. beide Richtungen) aus den Relationen ermittelt wird, die 
die Halteposition als Element enthalten. Nach links in Großbritannien und Co., 
nach rechts überall sonst.

d) Die Halteposition wird aus b)/c) bzw. der aus a) generierten Warteposition 
erzeugt, indem sie zu allen Relationen auf denjenigen Mitgliedsweg der 
Relation abgebildet wird, zu dem sie den geringsten Abstand hat.

Die Namen sollten per name=? an die Haltestellen kommen, ggf. zusätzlich per 
ref=? (wurde in Italien explizit erbeten), nicht über die stop_area. Eine 
virtuelle stop_area kann leicht aus allen Elementen mit gleichem Namen in 
einem Umkreis von max. 500 Meter erzeugt werden.

Bedarf gäbe es für eine Relation, die explizit auf empfohlene 
Umsteigebeziehungen hinweist und dann die automatischen Umsteigebeziehungen 
ersetzt. Es wäre zu fragen, ob das dann auch stop_area sein soll.

Anmerkungen:
d) ist vorwiegend aus diplomatischen Gründen drin. Aus fachlicher Sicht habe 
ich große Schwierigkeiten damit, weil es diverse Haltestellen gibt, an denen 
stop_position nicht definiert wäre: z.B.
- In Schloss Birlinghoven, Sankt Augustin gibt es schlicht eine lange Busspur 
mit Wartehäuschen in der Mitte, die Busfahrer halten je nach Laune in einem 
Intervall von ca. 50m.
- An zahlreichen Haltestellen, z.B. Wuppertal Hbf, Bussteig 5, halten mehrere 
Busse hintereinander, aber dann auch nur einmal, d.h. die stop_position würde 
um etwa 100m fluktuieren. Es gibt dafür sogar ein Verkehrszeichen, die 
"Doppelhaltestelle", auch wenn diese vorwiegend bei Straßenbahnen verbreitet 
ist.
- Der Kölner Hbf käme bei korrekter Anwendung bei 10 Gleisen auf insgesamt 152 
Haltepositionen, da die Zugspitze je nach Zuglänge und Position der 1. Klasse 
an sehr verschiedenen Orten zu stehen kommt. Das ist sehr viel Mapping-Aufwand 
für sehr wenig Information.
- Dass die stop_position an der Zugspitze liegen soll, ist recht schwierig zu 
erklären. Rund um Köln gibt es zahlreiche falsch gemappte Bahnhöfe, bei denen 
die stop_position in der geschätzten Mitte liegt. Nach dem obigen 
Interpolationsverfahren landet die stop_position zwar ebenfalls falsch, aber 
mir ist schlicht kein algorithmisch stabiler Weg eingefallen, die 
stop_position korrekt zu positionieren (es gibt ja nirgendwo eine Information 
über die Zuglänge).
Wenn das Element optional ist, können die Verfechter es gerne verwenden, aber 
es gibt keinen Zwang zum Falschmappen und auch keine Verschlechterung mehr, 
wenn unbedarfte Mapper korrekte bus_stop durch fehlplazierte stop_positions 
ersetzen.

Der Grund gegen die stop_areas ist ebenfalls, dass es zahlreiche Beispiele der 
Realität gibt, die fürs Mappen verbogen werden müssten:
- zusammengehörige Haltestellen haben nicht unbedingt den gleichen Namen: z.B. 
gehören zum Ostbahnhof in Frankfurt die Haltestellen "Ostbf/Honsellstr." und 
"Ostbf/Sonnemannstr.". Der Hauptbahnhof in Wuppertal heißt mal "Wuppertal 
Hbf", mal "Hbf/Döppersberg" mal "Hauptbahnhof". Köln hat "Köln Hbf", "Dom/Hbf" 
und "Breslauer Platz/Hbf". Grenoble (Frankreich) hat für den Bahnhof die Namen 
"Grenoble" (aus Sicht der SNCF/TER), "Gares" aus Sicht der Straßenbahn, wobei 
letztere dann auch zum Busbahnhof "Gare routiere" gehört.
- Die Zusammengehörigkeiten können sich überlappen, wie z.B. im obigen 
Beispiel von Grenoble. Paris macht das mit Metro und RER ganz massiv. Die 
größten Komplexe sind hier rund um St. Lazare und den Gare du Nord.
- Das Umsteigen kann abweichend von der namensgleichen Haltestelle empfohlen 
werden, z.B. von "Bonn Hbf" auf "Thomas-Mann-Straße", obwohl die dortigen 
Buslinien auch am Hbf halten. Ebenso am Hbf Wuppertal, bei dem in einigen 
Richtungen "Stadthalle" die richtige Haltestelle für die Korrespondenzen ist.
Insofern würde ich sehr dringend dafür plädieren, Umsteigen und 
Namensgleichheit zu entkoppeln. Die Namensgleichheit allein begründet 
eigentlich keine Relation. Bei normalen Straßennamen würde das ja auch niemand 
machen.

==Schienen==

Für einen durchschnittlichen Mapper sollte es eigentlich reichen, die Fälle
- eigener Bahnkörper, offene Schienen (railway=rail)
- Schienen in der Straße, die auch Fahrspur sind (railway=tram)
zu unterscheiden. Ich würde dann noch so etwas wie 
railway=monorail,funiculaire,other zulassen, um Spezialsysteme abzudecken. 
Aber Merkmale wie Signalsystem, Gesetzesgrundlage, Stromversorgung, 
Lichtraumprofil und auch Spurbreite (z.B. ist die Spurbreite der Straßenbahn 
von Mailand weniger als 5% breiter als die Normalspur, was nicht zu erkennen 
ist) sollte man nicht einfordern, sondern nur optional setzen.

Welches Angebot auf der Strecke gefahren wird, sollte nicht auf dem Weg, 
sondern nur mit Relationen gemappt werden.

==Busspur, O-Bus==

Die empfohlene Kombination highway=service + access=no + bus=yes ist für 
Mapper schwer zumutbar. Ohne Editor-Hilfe ist das sehr aufwendig und nicht 
sehr informationshaltig. Stattdessen highway=busway?. Aber das halte ich für 
ein Randproblem. Es gibt eine Tagkombination für Spurbusse 
[highway=bus_guideway], die erwähnt werden sollte. Also
a) Busspur (kein Zugang für normale PKW, ggf. Taxis/Fahrräder oder anderes 
nach lokalen Gepflogenheiten)
b) Spurbus (z.B. Adelaide "O-Bahn")
Dann haben wir zwar die Spezialsysteme Phileas, Translohr und Vergleichbare 
noch nicht geklärt, aber das kann auch Busspur, Spurbus bzw. railway=other 
werden.

=Verkehrsangebot=

Die Frage, wie viel vom Verkehrsangebot gemappt werden soll, ist recht 
umstritten. Konsens ist, dass ein kompletter Fahrplan nicht hineingehört. Aber 
es gibt auch extreme Vertreter, die nicht einmal Linien sehen möchten. 
Hintergrund dazu dürfte sein, dass es in deren Heimat England ein stark 
fluktuierendes Liniennetz ohne Tarifgemeinschaften auf ein sehr offenes 
Auskunftssystem trifft und es technisch machbar erscheint, Haltestellen mit 
Linien- und Fahrplandaten aus dem Auskunftssystem zu verknüpfen. In anderen 
Ländern sind dagegen die Busnetze sehr stabil (in Wuppertal seit 15 Jahren!) 
und auf jeden Fall Teil des lokalen geographischen Allgemeinwissens.

Persönlich würde ich nach dem Fahrgastnutzen auswählen. Das sind Fahrtdauern, 
Betriebszeiten, Taktdichten und Tarifgemeinschaften, ggf. Barrierefreiheit der 
Zugänge. Alles, was darüber hinausgeht, z.B. technische Eigenschaften der 
Fahrzeuge, Betreiber, Marketingname sind eigentlich zweitrangig, aber 
vermutlich für so manchen Mapper der naheliegende Anknüpfungspunkt.

Leider sind die Begriffe aber sehr verwischt:
- In Karlsruhe und Saarbrücken fahren einige Linien sowohl als Straßenbahn wie 
auch als Eisenbahnlinien. In Stuttgart, Hannover, Düseldorf und weiteren 
Städten sowohl als Straßenbahn als auch als U-Bahn. Und zwischen Köln und Bonn 
dann sogar als Straßenbahn, Eisenbahn und U-Bahn, je nach Abschnitt.
- Ähnliche Probleme gibt es bei der S-Bahn: Systeme wie in Berlin (mit 10- 
oder 5-Minuten-Takt und Spezialfahrzeugen lassen sich kaum vergleichen mit der 
S-Bahn Rhein-Neckar mit oft nur einem Stundentakt und normalen Eisenbahn-
Triebwagen.
- Zu allem Überfluss wird der Standard-Name dafür, Stadtbahn, auf der 
öpnvkarte irrtümlich als S-Bahn gemappt, was über Mapping for the Renderer 
regelmäßig zu falschen Typen auf den Relationen führt.
- Meistens sind solche Schienenstrecken normale Linien ohne Abzweigungen oder 
ausgelassene Zwischenhalte. Das sollte auch so zu erkennen sein. Im Gegensatz 
dazu stehen z.B. die RER in Paris und die Metropolitan Line in London, bei 
denen nahezu ohne Taktschema jeder Zug an anderen Haltestellen hält oder ohne 
Halt durchfährt.
Wie man das schlüssig taggt, habe ich ehrlich gesagt keine Idee. Aus meiner 
Sicht dürfte es das beste sein, nur type=route,route=rail oder 
type=route,route=bus zu mappen und dann lieber die Service-Qualität zu 
beschreiben, also
a) Tag für Betriebszeiten (auf der Relation)
b) Tag für Taktdichten (auf der Relation)
c) Relation, die alle Linien einer Tarifgemeinschaft einschließt.
d) Tag, ob alle Züge überall halten, oder ob es Eilzüge gibt. Wenn es eine 
einfache Systematik hat, können es ja auch ein paar Relationen, jeweils pro 
Richtung und Haltestellenfolge sein.
Ebenfalls Teil des Angebotskonzept ist in vielen Orten ein Systemanschluss, 
z.B. Umsteigemöglichkeiten in alle Richtungen in Wuppertal Hbf abends oder 
gerichtete Anschlüsse (Beispiel?). Das sollte eigentlich auch getaggt werden, 
wird aber vermutlich gegenüber die Auskunftssystem-Fraktion schwierig 
durchzusetzen sein. Das kann aber ja alles in den optionalen Teil.

Insbesondere ist das jetzige Tagging-Schema sehr unfallträchtig: Das in 
Deutschland beliebte System, eine von der DB AG betriebene S-Bahn zu haben, 
hat eigentlich gar keinen zugeordneten Typ, so dass route=light_rail dafür 
missbraucht wird - mit dem Ergebnis, dass Stadtbahnen (="light rail" in der 
englischen Sprache) regelmäßig von gutmeinenden Mappern kaputtgetaggt werden.

Richtungen würde ich auf jeden Fall getrennt mappen, da sich nur so komplexere 
Linienverläufe abbilden lassen (z.B. Schleifen im Gegensatz zu getrennten 
Fahrtrichtungen oder alternativen Linienwegen für einzelne Fahrten, Ringlinien 
in eine Richtung (Münster, Linie 3+4) im Gegensatz zu Ringlinien in beide 
Richtungen (Düsseldorf, 706)). Richtungsaufspaltungen braucht man sogar für 
Schienenstrecken, siehe Berlin-Ostkreuz oder die Pariser Metrolinie 10.

Viele Grüße,

Roland

> Marcel
> 
> Am 25.08.2011 20:53, schrieb Bernd Weigelt:
> > Am Mittwoch 24 August 2011, 11:13:40 schrieb Knauf, Heinrich:
> >> Bislang sind folgende Themen geplant:
> >> - Neue Plugins für JOSM
> >> - Der Verkehrsnachrichtendienst TMC in OSM
> >> - Diskussion: Status des ÖPNV-Mappings in der Region des VRS
> >
> > In Anbetracht der Diskussion zum Thema VRS würde ich den JOSM-Teil gerne
> > knapp halten, ich denke eine Stunde sollte ausreichend sein.
> > Man kann natürlich auch, begleitend zur Diskussion, entsprechende
> > Hinweise in JOSM geben, die entsprechenden Plugins gibt es ja schon.
> >
> > Bernd
> >
> >
> >
> > _______________________________________________
> > bonn-rhein-sieg mailing list
> > bonn-rhein-sieg at lists.openstreetmap.de
> > http://lists.openstreetmap.de/mailman/listinfo/bonn-rhein-sieg
>