ÖPNV Stadt Kassel - Stichtag 2018-03-25

Am Stichtag Sonntag, 25. März 2018
gibt es in der Stadt Kassel die größte Umstellung der ÖPNV-Linien seit 30 Jahren.
Betroffen ist ein Großteil des Schienen- und Straßenverkehrs einer Großstadt.
Ich poste das jetzt schonmal hier, um Interessierte mit Kompetenz anzusprechen (ich zähle mich nicht dazu) und wegen einer vorsorglichen diesbezüglichen Bitte - s.u.

Links:

ÖPNV-Träger ist die Kasseler Verkehrs-Gesellschaft (KVG):
https://de.wikipedia.org/wiki/Kasseler_Verkehrs-Gesellschaft

Übersicht der Änderungen:
http://www.kvg.de/kasseler-linien-ab-25318/

Der neue/zukünftige Netzplan:
https://netz.kvg.de/slnp#

Stadtplan (auf OSM-Basis) mit neuer/zukünftiger Linienführung:
https://netz.kvg.de/

Hinweis bitte lesen:

Wer sich nicht nur mit den ÖPNV-Linien, sondern auch mit den Geometriedaten beschäftigt,
der sollte bitte unbedingt die Aerowest-Luftbilder verwenden
http://www.aeroview.de/aerowest_IWS/map.php?user=osm&pwd=osmonly
(Stand 2014, Projektionsmethode UTM in JOSM)
Bitte bitte keine voreiligen Verschiebungen aufgrund irgendwelcher bing, esri oder sonstiger (aktuell) krummen Dinger.

Ich selbst werde mich mangels Fachkenntnis zu PTvxyz eher nicht beteiligen, kann aber ggf. (andere) auftauchende Fragen (mit)beantworten.

Gruß in die Runde
Jo

Hallo Jörg,

evtl. kann ich aus der Ferne etwas beisteuern: eine Soll-Ist-Analyse der dortigen ÖPNV-Linien.

Siehe meinen Beitrag zu einem anderen Thread hier im Forum:

https://forum.openstreetmap.org/viewtopic.php?pid=683855#p683855

Der notwendige Beitrag für die Kasseler Mapper ist dabei recht gering …

Viele Grüße
Toni

Da ich hier auch vor ähnlichen Problemen bei Fahrplanwechseln stehe, weil Linienführungen und -benennungen geändert werden, versuche ich möglichst die Haltestellen aktuell zu halten. Wenn dort der aktuelle Haltestellenfahrplan verlinkt ist, ist es m.E. die sicherste Variante, um ÖPNV aktuell zu halten.

Es gibt zwar notes zu den falschen Relationen (Linienbezeichnung, Streckenführung) - vielleicht sollte man die Strecken-Relationen “stilllegen”, da sich hier niemand darum kümmert. Generell wäre es auch für die Verkehrsbetriebe doch eine Möglichkeit OpenStreetMap nicht nur als Hintergrund zu nutzen.

Hallo,
so ne Umstellung ist doch was feines, aber wie geri-oc schon schrieb, wäre es doch sehr sinnvoll die Haltestelle aktuell zu halten.
Ein Beispiel sind die Haltestellen in Eiterhagen: Da sind vom Tagging in einem doch eher schlechtem Zustand.

Hallo,

ja ich bin bei uns schon relativ gut beschäftigt… könnten hier auch Verstärkung vertragen.

Ich hab mal 3-4 Relationen angeklickt… die sein auch nicht alle recht “super”… und nur PTV1 bzw. eine Straßennode also noch nix hochtragendes… also da kann man sich schon ran trauen. :wink:

Eine Übersicht über die vorhanden Relationen wäre gut… und dann muss man eine Linie nach der anderen vergleichen und schauen wo was zu machen ist…

Ich hab dem auch schon ein Thema gewidmet:

Bus-Relationen Erstellungshilfe
https://forum.openstreetmap.org/viewtopic.php?id=61170

=> damit könnte auch eine “Laie” schon mal eine gewisse Vorarbeit leisten… Haltestellen zusammensuchen,… Routen, vergleichen… fehlendes feststellen und vermerken… usw.

MfG Miche

Ich hatte auch einmal begonnen die (Bus-)Stadtrouten zu korrigieren oder erstellen. Aber da das eine gewisse Zeit in Anspruch schmeißt der Fahrplanwechsel vieles wieder über den Haufen.

Deshalb war mein Vorschlag die Haltestellen in OSM aktuell zu halten. Welche Linie wohin und wann fährt ist an der Haltestelle verlinkt - bei uns sogar mit QR-Code. Dort sind dann auch aktuelle Fahrplan- und Routenänderungen abrufbar.

Sooo schlimm finde ich die Haltestelle “Eiterhagen” nicht…
Das “shelter=yes” muss raus, denn das shelter ist getrennt gemappt. Das “bus=yes” gehört eigentlich nur an Stops und nicht an Platforms … das ist aber streng genommen nicht falsch.

Die Haltestelle “Endstation Linie 37 - Eiterhagen” sieht schlechter aus. Der Name ist nicht plausibel und eine stop_position kann nicht neben dem Weg liegen. Aber ohne Besichtigung ist das schwer zu korrigieren.

Schlechter sieht es in den Routen aus: Wenn man bei einer Haltestelle sowohl stop als auch platform desselben Halts mappt (was man weder muss noch soll, aber darf) dann MUSS beides in die Route und das ist hier nicht so. Und noch einiges mehr…

Generell fallen mir in Kassel viele überflüssige stop_areas auf, die oft falsche Rollen haben: “label” gibt es nicht und stops und platforms müssen die Rollen “stop” bzw. “platform” haben. Die leere Rolle ist für public_transport=station and amenity=* da.

Ich hab eine Liste mit 1732 Fehlern und 1859 Warnungen für Kassel. Das Gebiet ist der großzügig begradigte Wahlkreis Kassel (Stand gestern). Ganz Hessen hab ich aber auch.). Falls die jemand haben will oder das erzeugende Programm (z.Zt. nur Linux, das Windows-Exe ist etwas älter und langsamer.) oder die Programmquellen: Mit E-Mail-Adresse Bescheid geben.

@Weide

Dein Programm wäre schon interessant… aber ich glaub des findet mir noch zu viele Fehler… Ich erfasse erst mal nach und nach erst mal so die nicht vorhandenen Relationen und überarbeite die vorhandenen. Dabei finde ich schon mehr als genug Fehler bzw. Fehlendes das ist mir Momentan schon viel genug. Auf dein Programm komme ich vielleicht später nochmal drauf zurück :wink:

mfg Miche

Hallo,

leider ist eine solche Verlinkung nur für Menschen nutzbar. Ich kann von einer ÖPNV-Karte nicht erwarten, ein verlinktes PDF zu parsen, um Informationen über die Linien zu erhalten, die eine Haltestelle bedienen. Die Routenrelationen haben somit einen echten Mehrwert und dürfen nicht verworfen werden. Darüber hinaus ist es natürlich sinnvoll und wichtig, auch die Haltestellen aktuell zu halten.

Ich habe angefangen, Ordnung in die Tram-Relationen zu bringen (fehlende Master-Routen ergänzt, Routen-Member geordnet und aussortiert, Typografie vereinheitlicht…) und schon mal die neue Linie 2 vollständig angelegt. In den nächsten Tagen und Wochen werde ich hier immer wieder einmal aufräumen und Änderungen des neuen Liniennnetzes übernehmen. Falls daran jemand anderes mitwirken möchte, freue ich mich sehr und schlage vor, zur Koordination eine Checkliste im Wiki o. Ä. anzulegen.

@Weide: Ich habe Interesse an der Fehlerliste. Spricht etwas dagegen, sie zu veröffentlichen?

Ich kann das Programm per E-Mail verschicken, wenn ich eine attachment-fähige E-Mail-Adresse habe.

Ich habe meine OSM-Homepage dicht gemacht…

Ich hab nichts dagegen … aber sie wäre doch sehr schnell veraltet. Da müsste man wohl täglich eine frische Fassung ins Netz stellen wenn man nicht alle nutzenden Mapper frustrieren will.

Zum Programm:

  • Ich verschicke eine direkt ausführbare Fassung für Linux, eine ebensolche für Windows und die Quellen. Das Ding ist freie Software (GPL). Jeder darf es ändern. Jeder darf es weitergeben aber dann nur mit allen Rechten und Möglichkeiten.

  • Es wertet nur PBF-Dateien aus. Es gibt mehrere Möglichkeiten, sowas zu bekommen. Z.B.:
    1: Ganz Hessen gibt es täglich frisch bei der Geofabrik als pbf
    2: Man macht aus der o.g. Hessen-Datei erstmal einen Ausschnitt mit osmosis und verfüttert dann nur den.
    3: Man testet nur das, was man gerade editiert hat. Mit dem PBF-Plugin kann man im JOSM PBFs zwischenspeichern und so sogar vor dem Upload testen.

  • Es hat keine graphische Oberfläche. Man wirft ein PBF rein und bekommt Textoutput.

  • Es kann PTv1 und PTv2 und stop_area_groups. (Dem widersprechende Wikis werden nicht berücksichtigt.)

  • Eigentlich hat das Programm garnicht den Zweck, Fehler zu suchen. :slight_smile: Ich hab es geschrieben, weil die Erzeugung von ÖPNV-Overlays z.B. für Garmingeräte extrem kompliziert ist. Das Programm kaut die Daten sozusagen vor. Es wird eine Pseudo-OSM-Datei erzeugt, bei der die Buslinien etc. als Tags an den Straßen, Haltestellen usw. stehen und die stop-areas als Flächen mit entsprechenden Tags dargestellt sind.

Das klingt alles in allem sehr gut, …

…vor allem das. Wie wäre es mit einem Github-Projekt? Ansonsten gerne per Mail an kai-l@gmx.de.

Ist unterwegs

Hallo,

ich habe mal eine IST-Analyse der in den Kreisen:

  • Kassel
  • Landkreis Kassel
  • Landkreis Werra-Meißner-Kreis
  • Landkreis Schwalm-Eder-Kreis
  • Landkreis Waldeck-Frankenberg
  • Landkreis Hersfeld-Rotenburg
    gemappten ÖPNV-Linien gemacht und dabei nach dem ‘network’ = “NVV” und ‘network’ = “Nordhessischer VerkehrsVerbund” und ‘network’ nicht gesetzt gefiltert.

Das Ergebiniss würde ich gerne (regelmäßig = täglich) updaten und ins OSM-Wiki stellen.

Ich schlage als “Ort” im Wiki:

wiki.openstreetmap.org/wiki/Kassel/Transportation/Analyse

vor. Gibt es andere Vorschläge für den Ort?

Aus der derzeitigen IST-Analyse läßt sich recht schnell eine SOLL-IST-Analyse machen.

N.B.: selbiges mache ich bereits für

Toni

Los geht’s :slight_smile:

Ich habe heute sämtliche Kasseler Tram-Linien auf Vordermann gebracht und aufs neue Liniennetz umgestellt.

Heute Abend gibt’s den ersten Wurf als IST-Analyse …

Hallo,

die Analyse des NVV is on-line:

Eine kurze Dokumentation gibt es hier:

Durch Editieren der folgenden Wiki page könnt Ihr daraus eine SOLL-IST-Analyse machen. Die Seite soll die Linien des NVV definieren, so wie sie in OSM erwartet werden. Im Idealfall kommen die Infos vom Verbund selber (copyright beachten), so wie beim MVV, VMS, VBN.

Als Beispiel wie man das strukturieren kann:

VG
Toni

Sieht gut aus :slight_smile:

Ein paar kleine Sachen sind mir aber aufgefallen:

'public_transport:version' is not set 

Steht bei “route_master” als Fehler und bei “route” als Anmerkung. Das würde ich umgekehrt sehen, denn “route_master” ist sowieso immer PTv2. Bei “route” ist die Unterscheidung dagegen sehr wichtig, denn gleiche Einträge haben da je nach Version eine andere Bedeutung.

PTv2 route: 'role' = 'stop' but 'public_transport' is not set
PTv2 route: 'role' = 'platform' but 'public_transport' is not set

‘public_transport’ muss nicht gesetzt sein. Man darf auch die klassischen Tags wie ‘highway=bus_stop’ statt dessen (oder damit zusammen) verwenden.
“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.”

Danke. Wenn Ihr die Linien-Datei (https://wiki.openstreetmap.org/wiki/Kassel/Transportation/Analyse/DE-HE-NVV-Linien) für die SOLL-IST-Analyse ausfüllt, wird die Ausgabe etwas kompakter. Und wenn alle Fehler korrigiert sind, wird es auch übersichtlicher.

Stimmt, ich werde das ändern.

Ja aber …

highway=bus_stop interessiert mich nicht, da die Analyse auf PTv2 ausgerichtet ist

  • dieses tag gehört nicht zum “PTv2-Standard” dazu
  • es kann aber co-existieren (stört nicht weiter)

public_transport=… ist zwar recommended

  • das Tool behandelt viele ‘recommended’ aber als ‘mandatory’
    ** https://wiki.openstreetmap.org/wiki/User_talk:ToniE/Transportation/Analyse#Abweichungen
  • ich könnte highway=bus_stop zwar als Ersatz nehmen, doch ist die “Position” dieses Tag (am Stop-Node oder am Platform-Node) nicht definiert
    ** ich kann aus higway=bus_stop nicht eindeutig public_transport=stop_position oder public_transport=platform herleiten, ohne weitere Daten zu analysieren (und selbst dann ist’s u.U. nicht immer eindeutig)
    ** “replace, deprecete or obsolte …”: die alten Tags können co-existieren, müssen nicht gelöscht werden, … sind aber nicht Teil des neuen Standards

Gruß
Toni

Koexistieren im Sinne von “stört nicht weiter” können die neuen Tags:
“The proposed tags can and do coexist with the well known tags. The usage of the new tags is recommended but not mandatory.”

Man kann schon das “recommended” als “mandatory” betrachten … aber das ändert nichts an der vollen Gültigkeit der alten Tags in PTv2.

In der Kompatibilitätstabelle steht es detailliert:

“highway=bus_stop beside a way/street where buses are allowed” is interpreted as “public_transport=platform”

“highway=bus_stop on a way/street where buses are allowed” interpreted as “public_transport=stop_position + bus=yes”

Die alten Haltestellentags sind voll und ganz Bestandteil von PTv2. Insbesondere liegen gemäß dem oben zitierten zwei PTv2-Platforms vor, wenn auf einer Linie mit public_transport=platform zusätzlich ein Node mit “highway=bus_stop” angelegt wird.

Akzeptiert.
Dann muss ich wohl noch ein wenig am Programm feilen … werde es aber trotzdem als Anmerkung “interpretiert …” ausgeben, wenn der Fall vorliegt.
Aber langfristig sollten wir wohl die neuen Tags voll unterstützen (ohne die alten zu löschen), um von den Ausnahmeregelungen (so sehe ich das “interpretiert”) weg zukommen.

Ich hoffe dass nicht beide gleichzeitig Member einer Relation sind.