Talk:VRS/Analyse

From OpenStreetMap Wiki
Jump to navigation Jump to search

Diskussionen

Hinweis: die Diskussionen hier stammen von einer meiner privaten (in der Zwischenzeit gelöschten) Wiki-Seiten. 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)

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).

Das ist unter Umständen nicht richtig. In der VRS Liste fehlen Linien z.B. die Linie 747 (Rheinbach-Odendorf), die es aktuell (2018) aber durchaus mit Fahrplan gibt. Wenn nun jemand diese Linie erfasst, taucht sie in der Liste "Other Public Transport Lines" auf, da sie ggfs. noch nicht in der VRS-Liste eingetragen ist. Der Ersteller der Routen-Relation weiss möglicherweise nichts von dieser Liste. Ich selbst habe diese Linie durch Zufall über die VRS-Infos zur Haltestelle Rheinbach Bahnhof gefunden. --EvanE (talk) 22:52, 16 May 2018 (UTC)

Da stimme ich Dir zu. Die Liste selbst sollte beim Fahrplanwechsel (im Dezember jeden Jahres) bzw. bei Einführung neuer Linien innerhalb des Jahres angepasst werden, von jemandem, der sich zuständig fühlt. Das sehe ich als zentrale Aufgabe, um die sich nicht jeder Mapper selber kümmern muss. Allerdings könnte ich im Abschnitt "Andere ÖPNV Linien" einen Verweis auf die Liste machen, damit jeder sie kennt und ändern kann. In München haben wir andererseits z.B. eine Liste mit geplanten Fahrplanänderungen. --ToniE (talk) 07:55, 17 May 2018 (UTC)

Der route_master der Voreifelbahn taucht in der Liste "Other Public Transport Lines" auf, da die Voreifelbahn aus einem Teil S-Bahn (S23: Bonn - Euskirchen) mit entsprechendem Ausbaustandards (Hochbahnsteige, barrierefreie Zugänge, ...) und einem Teil Regionalbahn (RB23: Euskirchen - Bad Münstereifel) ohne diese Standards besteht. Die Züge fahren dabei die gesamte Strecke durch.
Die route_master Relation enthält sowohl die Relationen der S23 als auch der RB23. Sie hat daher konsequent ref=S23;RB23. Das wird (zugegeben wäre schwierig) nicht mit den Routen der S23 resp. RB23 assoziiert. Auf der anderen Seite sind sowohl Eltern- als auch Kind-Relationen bekannt oder zu ermitteln. --EvanE (talk) 23:46, 16 May 2018 (UTC)

Soweit ich mich erinnern kann hatte ich darüber schon mal mit User:hsimpson diskutiert. Nach meiner Meinung sind das zwei verschiedene Linien, die getrennt gemapped werden sollten (auch die Route-Master). Dass die Passagiere sitzen bleiben können und somit von S23 in den RB23 "unsteigen" ist für mich zweitrangig, das haben wir hier in München auch bei manchen Bussen. Ich vermute mal, die Zugbeschilderung vorne an der Lok und an den Seiten der Wagons ändert sich in Euskirchen automatisch von "S23" auf "RB23", ein weiteres Indiz für meine Annahme. Unter dieser Anhnahme erledigt sich das mit dem einzelnen Route-Master und es werden zwei draus. --ToniE (talk) 07:55, 17 May 2018 (UTC)

Nun ja als Nutzer des ÖPNV sage ich: "Ein Fahrplan => eine Linie". Aber darüber kann man trefflich streiten. Ich beende für meine Seite die Diskussion, da es für beide Ansichten Argumente gibt, die man jedoch nicht auflösen kann. --EvanE (talk) 18:52, 20 May 2018 (UTC)

"Ein Fahrplan => eine Linie"? Das ist eine Aussage, dann bin ich bei Dir. Aber dann sollten auch die Routes zusammengefasst werden und ebenfalls mit "ref=S23;RB23" gemapped werden. Ich bin der Ansicht, dass Route-Master und alle Routes identische "ref"-Werte haben müssen. So interpretiere ich zumindest das Proposal PTv2. Ob da jetzt ein Semikolon drin ist oder nicht ist für mich zweitrangig und läßt sich bei meinen Tool einfach einstellen: --separator="|" und eine entsprechende Änderung in der Liniendatei von ";" auf "|" als Trennsymbol ...
Bei Dingolfing, Landshut, Regionalbus Ostbayern, Deggendorf, Straubing, ... gibt es übrigens Kooperationen der verschiedenen 'network' mit z.B. ref="6097/21/13" und name="Bus RBO 6097/VSL 21/DGF 13 Straubing - Landau (Isar)" und ref:DGF="13", ref:RBO="6097", ref:VSL="21" und so weiter ... das macht's auch nicht einfacher. --ToniE (talk) 17:06, 22 May 2018 (UTC)

Ergänzung: Eine Meldung der Form   "route_master '%s' exists but ref/Network/... '%s' doesn't match."   wäre hilfreich.
Dann muss man nicht mühsam überlegen, was nicht passt. --EvanE (talk) 15:12, 22 May 2018 (UTC)

Guter Punkt, sollte einfach realisierbar sein. Den umgekehrten Fall, dass die "ref" von der Route nicht zu der vom Route-Master passt meldet das Tool schon, sofern die "ref" nicht unter "Andere ÖPNV Linien" auftaucht. Der Fall ist aber einfacher zu behandeln als umgekehrt --ToniE (talk) 17:06, 22 May 2018 (UTC)
Erledigt, ging schneller als erwartet.
"Multiple Routes but no Route-Master with same 'ref'" (wird noch geändert in "Multiple Routes but no Route-Master which fits here ('ref', 'network', ...)"
"'ref' = 'S23' of this Route does not fit to 'ref' = 'S23;RB23' of its Route-Master: %s"
--ToniE (talk) 07:32, 24 May 2018 (UTC)

Danke, damit wird klar warum das im Falle S23 und RB23 nicht funktioniert. Ich bin mir immer noch unschlüssig, ob und wie man das lösen kann.
Im Fall der RE22/RB22 (unterschiedliche Service auf einer Linie) habe ich das mit RE22/RB22 in Ref und in der VRS Liste vorläufig gelöst.
--EvanE (talk) 22:32, 27 May 2018 (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
      • 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)

  • das Thema ist gelöst, kein großer Aufwand: Einfach "S23;RB23";train;;;; - d.h. das normale CSV-Parsen, wenn der Separator im String vorkommt: in "..." einklammern
    • "S23;RB23|RB23|S23";train;Erfttalbahn;Euskirchen;Bad Münstereifel;DB Regio NRW
    • wodurch der Route-Master mit ref="S23;RB23" als auch seine Routes mit ref="RB23" und ref="S23" erlaubt sind

--ToniE (talk) 19:44, 25 March 2019 (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)

Mehrere stop_position bei der letzten Linie

Liegen auf der letzten Linie einer Bahn-Route mehrere Stop-Positionen, so führt das zu einer Fehlermeldung, dass die letzte resp. vorletzten Stop-Stelle in falscher Reihenfolge seien, obwohl sie in der Route richtig eingetragen sind. Wurden irgendwelche Prüfungen / Einstellungen geändert?

Bei mehreren Stop-Positionen am Anfang einer Bahn-Route gibt es keine Fehlermeldung. Dies habe ich an drei Stellen in Bonn überprüft (Godesberg, Oberkassel, Auerberg).   --EvanE (talk) 18:54, 1 November 2018 (UTC)

Hmm, ein Bug nachdem ich einen Bug korrigiert habe. An diese Konstellation hatte ich nicht gedacht. Ich schau mal nach. Es handelt sich vermutlich um: Tram 4, 7, 9, 12, 16, 17, 61, 62, 63, 65, 67
--ToniE (talk) 19:34, 1 November 2018 (UTC)
Korrigiert --ToniE (talk) 20:58, 1 November 2018 (UTC) (https://github.com/osm-ToniE/ptna/issues/51)
Ja und ja, genau diese Tram-Linien und bei der aktuellen Auswertung tauchen diese Meldungen nicht mehr auf.
Bei den Bahnlinien RE6 und RB25 ist das wohl so wie geplant? --EvanE (talk) 08:43, 2 November 2018 (UTC)
Ja, bei RE6 und RB25 greift der ursprüngliche Bugfix, denn hier liegt der Endhaltepunkt auf dem Verbindungspunkt von vor-letztem und letztem Gleisstück - d.h. das letzte Gleisstück ist in der Relation überflüssig.
--ToniE (talk) 09:16, 2 November 2018 (UTC)

NRW Tarif

Zur Zeit wird die Network-Angabe "NRW Regionalverkehr" bei etlichen Zuglinien durch "NRW-Tarif" (evtl auch mit/ohne Leerzeichen statt des Bindestrich) analog zum "WestfalenTarif" ersetzt. Das hat leider zur Folge, dass manche Zuglinien nicht mehr in der Auswertung erscheinen, da ja auf "NRW Regionalverkehr" geprüft wird. Aktuell war die RB90 (Limburg - Au (Sieg) - Siegen) davon betroffen (Schreibweisen wie bei der RB90 angetroffen). Ich habe bei der Linie einige Lücken geschlossen und dann bei 'network' ein "VRS" ergänzt, wie ich es bei anderen Zug-Linien gesehen hatte.
Gibt es dazu irgendwelche Informationen / Diskussionen / Abstimmungen? Im Wiki ist unter diesem Stichwort nichts zu finden. Bei der RB90 ist das konkret in diesen Changset erfolgt.
--EvanE (talk) 23:49, 9 January 2019 (UTC)

ich habe die Änderungen mitbekommen, weiß aber nicht warum, worauf die beruhen und ob das wegen offizieller Umbenennung erfolgt. Gibt es da eine einzelne Person die das bei OSM macht?
--ToniE (talk) 08:45, 10 January 2019 (UTC)
wäre aber kein Problem die diversen Varianten von "NRW-Tarif" als zulässig zu definieren (habe außer "NRW-Tarif" noch keine anderen gesehen)
--ToniE (talk) 09:04, 10 January 2019 (UTC)
Bisher ist mir nur alan1209 aufgefallen. Siehe den Changeset von oben und nachfolgende.
Der betreibt unter anderem die Umstellung auf den WestfalenTarif, was ja in der Tat einem neuen Verkehrsverbund (Bus+Tram+Bahn) entspricht.
Normalerweise fällt das kaum auf, da er meistens die einzelnen Verkehrsverbünde (VRR, VRS, ...) zusätzlich mit aufführt.
Gelegentlich rutscht aber mal einer durch die Maschen, wie bei der RB90 geschehen.
Soweit ich weiß gibt es den Begriff NRW-Tarif bei der deutschen Bahn.
Von daher ist NRW-Tarif vielleicht sogar die bessere Bezeichnung für die Bahnlinien. Wobei der NRW-Tarif auch für Busse und Straßenbahnen gilt.
Ich weiß nicht ob wir das gutheißen sollen oder nicht. --EvanE (talk) 23:44, 12 January 2019 (UTC)
Ich bin mit Alan in Kontakt, wir bearbeiten beide die WT-Linien-Daten im Wiki. Ich werden ihn mal auf "NRW-Tarif" ansprechen. --ToniE (talk) 12:59, 14 January 2019 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:VRS/Analyse&oldid=1954793"