ÖPNV Bus stop_position

Dann kannst Du kein Nahverkehrs-Mapping betreiben. So hart muss man das formulieren. Jeder User kann nur das mappen, was er oder sie auch in der Lage ist zu mappen. Wer ein Auto hat, das nur 50 fahren kann, gehört damit auch nicht auf die Autobahn, darf aber sehr wohl im Stadtverkehr und auf Landstraßen fahren (um mal einen Vergleich zu versuchen). Beim Mapping gibt es nun einmal unterschiedliche Schwierigkeitsgrade. Was einem zu hoch ist, soll man lassen und nicht stattdessen irgendwas anderes reinfriemeln. Das macht es allen anderen nur viel schwerer. Und nicht oder gar falsch zu taggen, nur weil es gefühlt noch keine Anwendung für die richtigen Tags gibt … dazu sage ich jetzt mal nichts.

Ich dachte anfangs auch, dass PTv2 ziemlich kompliziert sei, aber das stimmt nicht. Auch dabei gibt es ja verschiedene Stufen: Es geht erstmal nur um die korrekten Tags an den relevanten Knoten (Haltestellen, …). Wer sich an Relationen nicht herantraut, muss danach schon aufhören. Der nächste Schritt wäre dann die Zusammenfassung von Wegen in der richtigen Reihenfolge in einer Relation. Dann kommen die Haltestellen und Haltepunkte in der richtigen Reihenfolge mit den richtigen Rollen. Das ist total simpel und mit JOSM schnell gemacht. Wenn man das gemacht hat, ist schon das Meiste getan. Darüber hinaus kann man dann noch Haltestellenrelationen erzeugen und Hauptlinien und Sonderrouten und dergleichen. Auch alles recht simpel. Man muss es sich nur einmal zu Gemüte führen (eine Wiki hatte ich ja verlinkt) und Beispiele anschauen.

Ich bin in die tiefen Details von PTv2 noch nicht eingestiegen und kann daher noch nicht so richtig nachvollziehen, wo die vermeintlichen Probleme liegen. Auf den ersten Blick sehe ich nicht direkt, woran es krankt. Aber wenn es Lücken gibt, dann sollte PTv3 in Angriff genommen werden. Das heißt aber nicht unbedingt, dass man alles (inkl. Tag-Namen) über den Haufen werfen muss. Denn … ich wiederhole mich …:

Das Mappen ist eine reine Bestandsaufnahme. Ein stumpfes zuammenschreiben von mehr oder weniger physikalischen Fakten. Das Mappen ist aber keine (!) Interpretationsaufgabe. Daten werden nur erzeugt und nicht interpretiert! Die Interpretation ist z.B. Renderern vorbehalten.

Relationen, könnte man meinen, verstoßen ein Stück weit gegen diese Regel, denn sie gehen ja vermeintlich in Richtung Interpretation. Allerdings kann man das so oder so sehen … eine Zusammenfassung aller Elemente, die zu einer Haltestelle gehören, könnte man schon als Interpretation werten oder doch noch als einfachen Fakt. Manchen Leuten sträuben sich bei “Zusammenfassung” im Zusammenhang mit “Relationen” nun wieder die Haare, aber man sollte die Kirchen auch in den Dörfern lassen.

Wie gesagt, beim Mappen geht es ums Datensammeln und um die eindeutige Ablage dieser Daten in der Datenbank.

Sei dir da mal nicht so sicher :wink:

Weil ich gerade in Köln vorbeigeschaut habe :wink:

http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dbus_stop

Klassischer Fehler… highway=bus_stop ist das Schild an dem man Wartet! Wo heute zusätzlich public_transport=platform getaggt wird. Hab ich bei einer Relation ganz oft gesehen das es auf die Straße getaggt wurde, also an die Stop-Position… Müsste man in Köln mal drüberschauen… wird dadurch auch falsch gerendert… :roll_eyes:

Unter https://github.com/rurseekatze/osm-pt-validator habe ich mal angefangen, Validatorregeln für JOSM zu sammeln, mit denen man genau solche Fehler erkennen kann. Aktuell habe ich zum Beispiel schon einen Check darauf, ob eine stop_position auch Teil eines Ways ist.

Einen Check darauf, ob highway=bus_stop an einer stop_position getaggt ist, ließe sich auch relativ einfach formulieren und steht schon auf meiner Todoliste. Wenn ihr beim Mappen auch fehlerhaftes Tagging stoßt, dann würde ich mich über Pull Requests, Issues oder einfach eine Mail freuen.

Gruß
Alex

@rurseekatze

Aso… wäre auch :sunglasses: wenn eine Note die nicht Teil eins Weges ist… und mit highway=bus_stop getaggt ist und public_transport=* fehlt… man auf “Reparieren” drücken könnte und “public_transport=platform” wird hinzugefügt :slight_smile: :slight_smile: :slight_smile:

Dann noch a bischen Schwerer… dann kein “Way” in der nähe der Haltestelle Mitglied der Relation ist… z.B.

Ich hatte es eigentlich so verstanden, dass highway=* in PTv2 überhaupt nicht mehr vorgesehen ist. Beim eigenen Mappen hatte ich das in der Regel einfach drin gelassen, wobei es dabe ieigentlich immer auf dem Fahrweg war und nicht auf dem Fußweg. Um der Homogenität willen hatte ich das bei den Relationen, die ich bearbeitett hatte, entsprechend ergänzt. Aber normalerweise sollte nur noch public_transport=* verwendet werden, oder? Die Renderer haben das zwar noch nicht gerallt, aber dazu hatte ich mich ja schon oben ausgelassen :wink:

highway=bus_stop ist zum eine aus Gründen der Kompatibilität noch drin und damit klar ist das diese platform für z.B. unter anderem Bus ist. Lässt man highway=bus_stop weg müsste man auf jedenfall noch bus=yes taggen… Müsste denk ich dann soweit auch gehen…

@rurseekatze

public_transport=platform ohne Angabe des Verkehrmittel das da hält… wäre auch ein Fehler :slight_smile:

Stimmt. Das Verkehrsmittel ist so nicht abgedeckt. Auch muss ich feststellen, dass das highway=bus_stop in der PTv2 doch genutzt wird, zumindest in der Wiki hier. Gleich wird es mit Bahnen undso gehandhabt. Allerdings muss ich aus heutiger Sicht sagen, dass ich das recht unsinnig finde, insbesondere railway=tram_stop. Denn das impliziert, dass das Schild auf den Schienen steht. Eine Schild-Node kann man ja machen, aber nicht mit highway oder railway, sondern dann meinetwegen auch mit public_transport=stationsign oderso.

OK. Das Fußgängerrouting ended hier (bei gedachtem korrekten Mapping) an der richtigen Stelle. Aber nur, weil der Router bei der unmöglichen Aufgabe die Platform zu erreichen ersatzweise was möglichst nah gelegenes sucht. Er könnte auch einfach sagen “Es gibt keinen Weg”. Ich finde es in jedem Fall sinnvoller, die Ziele der Fußwege in die Routen zu stecken. Die platform wird ja trotzdem als physisch vorhandenes Objekt gemappt werden. (Übrigens sind das hier lustigerweise platforms, an denen garantiert nie gewartet wird)

Das gilt für sämtliche alte Linien, da ja alle umgestellt werden sollen.

Im Gegenteil: nur für diesen Fall ist das ignore-Flag gemacht. Ansonsten bekommen wir bei der Unterstützung beider Sachen doppelte Objekte.

Das PT-Mapping wird in der Übergangszeit komplizierter und danach m.E. einfacher. Andere Mapping-Aktivitäten werden nicht komplizierter und danach wesentlich einfacher.

Im Gegenteil. Wenn wir die Umstellung ohne Übergangszeit machen, dann wird kein Programm die neuen Sachen berücksichtigen solange nur wenig umgestellt ist. Das wiederum wird die beteiligten Mapper frustrieren und den Übergang langsamer machen. Mit einem geordneten Übergang kann man dagegen sofort den neuen Code einfügen und testen ohne die Qualität der Ergebnisse runterzuziehen.

Sooo schlecht ist der jetzige Zustand auch wieder nicht. Wenn plötzlich alle Haltestellen weg sind, dann wird das schon auffallen.

Ich hab langsam das Gefühl, Du meinst mit stop_area nicht eine stop_area-Relation…

Zum Masten-Tag: es gab auch früher keins.

Nein. highway=bus_stop bedeutet einfach “Hier ist eine Bushaltestelle”. Wenn es neben der Fahrbahn ist, dann ist es eine platform im Sinne von PTv2 und wenn es auf dem Fahrweg ist, dann ist es ein stop im Sinne von PTv2.

Es ist aber völlig korrekt…

Nein. Sämtliche alte Haltestellen sind in PTv2 völlig korrekt. Die alten Tags sollen ganz ausdrücklich durch PTv2 nicht geändert oder abgelöst werden. Abgelöst werden sollten nur die Routen.

Nein. Es ist nicht einmal vorgesehen, dass das eingetragen wird! Im PTv2 sind Einträge wie bus=yes ganz ausdrücklich für stop_positions vorgesehen und das wars.

Also bevor es dieses PTv2 gab… hat man das Schild bzw. das Häuschen oder wie auch immer die Haltestelle ausfällt gemappt… das was da neber der Straße steht… da wo man halt hingeht wenn man da mitfahren will, wenn es auf der Straße wäre, wäre es schnell kaputt :laughing: Das ist highway=bus_stop. Ich habe auch noch nie auf den Bus gewartet um zu sehen wo er genau stehen bleibt… diese Note ist meist geraten…

Jetzt wo es PTv2 gibt… sind hier viele der Meinung das wäre jetzt nicht mehr so :roll_eyes:

Mfg Miche

Da hilft es nur, nochmal das damalige Proposal zu konsultieren und zu prüfen, was gemeint ist. Aber angeblich werden die Proposals ja auch hin und wieder nach dem Approval noch geändert …

Das Original findet man unter
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

Zu den Linienarten hat nach der Abstimmung jemand light_rail hinzugefügt und dadurch indirekt die Bedeutung von train eingeschränkt. Jetzt steht da, wir hätten das damals beschlossen und Korrekturversuche verschiedener Leute wurden revertet.

Na okay, dann hält sich das ja in Grenzen. Lässt sich also mit arbeiten. Danke für den Link nochmal.

Es gibt noch wenige sinnvolle Anwendungen für ptv1 - Routen:

  • Bürgerbuslinien, die zwar feste Haltestellen, aber keine festen Fahrwege haben, da Haltestellen als Rufbus angefahren werden.
  • Bahnlinien bei denen die angefahrenen Bahnsteige nicht bekannt sind.

Dokumentationen existieren, werden aber nicht gelesen. Auf der VRR-Seite ist ein ptv2 Taggingschema datailliert beschrieben.
Meinst du mit Dokumentation solche Darstellungen http://www.roeltgen.com/e150900/ ? Und wo sollten sie stehen ?

Gruß Axel

Hallo Axel,

mein Problem ist, es gibt zu viele, sich zu Teil widersprechende Dokumentationen.

Ich finde es gut, daß du dir die Mühe gemacht hast, verschiedene tagging-Schemata zu vergleichen, mir sind die Erklärungen dazu aber zu knapp, um daraus für mich Schlüsse zu ziehen, welches man anwenden sollte.
Insbesondere die Bildchen auf deiner Wiki-Seite User:Axelr/Bushalte fand ich interessant, konnte sie allerdings nicht entschlüsseln.
Auch deine mir bisher unbekannte Seite http://www.roeltgen.com/e150900/ ist als Grundlage für einen Vortrag sicherlich sehr gut, als schriftliche Dokumentation unzureichend, angefangen mit erst bei Zoom-Faktor 250 lesbaren Schriften in den Zeichnungen bis zur Benennung der Schemata (island: weil auf den britischen Inseln verwendet? tunnel:?).

Die Idee finde ich gut, würde lieber erst einmal auf deutsch arbeiten, um Schwierigkeiten und Mißverständnisse sprachlicher Art auszuschließen.

Viele Grüße
Peter

Die Erklärung finde ich ganz gut… um die Unterschiede darzustellen zwischen 1 und 2:
https://wiki.openstreetmap.org/wiki/User:Weide

Welche Punkte mich stören sind zum einen… für jede Variante eine Relation, und diese stop_position… Es mag in komplexeren Haltestellen notwendig sein… aber ein einfachen Verhältnissen braucht man diese glaub ich nicht… vor allem da diese eher geraten ist als wirklich aufgenommen…

Zum Beispiel diese Linie des MVV Nr. 614 müsste man 5 Varianten für die Hinfahrt anlegen und 5 Varianten für die Rückfahrt auch 5 anlegen und eine Master-Relation… das macht 11 Relationen das finde ich ein wenig übertrieben… da dieser Bus nicht oft fährt… wahrscheinlich hauptsächlich nur um Schuler aus den Dörfern aufzulesen… wo gerade vorhanden sind.
http://efa.mvv-muenchen.de/ttb/mvv_19614___H_s17_1.pdf

Ja. PTv2 verlangt auch nicht, dass beides gemappt wird. Es verlangt nur, dass beide in die Routen kommen sofern beide vorhanden sind. Das hat den Sinn, dass man zu jedem Haltestellenobjekt einfach die Relationen nachschlagen kann und so die Liste der da haltenden Linienvarianten bekommt. Die meisten Pärchen aus stop und platform existieren nur deshalb, weil jemand irrtümlich angenommen hat, dass man das jetzt eben so machen muss. Ich lösche sowas normalerweise nicht, weil es ja zulässig ist … aber 90% der Pärchen sind einfach Quatsch und man kann sie nur deshalb nicht vereinfachen, weil sie ja keine Fehler im engeren Sinne sind.

Blätter eine Seite zurück, da stehen die Erklärungen. Zweimal ‘Strg’+‘+’ fürs Studium des Kleingedruckten, die Registriernummer brauchst du nicht.

Farben in Bildern:
magenta Routen-Relation (Elemente in der route-relation)
grau Elemente nicht in der route-relation
blau highway-tag
dunkelblau railway-tag

Benennung:
dualnode für Zwei-Knoten-Punkt-Lösung
island für Insellösung, weil für London-Busses dokumentiert und weil nicht kompatibel,
tunnel für Tunnelblick.

Gruß Axel

Wie soll denn sonst die unterschiedliche weglaufe deutlich gemacht werden? Ich hab es früher mal versucht mit eine “Alternative” role, aber das geht auch nicht mehr wenn es mehrere alternativen gibt.

Verstehe mich richtig: machmal stinkt’s mir auch für eine einzige Bus eine neue Relation anlegen zu mussen. Und in Deutschland gibt es solche fälle viel öfter als in die Niederlanden.

@ axelx: ich habe schon zurückgeblättert, aber die Farbenerklärung fehlte mir zum Verständnis. Ebenso kenne ich die Tastenkombination für Zoom in/out im Browser, aber damit eine Dokumentation beachtet wird, sollte es der Leser m.E. möglichst bequem haben. Deswegen würde ich auch die Beispiele lieber als Bild (mit zusätzlichen Link) haben, außerdem könnte sich im Laufe der Zeit die Karte ändern und dann wäre das Beispiel nicht mehr nachvollziehbar.

@ miche101 / Marten Deen: Bei solchen Linien stehen für mich Aufwand und Nutzen des Anlegens von Relationen in keinem vernünftigen Verhältnis, insbesondere da mit Änderungen bei jedem Fahrplanwechsel zu rechnen ist.
Ich wäre hier zufrieden, wenn alle Haltestellen getaggt wären und man einen Link zur Webseite des Verkehrsunternehmens hätte.

Daraus ergibt sich aber auch die Frage, ob es nicht gut wäre, alle an einer Haltestelle haltenden Linien (wie am Haltestellenmast angeschrieben) in einem entsprechenden Tag aufzuzählen.

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.