[Köln]: Stadtbahn/ÖPNV: Aufräumen, Verbessern, Aktualisieren

Hui, das ist aber ne ordentliche Mängelliste :slight_smile:
Ich denke das ist ziemlich nützlich, danke dafür!

Es gibt doch gar keine Registrierung … man nimmt doch den OSM-Account. Oder liege ich da falsch?

Weide

Danke für den Tipp.
Irgendwie war ich überzeugt, auch für das OSM-Forum einen separaten Account zu benötigen.

Grüße Martin

Hallo hsimpson,

danke für den Hinweis auf diesen Forumsbeitrag.

Da bin ich sehr leidenschaftslos und möchte das richtige Tagging [tm] den Railmappern überlassen :slight_smile:

Erwähnte ich schonmal irgendwo, dass ich mit Linienrelationen ein bisschen auf Kriegsfuß stehe?

Da kann ich gerne mithelfen bei meinen Streifzügen durch Köln.

Da habe ich schon viel Zeit investiert, zumindest in der Innenstadt. Werde ich aber auch gerne verstärkt drauf achten.

Zu allen anderen Punkten überlasse ich Statements den Kundigeren :slight_smile:

Ich hab mich bemüht, es nützlich zu machen. Aber man hat da auch schwer mit Folgefehlern zu tun. Wenn z.B. bei einer Route nicht klar ist, nach welchen Regeln sie interpretiert werden soll, dann steht das da als Fehlermeldung und sie wird ignoriert. So weit so gut. Aber das kann natürlich dazu führen, dass 20 Haltestellen als verdächtig eingestuft werden weil da nichts hält.

Auch ziemlich häufig ist der Fall, dass ein PTv2-Relation als PTv1 getaggt ist: Dann wird für jedes Stück Einbahnstraße gemeldet, dass der Busfahrer als Geisterfahrer unterwegs ist.

bis dann
Weide

Hallo zusammen,

aufgrund der teilweise lückenhaften Daten habe ich vor einigen Wochen einfach angefangen mit dem Ergänzen von fehlenden Gleisen.
Inzwischen passe ich auch die Relationen der KVB-Linien entsprechend an, damit die Bahnen die neuen Gleise auch benutzten.
Für die KVB-Bahn-Linien 1 bis 5 sollten die Gleise inzwischen vollständig sein.

Für die KVB-Linie_12 habe ich zwar schon die fehlenden Gleise nachgetragen, jedoch mich noch nicht daran getraut die gemeinsame Relation für beide Fahrtrichtungen in seperate Relationen je Fahrtrichtung aufzuteilen.

Das Mängellisten-Tool von “Weide” halte auch ich für eine sehr gute Hilfe.
Die Mängelliste ist jedoch so lang, so das man kaum weiß, wo man anfangen soll.

Da die Datensätze der KVB-Linie_1 schon recht gut aufgeräumt sind, habe ich mir mal die Relationen hiervon vorgenommen und versucht alle vom Tool gefundenen Mängel zu beseitigten. Also ca 5 Zeilen der 8.261 Zeilen könnten schon abgearbeitet sein.

Eine Liste der KVB-Linien wie https://wiki.openstreetmap.org/wiki/VRS (scheint leider veraltet zu sein), fände ich ganz gut, um den Überblick zu behalten, was noch zu tun ist, und was bereits erledigt ist.

Viele Grüße
Martin

Ich würde sagen, es ist am einfachsten, die Liste wieder zu aktivieren (dafür wurde sie ja gemacht).
So ganz Stillgelegt ist sie ja auch noch nicht, z.B. wurde National Express als Betreiber schon eingetragen, aber neue Linien wie die S19 oder die Linie 17 fehlen noch ganz. Und die meisten verlinkten Relationen wurden inzwischen gelöscht.

Hab mal mit den ersten Einträgen angefangen und die Definition von 100%(+) auf die korrekte Anwendung von PTv2 incl. richtiger Reihenfolge geändert. Das hat dazu geführt, dass ich bei allen Bonner Linien das Plus wegnehmen musste, aber die Verlinkten Relationen sind inzwischen eh alle wieder gelöscht.

Die Anleitung für die Relationen ist inzwischen auch veraltet, Weide, am liebsten würde ich da einfach auf deine Wiki Seite verlinken, wenn du nix dagegen hast. Da steht alles drauf, was man brauchen sollte :wink:

Viele Grüße

Hallo zusammen,

ich wollte gerade die Relation-Ids für die KVB-Bahnen in der Tabelle https://wiki.openstreetmap.org/wiki/VRS aktualisieren, und durfte dabei feststellen, das diese gar nicht im Wiki-Quelltext enthalten sind. Dafür steht folgendes drin; was ich übrigens für besser halte.

Es scheint eine Art Abfrage anhand von “network” und “ref” zu sein.

Leider verstehe ich zur Zeit noch nicht, warum es für die Linie_1 scheitert, und für die Linie_9 funktioniert.
Hat jemand eine Idee, und könnte Hilfen die Links auf die Relationen zu reparieren.

Grüße Martin

Hallo,

zum Thema railway=*:

Das Problem stellt sich ja nicht nur in Köln, sondern auch beim Erzfeind, der auch ein ähnlich heterogenes BOStrab-Netz hat – Düsseldorf mit seinen Ausläufern nach Neuss und Krefeld. Benutzer rurseekatze hat am Wochenede begonnen, Teile des Netzes umzutaggen. (Ich habe beratende mitgewirkt und meinen Senf dazu gegeben)

Wenn längere Abschnitte einen eigenen Gleiskörper haben, haben sie railway=light_rail bekommen. Wenn in diesen Abschnitten sich die Bahn auf kurzen Stücken den Raum mit dem Individualverkehr geteilt hat, wurde das ignoriert. Er hat mit der K-Bahn (Krefeld–Meerbusch–Düsseldorf) begonnen, sie zweigleisig gemacht (vorher war nur ein Gleis gemappt) und sie mit railway=light_rail getaggt.

Ab morgen früh (Update jede Nacht) könnt auf der OpenRailwayMap farblich schön die Unterschiede erkennen. Wer es eiliger hat, nimmt diese gestylte Overpass-Abfrage: http://overpass-turbo.eu/s/eGv

Aber zurück zu Köln: Die Strecke in der Luxemburger Straße würde ich durchgehend vom Übergang zur EBO-Strecke am Sülzgürtel bis hin zum Beginn des Tunnels nordöstlich des Barbarossaplatzes als light_rail taggen. Zwar fährt die Bahn im Bereich des Südbahnhofs kurz auf der Straße, aber das hat wohl einfach räumliche Gründe (der Neubau einer alten Bahnunterführung ist teuer). Auch den Tunnel würde ich als light_rail taggen, denn für eine subway sollte schon das ganze Netz frei von höhengleichen Kreuzungen sein (also entweder im Tunnel oder aufgeständert).

Die Linie 12 zum Südfriedhof fährt hingegen auf der gesamten Strecke von der Eifelstraße bis zur Endhaltestelle am Südfriedhof auf der Fahrbahn. Hier ist eindeutig tram richtig. An der Kreuzung Eifelstraße/Sachsenring ist dann der Übergang von tram zu light_rail, da die Strecke Barbarossaplatz–Überring eben ihren eigenen Gleiskörper hat.

Viele Grüße

Michael

Das ist ein Aufruf des Templates DisplayRoute. Mehr Infos: https://wiki.openstreetmap.org/wiki/Template:DisplayRoute

Gibt es eig eine Datenbank, wo man die VRS:ref der Haltestellen her bekommen kann?
Und ich würde gerne die UIC_ref und UIC_name einführen, damit das ganze auch überregional kompatibel wird.
Sind im VRS die VRS:ref zufällig auch die UIC_ref, oder haben die ihr eigenes System?
Und wo bekommt man diese Daten her?

Mir ist auch schon aufgefallen, dass da bei den Stadtbahnen etwas kaputt ist.
Machs einfach wie bei den Bussen: {{Relation|909176}} Das funktioniert.

Grüße

Also dem zufolge würde ich jetzt folgende Strecken als tram einstufen (bitte um Korrekturen):

  • evlt Linie 3 auf der Heidelberger und Karlsruher Straße
  • evtl Linie 4 Berliner Straße (im Vergleich sehr kurzer Abschnitt und keine Haltestelle in diesem Abschnitt)
  • Linie 5 Nußbaumerstraße bis Margaretastraße, evtl auch der Teil zwischen Ehrefeldgürtel und Eisenbahnunterführung.
  • Linie 7 auf der Dürener und der Siegburger Straße ab dem Poller Kirchweg
  • Linie 9 ab Abzweig Neumarkt komplett bis Sülz Endhaltestelle
  • Linie 12 ab Eifelstraße bis Endhaltestelle Zollstock
  • evtl (im Regelbetrieb nicht mehr genutzte) Schleife der Linie 13 auf der Neuenhöfer Alle und der Berrenrather Straße
  • ganz vlt Linie 1+9 im Bereich Moltkestraße-Rudolfplatz

Insgesamt aber erstaumlich, wie die Kölner es geschafft haben, den Bahnverkehr vom individualverkehr zu trennen und trotzdem eine reht hohe Netzdichte zu erhalten.

uic_ref=* heißt bei der DB EVA-Nummer. Für die Stationen, zu denen eine durchgehende Tarifierung (TBNE-Tarif) möglich ist (die meisten Vollbahnen und zahlreiche Haltestellen, wo Eisenbahnzüge auf BOStrab-Strecken fahren), findest du sie im Datensatz “Haltestellen” im Open-Data-Portal der DB: http://data.deutschebahn.com/datasets/haltestellen/

VRS:ref stammt wie alle VRS:* aus dem VRS-Import von vor ein paar Jahren. Ich meine auf der Bonner Mailingliste gelesen zu haben, dass ein VRS-Vertreter vor ein paar Monaten mal am Stammtisch war. (Btw, diese Liste ist auch für Köln zuständig) Der VRS ist recht OSM-freundlich.

EDIT: Korrektur entsprechend http://data.deutschebahn.com/datasets/haltestellen/#comment-2517526006

Wenn ich mich von Öffi im Netzwerk Deutschland zum Ebertplatz navigieren lasse, dann greift Öffi meines Wissens auf die HAFAS Datenbank zurück. Folglich müsste HAFAS auch eine (vermitlich EVA-) Nummer für den Ebertplatz besitzen und das System ist offen, heißt von dritten zugänglich. Folglich müsste es doch auch EVA-Nummern von nicht-DB Stationen geben und irgendwie zugänglich sein, oder ?
Oder welches Nummern nutzt HAFAS für nicht-DB stationen?

Wenn da räumlich der Platz für ein eigenes Gleisbett vorhanden wäre (als Option eines zukünftigen Ausbaus), würde ich railway=tram taggen. Ansonsten railway=light_rail. Die paar Mapillary-Bilder und die belaubten NRW-Atlas-Bilder lassen diesen Schluss zu. Bloß in den Eisenbahnunterführungen könnte es eng werden. Aber IMHO sollte eine light_rail schon mal kurze Stücke auf der Straße fahren, wenn die Baukosten das rechtfertigen.

dto. Bei einem Umbau dürften aber die Parkmöglichkeiten für Kfz auf der rechten Spur verloren gehen.

Ja, eindeutig.

dto.

Ja, ebenso. Das letzte Stück vor der Endhaltestelle hat zwar einen eigenen Gleiskörper, aber der ist recht kurz und rechtfertigt keine Wechsel.

siehe mein Posting weiter oben

Ja, ebenso tram. Diese Blockumfahrung kann man als eigenständige Strecke betrachten, daher darf er im Tagging von der Umgebung abweichen.

Ja. Zwar fahren keine Pkw laut NRW-Atlas auf der “Straßenbahnspur”, aber sie ist befestigt und Pkw, die die schrägen Stellplätze auf der jeweils linken Straßenseite erreichen wollen, müssen das Gleis kreuzen. Ich kann mir vorstellen, ohne Ortskenntnis zu haben, dass Falschparker (2. Reihe oder Pkw, die “den Arsch raus hängen”) dort gerne mal für Verspätungen sorgen. Mit der westlichen Kriegsstraße (zwischen Weinbrennerplatz und Kühler Krug haben wir so etwas auch in Karlsruhe, aber dort fährt im Regelbetrieb nur alle 10 Min. eine Bahn)

Viele Grüße

Michael

Na dann mach ich mich die Tage mal ans mappen.
Zum Glück kann man bei JOSM gleichzeitig von mehreren Objekten die values ändern :slight_smile:
Btw, mir ist als hätte ich letztlich bei JOSM was von overpass-turbo gelesen. Gibts da ne Möglichkeit, über turbo ne abfrage zu erstellen und dann nur die Objekte der Abfrage (z.B. nur mit railway=tram) in JOSM zu laden? Dann könnte man das nämlich direkt in einem klick für ein ganze Gebiet ändern :slight_smile:

Du kannst aus dem Overpass-Turbo heraus die JOSM-Fernsteuerung (Export → JOSM) nutzen oder von JOSM heraus Abfragen stellen.

Bitte ändere aber nicht mit einem Klick ein ganzes Gebiet. Es schadet nicht, die Gleise etwas genau anzuschauen. Du wirst Fehler entdecken und sie beheben. Beim blinden Umtaggen würdest du keine Fehler entdecken. Es wäre ein mechanischer Edit. (Das hier ist zwar eine Diskussion dazu, aber dann wäre der Titel der Diskussion falsch)

http://wiki.openstreetmap.org/wiki/What’s_the_problem_with_mechanical_edits%3F

Da ich die Verwendung des Templates DisplayRoute besser finde als die direkte Angabe der RelationsId, würde ich das Bestehende gerne wieder ans Laufen bringen.

Inzwischen habe ich herausgefunden, das die Abfrage mit “network=VRS und ref=1” drei anstelle von einer Relation ergab, und somit natürlich nicht angezeigt werden konnte. Ursache war, das nicht nur der route_master, sondern auch die beiden Fahrtrichtungen mit “network” und “ref” getagt waren.

Damit nur jeweils eine Relation gefunden wird, habe ich in den Link zusätzlich noch “type=route_master” als Bedingung eingefügt. Leider ohne Besserung.
Erst nachdem ich (zum Testen) aus den beiden Fahrtrichtungen der Linie_1 des Tag “network” entfernt hatte, funktioniert der Link wieder.

Fragen:

  1. Ist ein Aufruf des Templates DisplayRoute mit Angabe von “type=route_master” invalid, oder warum wird die Erweiterung nicht berücksichtigt ?

  2. Gehört das Tag “network” in die Relationen der beiden Fahrtrichtungen, oder nur in den RouteMaster rein ?

Grüße Martin

Kann sich das hier mal wer ansehen?
Mir wurde eben eine komplette Relation in einem Änderungssatz zurückgesetzt, der allerdings deutlich nach meiner letzten Bearbeitung entstanden ist.
http://www.openstreetmap.org/changeset/37557906
Geht im Wesentlichen um diese Relation: http://www.openstreetmap.org/relation/1366478#map=15/50.9650/6.9695&layers=N