ÖPNV Editor

Schau mal auf http://wiki.openstreetmap.org/wiki/DE:Aachen_Hinweise#Buslinien
Dort steht einiges wie in Aachen das Oxomoa-Schema umgesetzt wurde.
Insbesondere sind dort Typen für die diversen Relationen definiert, die im
Oxomoa-Schema ja leider weggelassen wurden.

Fang mit Haltestellen an, das ist noch ziemlich übersichtlich.
Zu unterscheiden sind public_transport=stop_position (auf dem Linienweg,
ein oder zwei mal) und public_transport=platform (die Zugangsstelle, neben
dem Weg, üblicherweise die Position des Haltestellenschildes, 0-2 mal).
Die Relation dazu (type=public_transport + public_transport=stop_area)
ist mit 1-4 Mitgliedern ebenfalls recht übersichtlich.

Schau dir dann in einem Gebiet, wo das Oxomoa-Schema schon verwendet
wird, an, wie es dort gemacht wird (z.B. Aachen oder Dortmund).

Die Grundzüge sind eigentlich einfach. Für eine Linie werden zwei Relationen
definiert, je eine für jede Richtung. Das hat Vorteile bei unterschiedlichen
Wegführungen z.B. wegen Einbahnstraßen oder bei getrennten Fahrwegen.
Man hat je Richtung immer einen kontinuierlichen Weg.

Man trägt in eine Richtungs-Relation (type=route + route=bus/…) zuerst
die Linienführung als Abfolge der benutzten Wege ein. Danach für jede
angefahrene Haltestelle die Stop-Positionen (public_transport=stop_position)
und die Zugangsstellen (public_transport=platform) ein.

Die beiden Richtungs-Relationen (und ggfs. Alternativ-Routen) werden in
einer Linien-Relation (type=line + line=bus/…) zusammengefasst.
Das heißt alle Richtungs- und Alternativ-Relationen sind Mitglieder der
Linien-Relation. Nur die Routen-Relationen sind Mitglieder einer Linien-Relation.

Das hat es mittlerweile bis zu einem JOSM-Plugin geschafft.
Das habe ich selber allerdings bisher noch nicht ausprobiert.

Laut der Beschreibung (Stand April 2010) werden die Routen gemäß dem
Oxomoa-Schema unterstützt, Haltestellen-Relationen jedoch noch nicht.

Ist leider etwas lang geworden, aber vielleicht hilft es ja.
Edbert (EvanE)

Hi,

Das Aachener Schema (so ungefähr tagge ich hier in Nürnbeg auch) ist in der Praxis nicht redundanzfrei.
Damit in der ÖPNV-Karte die Linie mit angzeigt wird, muss sie in der “Routen-Relation” mit angeben werden.
Sie wird leider nicht von der “Linien-Relation” mit-vererbt.

Ditto oxoma:
Man möge den Verbund stets mit angeben, nur hab’ wir ja alle Linien ja schon in einer “Verbund-Relation”,
demnach ist “network=…” in Linien-Rel. ebenfalls redundant.

Obwohl ich schon einige hundert Busrelation erstellt habe, bin ich mit den OPNV-Plugin nicht zurechtgekommen.
Muss wohl an mir liegen :wink:

Ciao,
Frank

Hallo Frank

Redundanzfreiheit ist nicht unbedingt das Ziel von OSM.
Die Ref-Angabe (nur die Nummer) gehört meiner Meinung nach
an jede Relation. Bei den Linien-Relationen wird daher zur
Unterscheidung als Ref-Angabe ‘Bus ’ vorgeschlagen.

Was die Network-Angabe betrifft, bin ich der Meinung, dass es
sinnvoll ist, die Verlinkung in beide Richtungen anzugeben.
Also:
Network-Relation und Network-Angabe in jeder enthaltenen Relation.

Das mag aus Informatiker-Sicht nicht optimal sein, erleichtert aber
in der Praxis die Qualitätssicherung.

Hast du die aktuelle Version des ÖPNV-Plugins und stimmt diese
(noch) mit der Beschreibung (Stand April 2010) überein?

Edbert (EvanE)

Ich auch. Ich habe mal versucht mit einer kleinen, einfachen Linie anzufangen und hier Forum nachgefragt. Aber da nicht so richtig Einigkeit herrschte, habe ich es dann ganz gelassen. Außerdem soll nächstes Jahr das Liniennetz in Lübeck sowieso komplett überarbeitet werden.

Da hört mein Verständnis leider schon auf. Das klingt alles sehr abstrakt.

Mir ist wirklich nicht klar, wo ich was hinsetzten soll. Nehmen wir als einfachstes Beispiel eine einfache Bushaltestelle mit Haltestellenmast, ohne weitere besondere Einrichtung. Der Bus hält einfach am Straßenrand, ohne Haltebucht. Einige Meter weiter ist dann die Haltestelle für die Gegenrichtung.

Wie ich das Ganze jetzt verstehe:
public_transport=stop_position kommt auf die Straße zwischen den beiden Haltestellen.
public_transport=platform kommt neben die Straße anstelle des highway=bus_stop. Ich habe ‘platform’ auch schon als Linie gesehen, ist das richtig?

Müssen ‘platform’ oder andere Dinge an das (Fuß-)Wegenetz angeschlossen werden? Insbesondere, wenn diese als Linie ausgeführt sind?

Christian

Auch wenn man nicht durchblickt durch die Feinheiten des ÖPNV-Taggen kann man doch trotzdem die Linien mappen: Alle entsprechenden Straßen und alle entsprechenden Haltestellen in eine Relation mit type=route, route=bus und ref=*. Fertig!
Irgendwann kann dann ein Experte kommen und das verfeinern. Aber bis dahin ist da immerhin schon was gemappt (das übrigens auch bei öpnvkarte.de angezeigt wird)!

Hallo Christian

Einfacher geht es eigentlich nicht.

  • Ein Punkt wo der Bus ungefähr auf der Straße hält.
  • Je ein Punkt für die Haltestelle, also neben der Straße.
    Die Haltestellen-Relation kannst du gegebenenfalls weglassen, falls dir das
    Kopfschmerzen bereitet. Das kann jemand auch nachträglich ergänzen.

Dass die Schreibweise etwas kompliziert aussieht, liegt an zwei Dingen:

  • Es sollten Schlüssel verwendet wrden, die noch nicht anderweitig
    benutzt wurden.
  • Das Ganze (Haltestellen, Routen, Linien) kommt von einer Diplom-/Studien-
    Arbeit und musste daher eher theoretisch sauber als praktisch nutzbar sein.

So ist es (meiner Meinung nach).
highway=bus_stop kannst du im Prinzip stehen lassen, da es keinen
Konflikt mit public_transport=platform darstellt.
So können auch Anwendungen, die das Oxomoa-Schema noch nicht
unterstützen, eine Haltestelle erkennen.

public_transport=platform ist eigentlich nur als Punkt definiert, wird
aber manchmal auch in seiner Länge als Weg eingetragen.
Ob das tragfähig ist, wird die Zukunft zeigen.

Was die Verbindung von public_transport=platform mit dem Wegenetz
betrifft sollte man erst mal sagen an welches? An die Fußwege, was ja
für den typischen ÖPNV-Nutzer das Wesentliche ist oder an die Straße,
auf der der Bus verkehrt?

Ein Problem ist, dass Fußwege sehr oft nicht separat erfasst sind.

Wie auch immer, sollten Router in der Lage sein auch zu einem Punkt
zu routen, der neben einem Weg liegt.
Ebenso sollten Router, die den ÖPNV unterstützen mit der Tatsache
umgehen können, dass eine Zugangsstelle grundsätzlich neben
dem Weg liegt, der vom ÖPNV verwendet wird. Einen virtuellen
Weg dafür einzutragen, halte ich für falsch.

Weiter sollte man mehrere Fälle unterscheiden:

  • Ein Punkt relativ nahe an der Straße (10-15 Meter)
    Hier sehe ich keine Notwendigkeit, das ans Wegenetz anzuschliessen.
  • Eine Haltestelle als Linie neben einer Straße
    Dazu habe ich mir noch keine Meinung gebildet.
  • Eine Zugangsstelle unabhängig von einer Straße, Beispiel Bahn
    und Plattform (Linie/Fläche) im Bahnhof.
    In so einem Fall sollte eingetragen werden, wie man vom restlichen
    Wegenetz zur Plattform kommt.

HTH
Edbert (EvanE)

Bei mir ist das Problem umgekehrt, die Experten waren schon da. :wink:
http://www.öpnvkarte.de/?lat=52.13387&lon=11.63293&zoom=12&layers=BT

Ich wollte lediglich ein paar Fehler und Ungereimtheiten in Angriff nehmen. Und beim Eintragen einer neuen Straßenbahn-Haltestelle, wurde ich vor’m Hochladen, in JOSM, von Fehlermeldungen erschlagen.

Den ÖPNV-Editor in JOSM kannte ich noch nicht, nach meinem ersten Eindruck: ziemlich unhandlich (aber das fand ich von JOSM anfangs auch, jetzt mag ich ihn nicht mehr missen).

Ansonsten finde ich die Diskussion recht anregend. Vielen Dank an Alle.

Hallo Edbert,

ja: public_transport: Version 22148 @ JOSM/1.5 (3514 de)
nein: Neben “Create Stops from GPX” und “Route patterns” gibt es nun einen dritten Menüpunkt “Create Stops from GTFS”.

Muss jedoch gestehen, dass ich mich bisher mit Googles General Transit Feed Specification noch nicht auseinander gesetzt habe.
Dagegen ist Oxomoa ja fast “easy-peasy” :wink:

Ciao,
Frank

public_transport=platform ist ja bei der Bahn der Bahnsteig und beim Bus ist es nur mindestens das Haltestellenschild, sofern man den “Bahnsteig” für den Bus nicht genau sehen kann. Bei Haltetaschen ist es das gerade Stück des Fußweges, manche Haltestellen haben sogar einen expliziten Zugang und dann an einem der platform-Enden Seite Rasen oder etwas anderes was die Plattform begrenzt. Ich trage die deshalb auch als Strich ein, wenn es sich anbietet und ich die Daten habe.

Ja, die Platform als Linie sollte Bestandteil des Fuß-/Radweges sein, sofern sie, wie sehr oft quasi in den Weg integriert ist. Ich schließe dann die Fortsetzung des Weges dort direkt an und tagge den highway=* lieber mit den Objekteigenschaften zusätzlich zu public_transport=platform, weil ein highway=bus_stop nach altem Schema ist das ja eh nicht mehr.

Ein virtueller Zugangsweg ist aus meiner Sicht auch falsch, weil die Platform ja selbst schon in der route-Relation mit drin ist, dort sollten sie die Auswerteprogramme/Router auslesen und immer zuordnen können, obwohl sie ja schon eigentlich nicht wirklicher Bestandtzeil der Route an sich sind, ist das technisch noch einzusehen. Schade und nerviger ist eher, das die ÖPNV-Map nicht ohne forward/backward klar kommt oder nicht mit der Tatsache, das die stop_area keinen Namen hat, und sich dieser dann in der stop_area_group-Relation befindet, weil man z.B. den Taxistand am Busbahnhof da noch mit rein getan hat und das ganze als eine Einheit ohne gesonderte Benennung zu sehen ist.

Eigentlich sollte eine stop_area immer einen Namen haben.

Ein Taxistand gehört sicher nicht in die gleiche stop_area wie
eine Bushaltestelle, da es sich um ein anderes Transportmittel handelt.

Taxistände haben auch nicht unbedingt einen Namen.
Von daher gibt es keinen Grund die in die gleiche stop_area
wie die Haltestelle zu stecken.

Das kann sinnvoll nur in einer stop_area_group zusammen auftauchen.

Das mit den Namen ist ein allgemeines Problem.

  • Die Haltestelle hat einen Namen.
  • Die Relation hat einen Namen (meist sind die gleich)

Jetzt ist es aber so, dass die Eigenschaften einer Relation, die
Eigenschaften sind, die für die Relation als als Gesamtheit gelten.

Diese Eigenschaften können nicht automatisch auf die einzelnen
Mitglieder der Relation übergehen.

Ganz offensichtlich wird das bei Wanderwegen:
Der Name des Wanderweges hat nichts mit den Namen der Wege
zu tun, die als Mitglieder in der Wanderweg-Relation enthalten sind.

Fazit:
Der Name der stop_area-Relation ist nicht der Name der Haltestelle.
Er dient zur Zeit nur zur einfachen Zuordnung durch die Nutzer.

Edbert (EvanE)

Hallo,

das Pluginin ist für die Hardcore-Fraktion gemacht:

  • Ticket und was zum Knappern kaufen, in den Bus reinsetzen und bis zur Endhaltestelle (und zurück) den Track aufzeichnen, dabei Bushaltestelle festhalten
  • Zuhause “Create Stops from GPX”

Nun fahren doch einige Mapper gar nicht mit dem Bus mit, sondern mappen eine Straße, ein Gebiet. Stehen dabei plötzlich vor einem Schild mit grünem H und denke sich “Oopsi, Du bist eine Bushaltestelle, dich nehm’ ich mal mit auf”.

Folge: Viele einsame Bushaltestelle in der Karte, welche keine Beziehung (Relation) untereinander pflegen.

Wäre es nicht schön, wenn

  • ich mir mit dem Plugin in einem JOSM-Ausschnitt alle Bushaltestelle (ggf. alle mir ref=65) anzeigen lassen kann.
  • ich sortiere die Haltestelle in logischer Reihenfolge in einem Fenster in vorgeblendeter Tabellenform
  • Plugin generiert nun die Streckenführung (ggf. manuelle Korrektur) und speichert alles zusammen (incl. stop_area-Schnick-schnack) als Relation ab.
  • Happiness?

Ciao,
Frank

Das wird sich bei mir auch in 2 Jahren noch nicht geändert haben. Die Busse werden zu 95% nur von Schülern benutzt, nicht selten hat eine Buslinie 5 Varianten die sie täglich fährt und ändern tut sie sich auch noch jährlich. Der ÖPNV hat hier auf dem Land nunmal keine Bedeutung und so wird er auch gemappt. Nur für ein paar Schüler die sowieso wissen wie der Bus fährt, mache ich nicht solch einen Aufwand, lieber nehme ich die Eigenschaften jedes unbedeutenden Weges auf. Selbst wenn ich mir die Busfahrpläne anschaue, weiß ich nicht 100prozentig, wo die Busse nun genau langfahren und vormittags mitfahren will ich auch nicht.

Doch, das ist es ja gerade, das ist eine Ausnahme.
Siehe den Busbahnhof Greifswald Süd:
http://öpnvkarte.de/?zoom=18&lat=54.07701&lon=13.39864&layers=BT

Der hat 5 Straßenspuren und die Östlichste davon ist ein Taxistand.
Da stop_area ja die gesamthaltgruppe der Busse ist, aber in diesem Fall mal ausnahmsweise nicht mit dem echten Busbahnhof, so wie man ihn vor Ort wahrnimmt,
identisch ist, habe ich natürlich das “Bahnhof Greifswald Süd” (was nach längerem überlegen ja nicht zur stoparea “Greifswald Süd” der Bahn gehört, da ja schon der Name anders ist (die Bezeichnung ist die offizielle von den Busanzeigen)) in die stop_area_group gepackt. Ich ging da davon aus, das die stop_area_group Bezeichnung nach unten durchvererbt wird, wenn der echte Busbahnhofsbestandteil des Busbahnhofes keinen Namen hat, weil stop_area_group ja nach Modell zu Gruppierung der stop_area + Zubehör dient.

Ja, bis auf die Ausnahme eben… :wink:
Es würde in dem Fall ja niemand vom Taxistand neben den 4 Bushgaltespuren reden, sondern eher davon, daß der Taxistand sich auf dem Busbahnhofsgelände befindet.

Ja, das ist soweit klar, eigentlich fehlt in dem Modell ja noch die Realtion der “echten” Einzelhaltestelle (bestehend aus stop_position + platform), weil dann währ das konsistent mit den route-Relationen und man
bräuchte da nur die echte Einzelhaltestelle in die Relation aufnehmen und sofort ist klar, wo sich die Zugehörige Plattform für den Haltepunkt befindet, weil daran krankt
leider auch noch das Oxomoa-Schema. Bei gemeinsamen Zugängen kommen die dann in die stop_area, was ja die gleichbenannte Gesamthaltgruppe (also Ansamlung von Einzelhaltestellen(realtionen) mit gleichem Namen) ist. Die Gesamthaltgruppe wird dann in der übergeordneten Ebene (stop_area_group) mit den mit ihr assoziierten verkwehrstechnischen Einrichtungen wie Taxiständen angereichert.

Das ist klar, weil so funktinieren die Relationen ja allgemein.

Doch, nach dem Modell ist die stop_area die Ansammlung von Einzelhaltestellen mit gleichem Namen,
weil wär da nicht so, könnte man ja alle Einzelhaltestellen in eine große stop_area-Relation reinpacken.

Hallo Fabi

Ich denke, die Frage von umfangreichen Haltestellen wie es Busbahnhöfe
sind, ist beim Oxomoa-Schema meines Erachtens nicht bedacht worden.

In meinen Augen stellt sich ein Busbahnhof als eine Ansammlung von
stop_areas dar. Einzelne Buslinien halten ja nicht beliebig irgendwo
im Busbahnhof sondern an bestimmten Haltestellen.

Von daher würde ich jede Haltestelle (stop_position + platform) als eigene
stop_area erfassen. Die haben ja alle unterschiedliche Haltestellen-Namen.
({Busbahnhof xxx} Bussteig yy)

Die Gesamtheit der Bushaltestellen würde ich dann zu einer stop_area_group
zusammenfassen. Darin kann dann auch gut die Taxi-Spur aufgenommen werden.

Die Fläche des Busbahnhofes inkl. Gesamtname kann man gut mit dem Tagg
amenity=bus_station erfassen. Ob das besser zur stop_area_group gehört
lasse ich einmal aussen vor. Ein eigener geschlossener Weg dafür halte ich
auf jeden für Fall sinnvoll.

Edbert (EvanE)

Ein eigener Name für jeden Bussteig ist im Oxomoa-Schema durchaus vorgesehen: Dafür gibt es im public_transport=platform-Objekt die Tags name und ref.

Auf diese Weise lässt sich ein Muster wie Hauptbahnhof/Bussteig A1, Hauptbahnhof/Bussteig A2 usw. einwandfrei innerhalb einer stop_area-Relation darstellen. Eine stop_area_group wird dafür nicht benötigt.
Zu stop_area_group (Gesamthalt-Gruppe) schreibt Oxomoa sogar ausdrücklich:

Taxi-Stände scheinen allerdings im ursprünglichen Oxomoa-Schema nicht in eine stop_area zu gehören, sodass dafür eine stop_area_group definiert werden muss.

Hallo,

das einzige Mal, wo ich bisher eine stop_area_group verwendet habe, war der Nürnberger Hauptbahnhof (http://www.openstreetmap.org/browse/relation/962582).
Vielleicht hätte man auch die 3 Bahnhöfe einzeln jeweils als Gesamthalt-Gruppe aufführen können und somit 962582 weglassen können.

Ciao,
Frank

Doch, die sind schon mit bedacht, aber nur in Teilen und nicht für alle Ausnahmen.

Das würde ich auch so machen, nur haben die Bussteige da weder name=* noch ref=*
Ich hab dann doch noch ein Foto vom Busbahnhof ausgebuddelt, obwohl ich im
Moment meist Zettel oder Audiomapping mache und das Handy nur im Norfall nehme, da nicht
sehr robust und Kamera lahm:

http://wiki.openstreetmap.org/wiki/File:27042010215.jpg

amenity=bus_station kannte ich noch gar nicht. Nach dem Zitat das MetiorErgoSum gepostet hat, müßte
man ja sogar den Eisenbahn-Bahnhof “Greifswald Süd” und den Busbahnhof “Bahnhof Süd” in eine stop_area_group stecken, wo ich beim taggen auch Probleme hatte (wie ist denn dann der name der stop_area_group, weil ohne Bezeichnung kann man sie sich ja auch schenken “Bahnhof Greifswald Süd”?), mich dann aber dafür entschieden habe erst mal nur den Busbahnhof mit Taxistand als stop_area_group aufzufassen.

So isses leider.

Deshalb mal was für Otto Normalmapper:

Wenn jemand eine fehlende Bushaltestelle findet und sich nicht in die endlosen
Diskussionen einarbeiten will, dann kann er/sie einfach eintragen:

Ein Punkt neben der Fahrbahn – etwa da, wo man einsteigt – mit den Tags:
highway=bus_stop
name=Karnickelweg
shelter=yes
tactile_paving=no
bench=no
platform=2
bus_lines=47;11;…

Wenn man irgendwas nicht erfasst hat, dann lässt man es halt weg. Aber wenn
diese Angaben alle da sind, dann braucht da keiner mehr extra hingehen.

Anmerkungen zu den Tags – so wie ich sie verstehe:

“shelter” bedeutet nicht “Haltestellenhäuschen”. Es kann auch eine andere
Unterstellmöglichkeit sein. Die Frage ist nur: Kann man da bei Regen so im
Trockenen bleiben, dass der Bus nicht vorbeirauscht?

“tactile_paving=yes” bedeutet nicht unbedingt “brauchbare Blindenleitspur”. Wer
ein schlechtes “tactile_paving” findet, sollte einen Kommentar dranschreiben,
damit der nächste Mapper nicht wieder aus dem “no” ein “yes” macht.

“bench” bedeutet nicht “Bank der Verkehrsbetriebe”. Die Frage ist nur: Kann
man da in der Nähe so sitzen, dass der Bus nicht vorbeirauscht?

“bus_lines” ist nur ein vorläufiges Tag. Da werden die Buslinien erstmal
notiert, bis sie jemand in eine Relation einträgt. “…” steht für “nicht
erfasste weitere Linien”

“platform”: gibt es meist nicht – es ist die Bussteignummer.

Weide

Zustimmung zu fast allem, allerdings ist für die Aufzählung der Buslinien das Tag route_ref vorgesehen, siehe http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dbus_stop. Laut Tagwatch wird es auch fleißig benutzt, was man von bus_lines nicht behaupten kann.

Da muss ich Dir schlicht und einfach zustimmen :slight_smile:

Weide