Talk:VRS/Analyse

From OpenStreetMap Wiki
Jump to: navigation, search

Overpass-API Abfrage

Diese Overpass-API Abfrage liefert alle Ways und Nodes der Routen (deren Member mit ihren Details).
Diese Abfrage erlaubt eine erweiterte Analyse der ÖPNV-Linien dahingehend, dass nun z.B. auch die Wegstrecke auf Vollständigkeit geprüft werden kann. Nodes, Ways und Relationen (Stops und Platforms) und deren Tags können gegen deren Rolle 'role' in der Relation gprüft werden. Die Abfrage liefert derzeit etwa 47,5 MB.

http://overpass-api.de/api/interpreter?data=area[boundary=public_transport][name='Verkehrsverbund Rhein-Sieg']->.L; rel(area.L)[route~'(bus|tram|train|subway|light_rail|trolleybus|ferry|monorail|aerialway|share_taxi)']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;

Filter nach network

Aus den Daten der Overpass-API Abfrage werden alle Routen und Route-Master herausgefiltert, die gewissen Kriterien entsprechen:

  • der network-Tag ist nicht vorhanden
  • der network-Tag enhält 'VRS' (short)
  • der network-Tag enthält 'Verkehrsverbund Rhein-Sieg' (long).

VRS Linien

Im nächsten Schritt werden die verbleibenden Linien mit einer Liste verglichen. Die Auswertung enthält derzeit zum Einen eine Bestandsaufnahme der in OSM gefundenen VRS-Linien.
Zum Anderen wurden hier manuell Daten aus der VRS-Wiki Seite eingepflegt.

Ziel ist aber die Erstellung dieser Datei aus VRS-Daten mit allen zum VRS gehörigen Linien.
Die Liste kommt idealerweise direkt vom und mit Hilfe des VRS (copyright!).

Diese Liste soll die Linien des VRS enthalten. Die Einträge in der CSV-Datei enthalten u.A. Informationen über die Liniennummer ('ref') und den Type des Verkehrsmittels ('route'='bus', ...). Die in OSM gefundenen Linien müssen dabei sowohl

  • mit ref als auch mit route_master bzw. route in der Liste vorkommen

Beispiel: '210;bus': Linie 210 muss als Bus-Linie erscheinen (d.h. 'ref' = 210 und ('route_master' = 'bus' oder 'route' = 'bus)).
Als Tram oder U-Bahn wird sie nicht berücksichtigt und erscheint auf der nächsten Liste ("Other Public Transport Lines").

Other Public Transport Lines

Übrig bleiben die Linien, die

  • den 'network'-Tag Kriterien entsprechen und
  • eben nicht in der Liste (s.o.) vorkommen.

Taucht in dieser Liste ("Other Public Transport Lines") z.B. eine VRS Linie 724 auf, so ist das ein Indiz, dass es diese Linie nicht mehr gibt - sie wurde u.U. eingestellt (denn sonst würde sie bei der Liste "VRS Linien" auftauchen).

Public Transport Lines without 'ref'

Hierzu zählen alle Linien, die

  • keinen ref tag haben

Verdächtige Relationen

Dieser Abschnitt enthält alle Relationen, die verdächtig sind:

  • evtl. falsche 'route' oder 'route_master' Werte?
    • z.B. 'route' = "suspended_bus" statt 'route' = "bus"
  • aber auch 'type' = 'network' oder 'route' = "network", d.h. eine Sammlung aller zum 'network' gehörenden Route und Route-Master.

Die Darstellung erfolgt in diesem Abschnitt lediglich mit der Relation-ID und markanten Tags.

Prüfungen

Zusammengefasst auf meiner Wiki-Page

Diskussionen

Hinweis: die Diskussionen hier stammen aus meiner privaten Wiki-Seite User_talk:ToniE/Transportation/Test. Sie wurden hierher verschoben, da es VRS-spezifische Inhalte sind.
Meine Antworten tragen daher nicht das übliche --~~~~, beginnen aber immer mit einem Bullet. Aber nicht alle mit einem Bullet beginnenden Zeilen stammen von mir. --ToniE (talk) 20:39, 23 September 2017 (UTC)

Eigennamen

Die Eigennamen VRS und VRR und sicherlich auch weitere sollten nicht als Fehler markiert werden. Dies wurde schon mehrfach im diskutiert. --Axelr (talk) 09:21, 21 September 2017 (UTC)

  • Sind auch nicht als "Fehler", sondern als "Anmerkung" gekennzeichnet.
    • Hintergrund: in München haben wir einen Misch-Masch von langer und kurzer Form und wollen das auf die lange Form vereinheitlichen. Daher der Hinweis, welche Form verwendet wurde.
    • Bei der Übersicht mittels CSV-Datei sind die Spalten 'network', 'ref', 'from', 'via' und 'to' nicht enthalten, so dass man den Wert von z.B. 'network' nicht sehen kann.
    • Des weiteren ist die Kurzform nicht eindeutig (MVV: München, Mannheim, AVV: Aachen, Augsburg, ...), so dass wir zusätzlich "network:guid"="DE-BY-MVV" mappen.

Es sieht so aus als ob du selbst das Problem in Augsburg geschaffen hast. Bisher waren die Äußerungen aus Aachen sinngemäß: Wir haben kein Problem, in Augsburg wird das nicht verwendet und wir haben keinen Ansprechpartner zum Abstimmen.--Axelr (talk) 14:00, 21 September 2017 (UTC)

  • In Augsburg bin ich nicht aktiv. Anders als User:hsimpson, der mich kontaktierte, habe ich damals Barfly_MB angesprochen und von meinem Tool berichtet. Dass dort (auch) 'AVV' verwendet wird ist aber naheliegend. Auf das Tagging-Schema vor Ort nehme ich (und das Tool) diesbezüglich keinen Einfluss. Das Tool dokumentiert in diesem Fall den Ist-Stand. In München haben wir uns halt entschlossen, die lange Form für 'network' zu wählen - auch der Eindeutigkeit wegen.

Dann mapt da jemand unter deinem Namen http://www.openstreetmap.org/changeset/46651524 und www.openstreetmap.org/changeset/46651323, aber ist ja auch egal, Aachen und Augsburg sollten sich da halt einigen.--Axelr (talk) 15:13, 21 September 2017 (UTC)

  • Erwischt! Da hatte ich network=AVV (analog zu den anderen dort befindlichen Linien) gemapped, damit die Buslinien bei der Analyse vom MVV nicht mehr rein rutschen (wegen leerem network tag).

route_master

route master hat keine public_transport:version. Das Fragezeichen in der Spalte PTv wäre besser durch eine Leerstelle zu ersetzen. --Axelr (talk) 09:21, 21 September 2017 (UTC)

Laut Diskussion auf der FeaturePage sollte es bereits seit 2014 entfallen sein.--Axelr (talk) 14:29, 21 September 2017 (UTC)

  • Na ja, wenn die Feature Page das Ergebnis der Diskussionsseite nicht widerspiegelt ... denn in der Feature Page stehts für route_master noch drin. Der Inhalt der Diskussionsseite ist zweitrangig.

busway=opposite_lane

Busspur in Gegenrichtung ist in http://www.openstreetmap.org/way/5875201 nach meiner Meinung richtig angelegt, wird aber als Fehler gemeldet. --Axelr (talk) 10:22, 21 September 2017 (UTC)

  • oneway=yes, busway=opposite_lane muss das Tool dann wohl noch lernen, danke für den Hinweis.
  • oneway=yes, busway:left=lane fällt auch darunter (zumindest in Ländern mit Rechtsverkehr).
  • oneway=-1, busway:right=lane fällt auch darunter (zumindest in Ländern mit Rechtsverkehr).

Hi, ich halte deutlich mehr davon, die Buswege nach dem gängigen :lanes - Schema zu erfasen. Auch sollte immer ein oneway:bus=no dranstehen, wenn der Bus gegen die Einbahnstraße fahren darf (Analog geht natürlich auch psv). Von daher sehe ich hier keinen gravierenden Fehler! --Hsimpson (talk) 15:34, 23 September 2017 (UTC)

  • die letzten beiden habe ich auch (noch) nicht implementiert, das spare ich mir dann erst mal.

bus_stop

Ein bus_stop neben der Fahrbahn ist laut public_transport-proposal eine vollwertige platform. Deshalb ist "PTv2 route: 'role' = 'platform' but 'public_transport' is not set" KEIN Fehler. Gleiches gilt für bus_stop in der Fahrbahn ist laut public_transport-proposal eine vollwertige stop_position. --Axelr (talk) 10:58, 21 September 2017 (UTC)

Das proposal sollten wir nur in der beschlossenen Version verwenden. User:Weide hat mehrfach darauf hingewiesen: http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

Unabhängig davon steht in beiden Versionen: "This proposal does not replace, deprecate or obsolete the already existing and well known tags. The usage of the proposed tags is recommended but not mandatory"

Die wiki-Seite DE:public_transport ist an mehreren Stellen inhaltlich falsch. highway=platform gehört in die Mottenkiste. Dies basiert auf einem nicht angenommenem Vorschlag von 2009, der durch public_transport 2011 abgelöst wurde. Außerdem gibt es im Gegensatz zu railway=platform keine bauliche platform für Busse. Diese ist immer Teil des Gehweges oder der Verkehrsinsel. Im Weiteren wird über public_transport=platform falsch argumentiert. Es werden Argumente pro und kontra bauliche Platform auf public_transport=platform übertragen. Die public_transport=platform ist nur der Bereich wo Passagiere auf das Vehicle warten, sonst Nichts. --Axelr (talk) 13:27, 21 September 2017 (UTC)

  • OK, ich werde nur noch auf die Version 625726 verweisen.
  • PTv1 und PTv2 mit ihren Tags können koexstieren, ja. Bei einer Route muss ich mich aber für eine der beiden entscheiden. Fehlermeldungen beginnen mit "PTv2 route: ..." und für diese Routen (mit public_transport:version=2) und deren Member gelten die "approved features", d.h. public_transport=stop_position/platform mit evtl. bus=yes, tram=yes, train=yes sind 'mandatory'. PTv1-Routen werden nicht weiter analysiert.
  • highway=platform und highway=bus_stop interessieren im Tool nicht.
    • update: 2017-10-13: highway=bus_stop auf ways (mit oder ohne area=yes) ist lt. FeaturePage von highway=bus_stop nicht erlaubt und wird als Fehler ausgegeben. Beachte: highway=bus_stop ist nicht PTv2, sondern die alte Art und Weise ÖPNV zu mappen. Das "Ptv2" in der Fehlermeldung "PTv2 route: 'highway' = 'bus_stop' is set on way(s). Allowed on nodes only!: %s" bezieht sich derzeit nur darauf, dass ausschließlich PTv2-konforme Linien entsprechend untersucht werden - das wird im Tool noch erweitert ... done
  • Es gibt hier in Ottobrunn Platfoms für Busse, die explizit dafür gebaut wurden, neben dem Fuß-/Radweg liegen, von diesem durch Gras getrennt und durch zwei separate Zugänge erreichbar sind. Das könnte man sogar als area=yes mit public_transport=platform mappen - sie sind nicht Teil des Fuß-/Radweges. Platform Hubertusstraße

Das Ignorieren eines nodes mit highway=bus_stop ist nicht der richtige Weg, da dieser für sich bereits eine komplette Haltestelle (auch in ptv2) markiert. Wenn stop_position und bus_stop neben der Fahrbahn eingebunden werden, hat man zwei Haltestellen.

Dein Beispiel Hubertusweg macht das Dilemma mit highway=platform deutlich. Das ist spurmapping auf Fußwegen --Axelr (talk) 15:36, 21 September 2017 (UTC)

  • Hmm, ich kann Dir nicht recht folgen.
    • Das Eine ist das Tagging gemäß PTv2. Um PTv2-konform zu sein muss public_transport=stop_position (am Node) und public_transport=platform am Node/Way/Area dran sein. highway=bus_stop darf dran sein, muss aber nicht. Und an welchem Node es ist hängt von der Historie ab, oder?
    • Das Andere ist der Kartenstil Mapnik (oder heißt der Renderer so?): highway=bus_stop definiert (leider) immer noch, wo das kleine Icon gemalt wird.
    • Ein weiteres ist Sketchline (MVV Bus 241), der scheinbar auch nur auf highway=bus_stop abfährt (und route_master ignoriert). Sketchline bringt unschönde Dinge hervor, wenn man highway=bus_stop bei PTv2-Routen neben die Fahrbahn setzt (MVV Bus 210).
  • Beim Hubertusweg
    • könnte man highway=platform weglassen, dann würde Mapnik u.U. nichts mehr malen - mal wieder Mappen für den Renderer?
    • ist es tatsächlich ein "baulich getrenntes Objekt", welches ein separates Mapping rechtfertigt.

Beim Bus 241 liegen zwei verschiedene Ungereimtheiten vor. Im ersten drittel und letzten drittel sind die platform-nodes Ursache der langen Lücke. (Laut proposal ist platform-way das Gebot, der node die Ausnahme) Im mittleren Drittel sind doppelte Haltestellen vorhanden (wie oben beschrieben). Bei der Ausnahme platform-nodes ist es besser nur einen Punkt einzubinden. Obgleich das Ergebnis ausser den mittleren Haltestellen gut aussieht http://www.roeltgen.com/gpx/ibro_ol4pt.html?idt=366620 --Axelr (talk) 17:10, 21 September 2017 (UTC)

  • Alle Buslinien in München und Umgebung sind uneinheitlich, sogar innerhalb einer Linie :(


Hi, ich möchte mal kurz die Ergebnisse der letzten Diskussionen wiedergeben, so wie ich sie empfunden habe (und dementsprechend auch so Mappe):

  • highway=plattform gibt es nur als Way und auch nur noch dann, wenn die Platform klar nicht teil eines Bürgersteigs ist, z.B. innerhalb eines Busbahnhofs.
  • Alle anderen Bushaltestellen werden mit zwei Nodes erfasst: je eine stop_position und eine platform nach PTv2.
  • highway=bus_stop kommt in der Regel an die Platform-Node. Ist dies ein Way, kommt es an die stop_position Node.
  • In keinem Fall gibt es mehr als eine platform und eine stop_position, egal ob Node oder way.

Grüße --Hsimpson (talk) 15:45, 23 September 2017 (UTC)