DE talk:Aachener Verkehrsverbund

" Verschieben Diskussionseite!???"

Ich würde vorschlagen diese Diskussionen auf http://wiki.openstreetmap.org/wiki/DE:Aachener_Verkehrsverbund zu verschieben, da dort schon einiges zu dem Thema steht und es sonst übersehen wird. --Wonk 16:43, 2 October 2010 (BST)

"Bus 33 forward" vs. "Bus 33 Fuchserde"

Ich finde es extrem schwierig, den Überblick über die Buslinien zu behalten. Die Angabe forward/backward im Namen hilft einem nicht weiter, weil man die vom AVV festgelegte Orientierung normalerweise nicht kennt. Außerdem ist es äußerst verwirrend, dass die Begriffe forward und backward im Relationsnamen eine völlig andere Semantik haben als in den Rollen der Relationselemente. Ich würde deshalb vorschlagen, alle Buslinien, die schon dem neuen Schema entsprechen, umzubenennen, z. B. "Bus 33 Fuchserde" statt "Bus 33 forward". Das macht es einfacher, beim Mappen den Überblick zu behalten, aber auch beim Browsen in OpenStreetMap. Bei der Gelegenheit sollten wir den nichtssagenden Namenszusatz "alternativ" ersetzen durch etwas wie "über Musterhausen". --09:25, 23 September 2010 (BST)

Bin dafür. Bei manchen Buslinien ist auch gar nicht klar, was jetzt der "normale" und was der "abweichende" Fahrtweg ist. Für die 3[AB] würde ich eine zusätzliche Relation "Schleife durch Malteserstraße/Pontstraße" o.ä. vorschlagen ("normal" hält sie ja am Pontwall). -- Oli-Wan 11:25, 23 September 2010 (BST)

Bevor wir uns ans Umbenennen machen: im Bereich des VRS werden die Buslinien nicht als "Bus 30" getaggt, sondern als "VRS 30". Ob das für AVV auch sinnvoll ist? Also "AVV 33 Fuchserde"? --Head 19:52, 23 September 2010 (BST)

Hm. AVV steht noch im network, oder? Bus gibt immerhin das Verkehrsmittel an. Da besteht bei uns zwar keine große Verwechslungsgefahr - gibt ja schließlich nur Busse (RB 20 etc. mal außen vor - aber keine U-, S-, und Straßenbahnen - jedenfalls solange keine Campusbahn gebaut wird), erscheint mir aber transparenter, da weiß man gleich, was gemeint ist. (Oder gibt es weiter außen im AVV-Gebiet doch sowas?) Würde also für "Bus" plädieren. Ist mir aber nicht sooo wichtig, also wenn Dir "AVV" besser gefällt... -- Oli-Wan 21:02, 23 September 2010 (BST)

OK, ich lasse das "AVV" erstmal weg. Wir können es ja später immer noch leicht nachtragen, sollte sich das allgemein durchsetzen. --Head 15:55, 24 September 2010 (BST)

direction=forward/backward

Ich finde die vorgeschlagene Nutzung des Tags direction=forward bzw. backward extrem unnötig und verwirrend. Ich erlaube mir, das beim Überarbeiten der Buslinien herauszunehmen und stattdessen nur from und to zu verwenden. Hier ein Beispiel:

Bisher:

name=Bus 33 forward
direction=forward
from=Vaals (NL)
to=Fuchserde

name=Bus 33 backward
direction=backward
from=Vaals (NL)
to=Fuchserde

Jetzt:

name=Bus 33 Vaals (NL) - Fuchserde
from=Vaals (NL)
to=Fuchserde

name=Bus 33 Fuchserde - Vaals (NL)
from=Fuchserde
to=Vaals (NL)

Damit werden, sobald diese Änderungen durchgezogen sind, die Begriff forward und backward nur noch für die Rollen von Straßen verwendet, was es hoffentlich etwas einfacher macht, an diesem Teilprojekt mitzuarbeiten. --Head 16:01, 24 September 2010 (BST)

Die Verwendung von direction=forward/backward ist der Weg, wie es wohl andere im OXOMOA-Schema anwenden. Man sollte dieses klären, bevor man einen Sonderweg wählt. Die name-Eigenschaft sollte in jedem Fall mit " Bus <Nr.>.." beginnen, damit man die verschiedenen Varianten direkt zusammen sieht.--Wonk 16:51, 2 October 2010 (BST)

Mit dem "Bus <Nr.>" am Anfang hast du natürlich recht, das war nur ein Tippfehler in meinem Beispiel oben. Gibt es irgendwo eine Seite, auf der vorgeschlagen wird, direction=forward/backward einzusetzen? Auf User:Oxomoa/ÖPNV-Schema steht dazu nichts. --Head 19:29, 2 October 2010 (BST)

Ich habe das aus dem Tagging in Kiel übernommen, wo das OXOMOA-Schema sehr früh angewendet wurde. Ich finde die Namensgebung von Head aber besser. Es bleibt die Frage, ob es nicht sinnvoll wäre, wenn ein Programm die Zugehörigkeit von Hin- und Rückroute leicht erkennen könnte. Andererseits ist es in der Realität manchmal so, dass die Routen selbst im Grundverlauf hin und zurück sehr unterschiedlich sind. Es fehlt bisher eine durchgängige Normung. Man sollte das in talk.de allgemein diskutieren.--Wonk 10:37, 3 October 2010 (BST)

Die Relation ist doch am einfachsten zu verstehen, wenn man als Name das einträgt, was vorne am Bus steht: "Bus 33 Vaals" oder "Bus 33 Fuchserde". forward und backward im Namen setzt irgendwie voraus, dass man eine Richtung als bevorzugt definiert. --Ajoessen 17.10.2020

Fehlende Haltestellen

Unter anderem fehlen folgende Haltestellen. Erledigtes bitte aus der Liste streichen.

• Heerlen: Bradleystraat stadtauswärts (Lijn 50)
• Richtung Eupen (Linie 14): auf belgischer Seite (jenseits Köpfchen Grenze) fast alle Haltestellen
• Lichtenbusch: Lichtenbuscher Weg, Kesselstraße (betrifft mindestens Linie 55)

Ergänzen fehlender Haltestellen; Plattform-Nodes vs. -Ways

@Daniel - ich finde es gut, daß Du Dich derzeit so aktiv um die lange vernachlässigten Buslinien kümmerst. Vorschlag: Wenn eine Haltestelle (wie bei Linie 23 gesehen) in der Karte fehlt, trag sie an einer grob geschätzten Position ein, kleb ein dickes FIXME dran (und setz am besten einen OSB) und berücksichtige die Haltestelle schon in der Relation. Sonst geht beim nachträglichen Eintragen doch wieder nur die Relation kaputt, passiert ja sowieso ständig.

Falls Du nicht selbst hinkommst, werde ich versuchen, mich nach und nach um die so markierten Bugs zu kümmern. Am besten mehrere separate Haltestellen (für links und rechts) und den Knoten nicht auf, sondern neben die Straße legen: zusammenfassen, wenn die Haltestellen dann doch direkt gegenüberliegen, ist einfacher, als aufspalten und auseinanderklamüsern im umgekehrten Fall. Das geht dann doch wieder nur schief. -- Oli-Wan 11:25, 23 September 2010 (BST)

Schau dir bitte nochmal DE:Aachener Verkehrsverbund#Taggen von Buslinien in Aachen und Umgebung an: An einfachen Haltestellen wird auf dem Fahrweg ein Knoten gesetzt. An diesen Knoten dran kommt dann ein Way für die Plattform, vgl. Elisenbrunnen. Ich gehe davon aus, dass es unser Ziel ist, dieses Schema flächendeckend umzusetzen. Dafür ist es aber wenig hilfreich, Knoten neben die Strecke zu setzen, denn solche Knoten kommen in dem Schema nicht vor. --Head 12:14, 24 September 2010 (BST)

Für komplexe Haltestellen (also nicht nur zwei H-Schilder einander fast direkt gegenüber) schlägt das Schema zusätzliche platform-Knoten vor, und zwar neben der Straße: zusätzliche platform-Knoten rechts und links neben dem Fahrweg an den passenden Stellen. Die platform-Wege sind für besonders große Haltestellenbereiche gedacht. Es scheint mir etwas übertrieben, jetzt an jede Haltestelle solch einen Weg zu kleben. Das gibt schon alleine die GPS-Positionsgenauigkeit nicht her.

Meine Überlegung zu den aufgespaltenen provisorischen Knoten war, daß es einfacher ist, zwei Knoten zu vereinen und anschließend in den Weg einzufügen, falls man feststellt, daß die Haltestelle "einfach" ist, als die Knoten aufzuspalten und anschließend richtig auf die Relationen zu "verteilen", wenn die Haltestelle "komplex" ist. Da habe ich mich geirrt: die stop_position- und platform-Knoten bekommen unterschiedliche Rollen in den Relationen, sodaß man in jedem Fall die Relationen nachträglich bearbeiten muß. Meine Idee bringt insofern nichts.

Kuckelkorn muß also auch überarbeitet werden: beide stop_positions müssen in platforms überführt werden, dazu ein logischer Haltepunkt stop_position (ich würde die Kreuzung vorschlagen), und die Busrelationen müssen entsprechend geändert werden (also stop_position als stop und platform als platform). Den letzten, mühsamen Schritt wollte ich vermeiden, aber das ist wohl leider nicht möglich. Ach ja, und eine stop_area-Relation.

Also neuer Vorschlag: setz einen stop_position-Knoten an die geschätzte Stelle auf dem Fahrweg, mit FIXME und OSB und bau die stop_position als role=stop in die Busrouten ein. Die so markierten Haltestellen (im Stadtgebiet Aachen, mehr kann ich nicht versprechen) werde ich dann nach und nach überprüfen und, falls nötig, um platform-Knoten (oder im Einzelfall auch -Wege) ergänzen - und zwar neben dem Weg - und diese in die Relationen einbauen. -- Oli-Wan 15:24, 24 September 2010 (BST)

Ich finde es eigentlich sauberer, bei einfachen Haltestellen pro Fahrtrichtung eine Plattform (Knoten oder Weg) und eine Stopp-Position (Knoten auf der Straße neben der Plattform) einzutragen. Dann hat man das sauber getrennt nach Fahrtrichtung, was meines Erachtens leicher wartbar ist. Außerdem sind die beiden Haltepunkte ja in der Realität selten genau gegenüber voneinander. --Head 17:55, 24 September 2010 (BST)

Das heißt im Klartext, Du willst jede einfache Haltestelle genauso behandeln wie eine komplexe Haltestelle? Sauber getrennt ja - dafür aber auch doppelte Arbeit, und zwar auch bei späteren Änderungen. Wenn jetzt jemand Änderungen vornimmt, der sich da nicht so eingearbeitet hat wie Du, vergißt er garantiert irgendwo entweder einen stop oder eine platform. Und wirklich genau gegenüber sind die Haltepunkte tatsächlich nie - aber auch bei Abständen von z.B. 20 Metern zwischen den Schildern kann man m.E. mit gutem Gewissen einen Knoten in die Mitte setzen. Wer es bis dahin geschafft hat, wird auch noch die richtige Straßenseite finden. -- Oli-Wan 20:50, 24 September 2010 (BST)

Habe nochmal nachgedacht und auf der Oxomoa-Seite nachgelesen, die für mich um einiges verständlicher ist als die Beschreibung bei uns. Okay, meinetwegen bei neuen Haltestellen komplette Aufspaltung. Aber bestehende Haltestellen würde ich erstmal nicht anfassen, nur von highway=bus_stop auf (zusätzlich) public_transport=stop_position, bus=yes umsatteln; aufspalten nur bei Bedarf (d.h. wenn die Haltepunkte nicht "genau" gegenüber liegen und das noch nicht abgebildet wurde).

Ich glaube, das Thema läßt sich besser anhand von Beispielen als abstrakt diskutieren. Also neue Haltestellen wie "Halifaxstraße"; bei größeren Haltebereichen wie "Elisenbrunnen". Bestehende "einfache und halb-einfache" Haltestellen erstmal nur umtaggen, "komplexe" nach und nach komplett umstellen. Definitionen: einfach - zwei Haltepunkte (fast) direkt gegenüber; halb-einfach - zwei Haltepunkte an derselben Straße, aber größerer Versatz; "komplex" - mehr als zwei Haltepunkte und/oder auf mehrere Straßen verteilt, wie "Halifaxstraße". Ist das mehrheitsfähig? -- Oli-Wan 21:54, 24 September 2010 (BST)

Ich habe jetzt die Haltestellen Halifaxstraße und Karlsgraben an das Schema angepasst. Es wäre nett, wenn jemand mit GPS die genauen Positionen der Haltestellen überprüfen könnte. --Head 12:14, 24 September 2010 (BST)

M.E. reichen dort platform-Knoten (s.o.). -- Oli-Wan 15:24, 24 September 2010 (BST)

Für "Halifaxstraße" habe ich gerade Knoten an die "richtige" Stelle (H-Schild modulo 3-4 Meter Unsicherheit) gesetzt. Die stop_area-Relation fehlt dort noch (ich wußte ja nicht, ob Du jetzt wirklich platform-Wege benutzen willst oder mit den Knoten zufrieden bist). Übrigens gut geschätzt. -- Oli-Wan 17:46, 24 September 2010 (BST)

zone=6646 etc.

Viele Haltestellen in Aachen sind mit Zoneninformationen wie zone=6646 getaggt. Diese stammen aus Changeset 2190060 (und möglicherweise weiteren, gleichartigen Changesets), wo jemand die niederländischen Zonendaten importiert hat. Diese Daten wurden vermutlich auch in viele weitere, neu angelegte Haltestellen übernommen. Mit dem AVV hat das ganze nichts zu tun. Mein Vorschlag wäre, die ganzen Zoneninformationen für Haltestellen auf deutschem Gebiet in zone:NL umzutaggen. Nächste Frage, die sich stellt: Stehen uns Informationen über die Tarifzonen des AVV zur Verfügung - und wollen wir uns die Mühe machen, sie einzutragen? -- Oli-Wan 22:35, 7 November 2010 (UTC)

"AVV 50" statt "Bus 50"?

Was haltet ihr davon, die Relationen umzubenennen, um ihre Zugehörigkeit zum AVV zu verdeutlichen? Gerade an den Verbundsgrenzen dürfte das die Übersichtlichkeit erhöhen. Wir haben hier ja im Moment den Konflikt AVV 50 vs. Veolia 50, da regeln wir es durch "Linie 50" vs. "Lijn 50". In die anderen Himmelsrichtungen funktioniert dieser Trick nicht. Die Kölner verwenden das Schema "VRS 339". Sollen wir auch auf "AVV 50" umstellen? --Head 12:02, 21 March 2011 (UTC)

Find ich gut.--Zuse 13:36, 21 March 2011 (UTC)

Bin auch dafür. Im AVV gibts ja keine Verwechslungsgefahr mit anderen Verkehrsmitteln, ansonsten könnte man noch beides kombinieren. --Oli-Wan 16:41, 21 March 2011 (UTC)

"Campus-Bahn" rauswerfen?

Können wir die "Campus-Bahn" löschen? Grundregel bei OSM ist doch: Wir mappen das, was existiert, im Bau ist (construction) oder zumindest ganz konkret geplant (proposed), will sagen: wenn es einen Beschluß der zuständigen politischen Gremien gibt oder dieser nahezu sicher absehbar ist und auch die Trassenführung etc. im wesentlichen steht. Davon ist die "Campus-Bahn" ja nun weit entfernt, im Moment ist sie Wunschdenken einiger Politiker und der ASEAG (und sollte es zur Realisierung kommen, ist dafür 2020 angepeilt). proposed steht ja nicht für "hat mal irgendjemand vorgeschlagen". Dann könnten wir die Datenbank gleich noch mit ein paar weiteren Tagträumen und unsicheren Vorhaben vollmüllen: zwei neue Autobahnanschlußstellen (Würselen, Stolberg), die B 258n, sämtliche in den letzten 15 Jahren diskutierten Varianten für den Umbau des Flugplatzes Merzbrück, das berühmte dritte Bahngleis und Windenergiekonverter an allen Standorten, die mal ganz vage angedacht wurden. --Oli-Wan 16:54, 22 March 2011 (UTC)

Ja raus.--Zuse 19:44, 22 March 2011 (UTC)

Bin auch für löschen. --Head 15:47, 25 March 2011 (UTC)

Hab sie gerade rausoperiert.--Zuse 13:36, 1 April 2011 (BST)

Relation AVV reparieren

In diesem Changeset http://www.openstreetmap.org/browse/changeset/7057209 hat User Merzen anscheinend die AVV-Relation kaputtgemacht. Kann bitte jemand die Relation AVV (57425) auf v133 zurücksetzen? Ich habe das Reverter-Plugin für JOSM installiert, aber komme damit nicht zurecht. --Head 15:47, 25 March 2011 (UTC)

Hab mich schon gewundert, wo die Relation geblieben ist. War so frei, sie neu anzulegen: 1505281 1505281 --Oli-Wan 16:27, 25 March 2011 (UTC)

Abstimmung ÖPNV-Schema

Aktueller Hinweis: Auf Proposed features/Public Transport läuft die Abstimmung über das "neue" ÖPNV-Schema.

Hat sich erledigt, der Vorschlag wurde inzwischen angenommen.

public_transport=platform

In der public_transport=platform - Beschreibung ist ein Fehler:

Siehe dazu das Public Transport Proposal: "A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole."

Ein Node mit public_transport=platform entspricht also nicht einem Node mit highway=bus_stop. Ersteres besagt, dass dort nichts außer allenfalls einem Schild ist!

Weide

Also laut dem hier ist das so korrekt. Beides in eine Node: http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dbus_stop --Hsimpson (talk) 11:58, 12 July 2016 (UTC)

Ich sehe den Sinn von public_transport=platform darin, baulich getrennte, als way gemappte Haltestellenbereiche zu kennzeichnen, damit diese entsprechend gerendert werden. So funktioniert das ja auch in der Praxis. Wozu sollte eine einzelne Node ein public_transport=platform benötigen? Meines erachtens werden Bushaltestellen in 80% der Fälle ohnehin am besten als einzelne Node gekennzeichnet. public_transport=platform halte ich nur bei baulich getrennten Busstiegen sinnvoll, wie z.B. Die Inselhaltestelkle Scheibenstraße in Aachen.--Trockennasenaffe (talk) 12:08, 12 July 2016 (UTC)

Bitte die platform in der node belassen. Die wird z.B. von JOSM gebraucht um die Rolle als platform im Zuge einer Linienrelation zu erkennen. Grüße --Hsimpson (talk) 12:14, 12 July 2016 (UTC)

Sorry, hast recht. Hab das gerade mit highway=platform verwechselt.--Trockennasenaffe (talk) 15:36, 12 July 2016 (UTC)

Veraltet

Vieles was auf dieser Seite steht ist hoffnungslos veraltet. Die Informationen sind im besten Fall nutzlos und im schlechtesten Fall grob falsch oder irreführend. Wenn das keiner aktuallisieren mag sollte man vielleicht eine Warnung hinzufügen.--Trockennasenaffe (talk) 16:47, 22 February 2016 (UTC)

Rückänderung AVV 33 auf Bus 33?

Hier gab es früher mal einen Konsens, dass alle Linien von Bus [Liniennummer] auf AVV [Liniennummer] geändert wurden, um die zugehörigkeit zum Verbund zu verdeutlichen. Das halte ich inzwischen für überflüssig. Es gibt mir dem network-tag ein gutes Instrument, um Dopplungen, wie z.B. bei der Linie 50 zu vermeiden. Da die Holländischen Linien kein network-tag besitzen, würde ich für die Linie 50 nework=OV vorschlagen, da die OV-Chipkaard der Funktion eines Verkehrsverbundes in D noch am nächsten kommt. AVV 33 als name ist somit ein Sonderweg von einigen Verbünden, der früher vieleicht sinnvoll war, aber inzischen unnötig geworden ist und zum zwecke der Einheitlichkeit meiner Meinung anch zurückgenommen werden sollte. Ich würde mich natürlich an der Umstellung beteiligen ;) Viele Grüße, --Hsimpson (talk) 16:50, 11 July 2016 (UTC)

Bus 33 wär nach Ptv2 die korrekte Bezeichnung, allerdings sind woghl aus historischen gründen fast alle Buslinien im AVV nach dem Schema AVV 33 benannt. Wenn jemand das mal einheitlich ändern würde fände ich das gut.--Trockennasenaffe (talk) 09:02, 12 July 2016 (UTC)

Die Einführung desgleichen ist auch hier im Talk dokumentiert, unter "AVV 50 statt Bus 50" Grüße --Hsimpson (talk) 09:12, 12 July 2016 (UTC)

So, ich hab die Seite jetzt mal komplett überarbeitet und die beiden Änderungen da mal mit reingenommen. --Hsimpson (talk) 13:33, 12 July 2016 (UTC)

Ich verweise mal hierhin: klick --Hsimpson (talk) 10:06, 13 July 2016 (UTC)

Finde ich gut, dass du dich da engagierst. Hatte das ja mal angestoßen, aber letztendlich verlief es im Sand, da ich da momentan nicht die nötige Zeit habe mich drum zu kümmern. Ich werde aber weiterhin mithelfen.--Trockennasenaffe (talk) 10:14, 13 July 2016 (UTC)

Neue Routenlinks

Ich hab mal die Art, auf die Routenrelationen zu verweisen, aus dem VRS übernommen und an die Linie 1 gepackt. Diese Art beinhaltet eine Overpass-Abfrage, was den Prozess zwar deutlich verlängert, aber auch wesentlich Fehlerresistenter ist (z.B. sind fast alle Links auf Relationen, die im Moment auf der Seite existieren inzwischen tod, weil die Relationen schon vor langem gelöscht wurden). Grüße --Hsimpson (talk) 14:35, 13 July 2016 (UTC)

Funktioniert allerdings nur mit Linien, die schon ne Masterroute haben... --Hsimpson (talk) 14:37, 13 July 2016 (UTC)

Finde ich gut. Dabei muss man jedoch beachten, dads einige Linien aus der Liste nicht mehr existieren und manche dazugekommen sind. Ich würde mir erst mal ne aktuelle übersicht besorgen und die Tabellen dann neu machen. Die Informationen darin sind eh größtenteils veraltet und unzuverlässig, so dass da ohnehhin bei jedem eintrag erst jemand drüber schauen müsste.--Trockennasenaffe (talk) 14:43, 13 July 2016 (UTC)

Open Data

Vom AVV gibt es jetzt umfassende offene Daten unter http://opendata.avv.de/. Die Lizenz ist kompatibel zu OSM. Es ist noch zu klären, wie sich die Daten konkret nutzen lassen.--Trockennasenaffe (talk) 10:50, 2 May 2017 (UTC)

Schreibweisen

Bisher sind fast alle Linienrelationen nach den Schema "Start - Ziel" (mit Bindestrich) eingetragen. Ich habe im Rahmen des Fahrplanwechsels bei den betroffenen Linien die Schreibweise auf "Start -> Ziel" geändert (Minuszeichen + spitze Klammer zu, lt. diesem Wiki). Verbreiteter scheint aber die Schreibweise "Start => Ziel" (Gleichheitszeichen + spitze Klammer zu, siehe VRR oder VRS) zu sein. Sollten wir uns im Bereich AVV dem anschließen und ebenfalls "=>" verwenden?

Ja Siehe: https://wiki.openstreetmap.org/wiki/DE:Public_transport#Fahrtvariante.2FRoutenrelation --Hsimpson (talk) 14:23, 14 December 2017 (UTC)

Ah, da habe ich das wohl übersehen. Blöd, wenn Informationen an mehreren Stellen stehen und dann auch noch unterschiedlich sind. Ich hatte mich bisher hauptsächlich an der AVV-Wikiseite orientiert, die ich dann dahingehend mal korrigiere. --Aixbrick (talk) 17:13, 14 December 2017 (UTC)

Bei Linien mit Buchstaben (z.B. N 1, AL 4) steht zwischen Buchstabe und Ziffer/Zahl ein Leerzeichen. Korrekt lt. Fahrplan und den Auskunftsmedien ist aber offenbar die Schreibweise ohne (also N1, AL4). Ändern? --Aixbrick (talk) 11:19, 14 December 2017 (UTC)

Ist mir egal, Hauptsache, das ganze ist einheitlich. Daher würde ich persönlich das einfach so lassen, wie es ist. Grüße --Hsimpson (talk) 14:23, 14 December 2017 (UTC)

Stimmt, zumal ich gesehen habe, dass der AVV es auf seiner Seite (Linienfahrpläne) auch mit Leerzeichen schreibt. --Aixbrick (talk) 17:13, 14 December 2017 (UTC)

Bilanz und was noch zu tun ist

Seit meinem letzten Besuch auf der Seite hat sich ja echt was getan, Respekt! Die Umstellung auf PTNA ist offenbar sehr hilfreich. Ich würde gerne mal anfangen Bilanz zu ziehen, was noch zu tun wäre, bzw Fehler die mir aufgefallen sind:

• Die Nachtbusse im Kreis Düren fehlen komplett. Ich wüsste nicht, warum die nicht gemappt werden sollten. Vielleicht sollten wir die zumindest in die Auswertung mit aufnehmen um zu dokumentieren, dass die fehlen.
• Reine Verstärkerfahrten fehlen komplett - das ist eine nachvollziehbare Entscheidung, die nicht zu mappen, aber diese Entscheidung sollte man hier dokumentieren.
• Es wird eine Relation "Rursee Bahn" erwartet, in der Realität existiert eine Relation "RURSEE-BAHN", di allerdings recht kaputt ist und mal komplett überarbeitet werden sollte. Vielleicht sollten wir generell mal festhalten, wie "halböffentlichen" Verkehren diese Art umzugenhen ist
• Für Bedarfsverkehr gibt es wohl OSM-weit bisher keine Lösung, wobei ich es für einfach und praktikabel halte, entweder Bediengebiet oder Summe der möglichen Haltestellen zu mappen, falls dies mal standardisiert ist.

Das ist sicherlich noch nicht alles, ich werde mich damit in den nächsten tagen weiter beschäftigen.--Trockennasenaffe (talk) 07:11, 21 April 2023 (UTC)

• Bei den Nachtbussen gibt es meiner Meinung nach mehrere Probleme: Sie fahren nur in eine Richtung (keine Rückfahrt), sie halten nur zum Aussteigen, es wird in jedem Ort nur eine Hst angefahren, der Fahrer bestimmt die Route, sie sind teurer. Das hat mich bisher immer davon abgehalten, diese zu mappen, weil solche Informationen irgendwie sinnvoll erfasst werden müssen.
• Bei Verstärkerfahrten (zumindest die reinen "V"-Fahrten, also nicht die "<Nummer>V") gibt es hauptsächlich das Problem, dass sie nirgendwo stehen. Es gibt keine Fahrplantabellen (wie bei den normalen Linien), sie stehen nicht im Netzplan, man findet sie nur in den Hst-Fahrplänen oder in der Onlineauskunft. Dazu kommt, dass sie auf Schulen ausgerichtet sind. Das macht sie schwer wartbar, weil sich das quasi sogar während des Schuljahrs ändern kann. Informationen dazu findet man aber kaum, also veralten diese Relationen schnell(er).
• "Halböffentliche" Verkehrsmittel können natürlich als PTv2-Relation gemappt werden. Sie dürfen aber nicht Mitglied des Verkehrverbund-Netzwerk-Tags (network) sein. Mehr muss da m.M.n. nicht beachtet werden.
• Hst des Bedarfsverkehr können wie normale Hst gemappt werden. Das habe ich z.B. im Kreis Heinsberg mit den reinen Multibus-Hst gemacht. Das Gebiet könnte man evtl. als boundary erfassen.--Aixbrick (talk) 14:56, 21 April 2023 (UTC)

OK, das wusste ich nicht, dass die Nachtbusse in Düren so speziell sind. In den Daten des AVVs sind die als normale Linie mit Haltestellen und Fahrweg enthalten. Nur eine Richtung ist jetzt auch nicht völlig ungewöhnliches, aber ich würde mir wahrscheinlich auch nicht die Mühe machen. Wenn wir die Rursee Bahn mit rein nehmen, können wir eigentlich auch Museumsbahnen rein nehmen oder? Da gibt es teilweise auch Relationen.--Trockennasenaffe (talk) 16:18, 21 April 2023 (UTC)

In den Niederlanden gibt es auch Relationen für Museumsbahnen: https://www.openstreetmap.org/relation/2813685. Könnte man also auch für die Selfkantbahn erstellen.--Aixbrick (talk) 17:34, 21 April 2023 (UTC)

Genau die hatte ich vor Augen, die geht ja auch nach Aachen rein.--Trockennasenaffe (talk) 17:39, 21 April 2023 (UTC)

Die Rursee-Bahn wurde überarbeitet und ist jetzt PTv2. Ich habe die Schreibweise mit Bindestrich beibehalten (lt. https://www.rursee-schifffahrt.de/wp-content/uploads/2022/12/Rursee-Schifffahrt_Fahrplan_2023.pdf), aber auf die komplette Großschreibung (weil nur Marketing) verzichtet.--Aixbrick (talk) 09:09, 22 April 2023 (UTC)

GTFS-Daten

Ich habe mal angefangen, die GTFS-ids für PTNA an die Relationen zu taggen. Je weiter ich damit komme, desto sinnloser scheint mir dieses Unterfangen jedoch, obwohl das Feature an sich sehr gut ist. Ein Punkt ist, dass die ID zumindest für die einzelnen Fahrten nicht stabil sind. Die müsste man also wohl für jede neue Version aktualisieren und da dies Arbeit für Wochen ist, käme man da wohl kaum hinterher. Des weiteren ist es wohl so, dass die Aufteilung in Linien in den GTFS-Daten nicht immer genau mit unseren Master-Routen korrespondiert. Zum einen die Ringlinien, die bei uns eine gemeinsame Master-Route sind z.B. 3A/B aber auch die Alt-Fahrten, die in den GTFS-Daten eine eigene Linie sind. Gerade die Behandlung von Alt-Fahren wäre noch ein Thema für sich, dazu mache ich noch mal ein eigenes Thema auf. Ansonsten müssten wir auch mal sehen, was genau der angestrebte Endzustand des Linien-mappings sein soll. Laut den GTFS-Daten haben die Linien im Schnitt grob geschätzt ca 20 Varianten mit Extremwerten von bis zu 60. Dies alles zu mappen und zu warten dürfte kaum praktikabel sein. Bei den bisher gemappten Varianten scheint die ungeschriebene Regel zu sein, dass nur Varianten gemappt werden, die keine Teilmenge einer anderen Variante sind. Auch das wurde aber nicht zu 100% durchgezogen.--Trockennasenaffe (talk) 07:42, 25 April 2023 (UTC)

GTFS ist zwar ganz nett, für OSM m.M.n. aber kaum nutzbar - zumindest wenn man ein großes Liniennetz und zig Varianten hat. Ich bin zu der Erkenntnis gekommen, dass eine vollständige Erfassung aller Linien und deren Routen in OSM ein fast aussichtsloses Unterfangen ist. Das fängt schon damit an, dass mind. 1x im Jahr Änderungen erfolgen. Dazu kommt, dass die Relationen immer wieder durch andere Editier-Aktionen (hauptsächlich auftrennen von Wegen) "kaputt" gehen. Und dann gibt es noch Sperrungen, die, wenn sie länger als einige Wochen andauern, auch in OSM abgebildet werden sollten. Ist davon eine Straße mit 50+ Relationen betroffen, vergeht einem der Spaß, wenn man den geänderten Weg wieder zusammenklicken muss. Daher habe ich für mich entschieden, dass zwar grundsätzlich alle Linien erfasst werden sollten (mit Ausnahmen), ich mich dabei aber auf die häufigsten und/oder wichtigsten Varianten beschränke. Wichtig ist eigentlich nur, dass man auf einer entsprechenden Karte den Fahrtverlauf in etwa erkennen kann (z.B. Linie 52 fährt von Aachen nach Eschweiler). Wenn eine Linie 1x/Tag noch einen zusätzlichen Schlenker über ein Gewerbegebiet macht, um dort eine Haltestelle anzufahren, die anderen 9 Fahrten aber immer denselben Weg nutzen, dann fällt die eine Fahrt in OSM halt unter den Tisch, weil das wieder eine weitere Relation wäre. Mit dem jetzigen Taggingschema (pro Variante eine Relation) ist eine vollständige Erfassung aller Linienvarianten kaum machbar und nur mit einem hohen Wartungsaufwand verbunden. Dazu reicht die Zeit einfach nicht.--Aixbrick (talk) 14:40, 25 April 2023 (UTC)

GTFS nutzen heißt ja nicht zwingend, dass man alle Varianten mappen muss. Ich dachte allerdings das würde zumindest dabei helfen zu erkennen, wenn sich lin ienwege geändert haben oder Linien dazugekommen oder weggefallen sind. dazu müssten aber zumindest die IDs über die zeit konsistent sein, was sie beim AVV nicht sind. Mit Sperrungen haben die Daten eh nichts am Hut, da die Aseag keine Baustellenfahrpläne kennt.Da werden nur Hinweistexte ausgegeben. Allerdings könnte man sich wohl doch mal Gedanken machen, ob man die euregiobahn nicht doch aufsplitten möchte. Die ist jetzt schon fast zwei Jahre bei Eschweiler Aue unterbochen und wird das wohl auch noch mindestens ein Jahr sein.--Trockennasenaffe (talk) 15:03, 25 April 2023 (UTC)

Und genau das mit den konstanten IDs über die Zeit ist das Problem. Selbst wenn du nicht alle Varianten in OSM hast, musst du die vorhandenen der ID zuordnen. Nach einem Jahr ändert sich das dann wieder - zumindest offenbar beim AVV. Dann fängst du wieder von vorne an. Und umso mehr Varianten es gibt, desto aufwändiger ist das. Insgesamt bezog sich mein Kommentar aber vor allem auf deine Frage nach dem "angestrebten Endzustand".--Aixbrick (talk) 15:40, 25 April 2023 (UTC)

Die GTFS-IDs der Routen sind tatsächlich nicht stabil, sondern verweisen nun auf andere Linienverläufe. Nutzbar sind aktuell nur noch die IDs der Master (fragt sich nur wie lange). Ich wäre dafür, die zu löschen und nicht mehr an den Linien zu erfassen, da das auf Dauer nicht aktuell zu halten ist.--Aixbrick (talk) 16:36, 7 November 2023 (UTC)

Ja zu dem Schluss bin ich auch gekommen, daher habe ich da auch zwischenzeitlich jede Aktivität in diese Richtung eingestellt. Bekommt man die Daten ohne großen Aufwand wieder gelöscht?--Trockennasenaffe (talk) 18:40, 7 November 2023 (UTC)

Hab ich gelöscht. Das geht mit JOSM und einer "overpass turbo"-Abfrage (herunterladen von Relationen mit Netzwerk "Aachener Verkehrsverbund" und Tag "gtfs:shape_id").--Aixbrick (talk) 16:29, 8 November 2023 (UTC)

Es ist so, dass zumindest die route_id konstant zu bleiben scheinen. Daher ist es wohl zumindest hilfreich, diese auf der Konfigurationssete für die Auswertung zu behalten. Die Daten an die Relationen zu taggen werde ich aber zumindest vorläufig aufgeben, bis ich da eventuell eine sinnvollere Vorgehensweise gefunden habe.--Trockennasenaffe (talk) 06:04, 26 April 2023 (UTC)

Es laufen die ersten Edits zu einem GTFS-Proposal inkl. Diskussion in der Community. Zum Thema "Die GTFS-IDs der Routen sind tatsächlich nicht stabil,..." sollte dort auch was entstehen: "best practice"?

Ich glaube mittlerweile einfach, dass das GTFS-Format grundsätzlich nicht dafür geeignet ist, dass GTFS-Daten mit OSM verknüpft werden, auch wenn das verlockend klingt, einfach weil GTFS keinerlei Garantien gibt, das irgendwelche Verknüpfungspunkte stabil sind und selbst wenn es hier und da in der Praxis so ist, gibt es keinerlei Garantie, das das so bleibt. GTFS wurde dazu einfach nicht geschaffen. Alle Informationen eines GTFS-Datensatzes haben nur innerhalb dieses Datensatzes Gültigkeit.--Trockennasenaffe (talk) 20:21, 7 November 2023 (UTC)

Ich glaube das auch, hängt aber stark vom GTFS feed selber ab: wie die Daten strukturiert sind. Ich hatte für's Proposal vorgeschlagen, auf diese Problematik im Porposal in einem eigenen Kapitel "Best Practice" (oder so) hinzuweisen.

Fahrplanwechsel bei der Aseag am 14.1.

Am 14.1. ist fahrplanwechsel bei der Aseag. Dabei werden in der Städteregion auch viele Haltestellen umbenannt. Hier gibt es eine Liste: https://auskunft.avv.de/download/1698145019147_Umbenennungen_2024.pdf --Trockennasenaffe (talk) 14:03, 5 December 2023 (UTC)