Talk:VRS/Analyse

From OpenStreetMap Wiki
Jump to: navigation, search

Overpass-API Abfrage

Die Overpass-API Abfrage liefert alle Routen für ÖPNV sowie deren Route-Master für den angegebenen Ort (die angegebene Region). Route-Master ohne Routen (leere Route-Master) werden hiermit nicht gefunden. Zusätzlich liefert die Abfrage noch alle Ways und Nodes der Routen (d.h. Member der Relationen mit ihren Details, sowie die Ids aller Nodes der Ways).
Diese Abfrage erlaubt eine Analyse der ÖPNV-Linien dahingehend, dass auch die Wegstrecke auf Vollständigkeit geprüft werden kann. Nodes, Ways und Relationen (Stops und Platforms) und deren Tags können nun auch gegen deren Rolle 'role' in der Relation geprüft werden. Die Abfrage liefert derzeit etwa 49,8 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' oder 'NRW Regionalverkehr' (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").

Andere ÖPNV Linien

Übrig bleiben die Linien, die

  • zwar den 'network'-Tag Kriterien entsprechen aber
  • 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).

ÖPNV Linien ohne 'ref'

Hierzu zählen alle Linien, die

  • keinen ref-Tag haben
    • egal, ob sie den network-Tag Kriterien entsprechen oder nicht

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.

Nicht berücksichtigte 'network'-Werte

Dieser Abschnitt listet die nicht berücksichtigten 'network'-Werte auf. Das sind diejenigen, die nicht den oben genannten 'network'-Tag-Kriterien entsprechen.
Mögliche Ursachen:

  • Tippfehler im wert von 'network'
  • tatsächlich nicht zu berücksichtigenden Werte

Prüfungen

Zusammengefasst auf meiner Wiki-Page

Auswertungsoptionen

Die Ausgabe von Fehlern und Anmerkungen kann durch eine Vielzahl von Auswertungsoptionen beeinflusst werden.
Hier ist eine Auflistung der Texte der Fehlermeldungen und Anmerkungen.

Option Wert Anmerkung
check-access ON Es werden Wege benutzt, die explizit oder implizit nicht befahren werden dürfen und wo bus="yes", bus="designated", bus="official", psv="yes", ... fehlt.
check-bus-stop OFF highway="bus_stop" darf nur auf Punkten (Nodes) gesetzt werden, nicht auf Wege oder Flächen.
check-name ON Prüfung von name="...ref: from => to" bzw. name="...ref: from => via => ... => to".
check-platform OFF Fehlendes bus="yes", tram="yes" oder share_taxi="yes" bei public_transport="platform".
check-roundabouts OFF Prüfung, ob Kreisverkehre nur teilweise durchfahren werden, aber komplett in der Relation enthalten sind (JOSM prüft das nicht).
check-sequence ON Prüfung, ob die Wege in der Route-Relation lückenlos sind.
check-stop-position ON Fehlendes bus="yes", tram="yes" oder share_taxi="yes" bei public_transport="stop_position".
check-version OFF Prüfung von public_transport:version="..." bei Route-Master und Route.
coloured-sketchline ON Die SketchLine berücksichtigt den Wert von colour="..." des Route-Master, der Route.
expect-network-long ON Der Wert von network="..." wird in der langen Form erwartet (siehe network-long-regex).
expect-network-long-for Der Wert von network="..." wird in der langen Form erwartet, statt der hier angegebenen kurzen Form.
expect-network-short OFF Der Wert von network="..." wird in der kurzen Form erwartet (siehe network-short-regex).
expect-network-short-for Verkehrsverbund Rhein-Sieg Der Wert von network="..." wird in der kurzen Form erwartet, statt der hier angegebenen langen Form.
max-error 10 Limitiert die Anzahl der Ausgabe von Nodes, Ways, Relations bei identischen Fehlermeldungen pro Route.
network-long-regex Verkehrsverbund Rhein-Sieg|NRW Regionalverkehr Der Wert von network="..." der im Datensatz enthaltenen Route-Master und Routen muss diesem Muster als Langform entsprechen oder darf leer sein.
network-short-regex VRS Der Wert von network="..." der im Datensatz enthaltenen Route-Master und Routen muss diesem Muster als Kurzform entsprechen oder darf leer sein.
operator-regex Der Wert von operator="..." der im Datensatz enthaltenen Route-Master und Routen muss diesem Muster entsprechen oder darf leer sein.
positive-notes OFF Ausgabe von network:short="...", network:guid="..." und anderen Werten.
relaxed-begin-end-for train,light_rail,tram Entspanntere Prüfung von Anfang und Ende einer Route bzgl. Stop-Position (zB. bei train, tram, light_rail).
strict-network OFF Keine Berücksichtigung von Route-Master oder Route bei leerem network="...".
strict-operator OFF Keine Berücksichtigung von Route-Master oder Route bei leerem operator="...".

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. <strike>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
      • update 2017-10-23: Prüfung wieder entfernt, hat zu Irritationen und kontroversen Diskussionen geführt.
  • 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)

Fehler in der Linienliste

Hi,

  • der RE6a ist vor einiger Zeit in den RE6 aufgegangen. In der Liste ist er noch vorhanden.
  • Die RB21 befährt an keiner Stelle die VRS-Gemeinden. Die Gemeinde Düren gehört zwar zum "erweiterten VRS-Netz, ist aber primär Teil des AVV und daher richtigerweise nicht in der Analyse mit inbegriffen. Daher sollte die RB21 auch aus der Liste gelöscht werden. Selbiges gilt für die RB96 und RB97
  • Die RB47 ist vor einiger Zeit in die S7 aufgegangen. Dazu fährt auch diese nicht im Kernnetz.
  • Die RB95 fährt nirgendwo auch nur Ansatzweise in VRS-Nähe
  • Die RB83 ist mir nicht bekannt.

Ich habe das ganze jetzt korrigiert, wenn mir weitere Fehler auffallen werde ich das hier ergänzen. --Hsimpson (talk) 14:33, 22 November 2017 (UTC)

  • Die Bonner Stadtbahnlinien wurden jetzt auch zur tram geändert: https://www.openstreetmap.org/changeset/53300072 Damit kann ich persönlich erstmal leben, mein Ziel ist aber immer noch, das System auf light_rail umzustellen. Aber erstmal psse ich die liste entsprechend an. --Hsimpson (talk) 15:10, 22 November 2017 (UTC)

Anrufsammeltaxen u.ä.

Hallo, ich will auf die Fragen mal heir antworten, da das ganze etwas ausführlicher wird:

  • Generell sind diese Taxen in den Verbundtarif integriert und fahren nach Fahrplan. Daher ist das ganze für mich eher ein route=bus. Shared-Taxen (so, wie ich sie kennen gelernt habe) stehen dagegen so lange rum, bis sie voll sind, und fahren dann los. Auch sind diese normalerweise nicht Teil des ÖPNV-Verbunds.
  • Es gibt im VRS-Raum im Wesentlichen zwei verschiedene Arten von Taxibussen nach Fahrplan: Solche, die eine klassische Linie bedienen und solche, die einen ganzen Bereich mit einer oder mehreren Haltestellen verbinden. Letztere fahren sammeln dich nach Bestellung zu bestimmten Zeiten z.B. an der U-Bahn Haltestelle ein und fahren dich bis vor die Haustüre (oder umgekehrt). Sie kommen vor allem in Köln vor und ich habe hier noch keine Möglichkeit gefunden, diese irgendwie zu erfassen. Mehr dazu gibt es hier: http://www.kvb-koeln.de/german/fahrplan/rufbuslinien.html

--Hsimpson (talk) 16:07, 22 November 2017 (UTC)

ref mit Semikolon

Hi, ich hab grade beim RE22/RB22 und der RB23/S23 die refs überarbeitet, sodass dort nun korrekterweise ein Semikolon die beiden refs trennt => ref=RE12;RE22 Problem dabei: In der Liste ist die Funktion von Semikolons schon anderwertig gesetzt. Ich hätte eine Lösung dafür:

  • Die Einträge zur RE22 und RB22, bzw RB23 und S23 werden getrennt, was dazu führen würde, dass die Einträge teilweise auf die selben Relationen verweisen (kann persönlich ich mit leben). Vorraussetzung: Dein Programm kann Semikolons korrekt auswerten (ich glaube an anderer Stelle funktioniert das schon) und erkennt auch ein ref=RE22;RB22 zugehörig zur Linie RE22. Was sagst du dazu? Könnte das funktionieren? Grüße, --Hsimpson (talk) 23:37, 22 November 2017 (UTC)

Edit: Hab ich mich doch tatsächlich in den Liniennummern vertan :) Hab jetzt die Einträge mal getrennt, mal sehen, was passiert. Grüße, --Hsimpson (talk) 00:12, 27 November 2017 (UTC)

  • "ref mit Semikolon": Wäre machbar, der Aufwand ist aber recht hoch und erfordert eine Änderung der Datenstruktur. Auch müsste die VRS-Linen-Datei geändert werden. Das Thema würde ich für den Re-Design des Tools aufheben.

--ToniE (talk) 16:19, 19 December 2017 (UTC)

Mögliche Prüfungen

Ich bin grade auf diverse Absonderheiten gestoßen, wie etwa ein bus=yes an mehreren route=train... Oder als Rolle für die stops a:01, a:02, a:03,... usw. fein säuberlich durchsortiert. Ich denke, dieses Programm sollte langfristig eine Positiv-Liste an möglichen Schlüsseln und Werten erhalten und alles andere anmerken. Mommentan dürfte das noch den Upload vom Wiki sprengen, aber Gedanken könnten wir uns dazu schon machen. Nebenbei: Laut deiner Checkliste soll das Programm auch den Schlüssel note:* als Anmerkung auswerfen. Ich bin eben auf ein note:osm=[...] gestoßen, das auf die Proposal-Seite für PTv2 verwiesen hat. Wurde offensichtlich 2012 an alle RE und RB Linien in der Gegend geklatscht. Habs dann da wo ich gearbeitet habe gelöscht, aber dein Programm hat das nicht ausgeworfen. Fehler oder nur deaktiviert wegen der Uploadgrenze? Grüße, --Hsimpson (talk) 00:33, 23 November 2017 (UTC)

Vorschlag: Der Wert für network enthält nicht VRS, bzw. bei Zügen NRW Regionalverkehr - als Fehler --Hsimpson (talk) 00:14, 27 November 2017 (UTC)

  • "bus=yes" an "route=train" (Relationen?) wird nicht geprüft - könnte ich noch einbauen
  • "stop:a:01" und so weiter ist in PTv2 nicht erlaubt. Im Forum war die Rede von " ... nach PTv1 zusätzlich definiert ..." oder so. Das sind 5 Jahre alte Artefakte bei 5xx-Linien von "netzwolf", oder?
  • "Positiv-Liste"? die ist doch für die meisten tags durch PTv2 schon gegeben.
  • "note:osm=..." geht bei mir, eigentlich alles was mit "note" anfängt wird ausgegeben
  • derzeit habe ich beim VRS "--expect-network-short" gesetzt, so dass "Verkehrsverbund Rhein-Sieg" angemeckert würde, leider aber auch "NRW Regionalverkehr"
    • das kann ich ändern in "--expect-network-short-for=VRS" und "--ecpect-network-long-for=NRW Regionalverkehr" unabhängig davon welches Verkehrsmittel das betrifft (s.u.)

--ToniE (talk) 16:19, 19 December 2017 (UTC)

Möglichkeiten zur Upload-Verkleinerung

Hi, folgende Anmerungen halte ich für überflüssig und würde vorschlagen, sie aus der Liste rauszunehmen, um Kapazitäten für andere Prüfungen zu schaffen:

  • network is short form: Ist der Standard im VRS und taucht daher an fast jedem Element auf. Die Liste soll aber Abweichungen von der Norm aufzeigen, also weg damit.
  • network is long form: Kann bei route=train ebenfalls ignoriert werden, wenn der Wert NRW Regionalverkehr ist.
  • PTv2 route: includes 1 entire roundabout(s) but uses only segment(s): Da das nach PTv2 zulässig und sogar erwünscht ist, muss diese Anmekung hier ebefalls nicht auftauchen
  • PTv2 route: first/last node of way is not a stop position of this route: Würde ich bei route=train und route=tram/light_rail ebenfalls ignorieren, wenn die erste/letzte stop_position Teil des ersten/letzten Ways ist. Z.B. würde bei dieser Endhaltestelle: http://www.openstreetmap.org/node/2105944600 niemand diesen letzten Way: http://www.openstreetmap.org/way/200626251 aufsplitten.

Nebenbei würde das die Analyse auch deutlich übersichtlicher machen ;)

Grüße, --Hsimpson (talk) 15:59, 23 November 2017 (UTC)

  • network als short oder long: siehe oben
  • das habe ich bei den "Geplanten Prüfungen" beschrieben "--relaxed-begin-end-for=train;light_rail;tram"

--ToniE (talk) 16:19, 19 December 2017 (UTC)