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

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

Das sieht ja aus als hätte ne Bombe eingeschlagen. Aber ich trau mich nicht das zu reverten, weil ich nicht verstehe was da schief gelaufen ist und wie man es hätte anders machen können. Man muss dem Mapper ja auch irgendwas Konstruktives sagen…

Weide

Meine Vermutung ist, dass er veraltete Daten verwendet hat…

Same here, dazu kommt, dass ich noch nie etwas revertieren musste.
Bin grade leicht am verzeifeln :slight_smile:

Hallo,

Ja, da hat er bzw. iD den Konflikt falsch gelöst. Ich würde iD sogar zutrauen, einfach den Konflikt so zu lösen, dass er immer die lokale Version verwendet und die auf dem Server ignoriert.

Das Webinterface auf osm.org hat einen Timeout, weil das Abrufen der Versionsgeschichte dieser Relation zu lange dauert. Mit JOSM klappt es aber. Wenn man die Relation auswählt (sie wird dann rosa) und auf Ansicht → Chronik klickt, kann man sich schön die Differenzen zweier Versionen betrachten.

(Alle Zeiten in UTC) Die Version 70 von Mah vom 2. März 2016 00:36 basiert auf Version 57 vom 19. Januar 2016 15:58 (Version 58 wurde am 29. Februar 2016 13:18 hochgeladen). Sein Editor arbeitete also mit Daten von vor dem 29.2.2016 13:18! Entweder war da ein Browser-Tab tagelang offen oder der Benutzer verwendet nicht den iD von osm.org und sein iD bezieht die Daten nicht von der OSM-API oder es ist ein ganz böser Bug in iD (der ist ja dafür bekannt, gerne mal Schrott zu produzieren).

Ich befürworte einen harten Revert, d.h. Zurücksetzen auf Version 69. Dazu einfach das Reverter-Plugin verwenden und nachdem der Revert lokal abgeschlossen ist, nur die Relation auswählen und dann Datei → Auswahl hochladen. Danach die Datenebene löschen. Nach dem Revert schadet eine optische Prüfung (neuer Layer in JOSM, dort Daten herunterladen) nicht.

Viele Grüße

Michael

EDIT: hsimpson hat noch ein paar Details per PN erhalten, wie man revertiert

Ok ich hab jetzt zur sicherheit alle drei Relationen, an denen ich bisher gearbeitet hab zurückgesetzt und danach nochmal nachjustiert. Damit müsste das jetzt hoffentlich wieder gefixt sein.

Welches Schema sollte man für die bereits fertiggestellten, aber noch nicht in Betrieb genommenen Abschnitte der Nord-Süd-Stadtbahn verwenden?
Bisher wurde das railway=construction einfach beibehalten, was ich für falsch halte. Gestern habe ich teile davon im Zuge der gesamten Überarbeitung auf railway=light_rail umgeschrieben, aber inzwischen halte ich auch das für falsch, weil die Strecke durch massive Tore vor unbefugtem Zutritt geschützt wird.
railway=disused würde dem noch am ehesten nahekommen, aber kann man eine Strecke, die noch nie in Betrieb war als stillgelegt bezeichnen? :smiley: Und damit verschwindet meiner Meinung nach auch der Verweis auf die Absicht, die Strecke mit Abschluss der Bauarbeiten am Waidmarkt freizugeben. Ich kann mir auch vostellen, dass die Betriebsgenehmigung für die Strecke schon vorliegt.
Viele Grüße

Was stört dich an costruction?
Papierkrieg gehört zu sowas genauso wie Hardware.

Dass die Bauarbeiten seit Jahren abgeschlossen sind und die Strecke betriebsbereit ist.

Die Relations-Links für die Straßenbahnen in https://wiki.openstreetmap.org/wiki/VRS#Stadtbahnen_.2F_Stra.C3.9Fenbahnen_.2F_U-Bahnen funktionieren jetzt wieder.
Dazu habe ich das DisplayRoute-Template um den optionalen Parameter “type=route_master” erweitert.

Danke!

Ich bin inzwischen jetzt fertig mit dem Überarbeiten der linksrheinischen Strecken. Damit konnte ich auch die Routen der Linien, die nicht den Rhein queren, komplettieren (also die 5, 12, 15, 16 und 17).

Folgende Sachen sind mir dabei noch aufgefallen, wo ich alleine nicht weiter komme:
-Bei den Linien 3 und 4 fehlen zwischen “Hans-Böckler-Platz/Bf. West” und “Bocklemünd” nahezu alle Bahnsteige und die Bahnsteigzugänge incl. Zwischengeschosse. Bei Bing ist nix erkennbar, da im Tunnel oder unter Bäumen (Hab mich schön öfter gefragt, warum bing nicht mal im Winter Fotos macht).

  • Bei den Linien 1 und 7 ist die Situation zwischen den Haltestellen Moltkestraße und Rudolfplatz noch nicht ganz optimal. Die Schienen liegen Straßenbündig auf einer eigenen Spur, die auch von zwei Buslinien befahren wird. Diese Halten auch an den Haltestellen der Stadtbahn. Im Moment sind die Buslinien doppelt gemappt: Zum einen auf den Schienen, die hierfür um Straßen-tags erweitert wurden und zum anderen auf der eigentlichen Straße. Meiner Meinung nach ist das erweitern der Schienen um Straßen-tags schon falsch, da meist keine bauliche Trennung vorliegt. Allerdings bekommt man dann Probleme mit den Haltestellen…

Grüße

Bei der Linie 15 hat die Route eine Verzweigung drin. Das ist aber in PTv2 nicht zulässig. Für die Fahrten zur Longericher Straße sollte ein extra Routenpaar erstellt werden.

Die uic_ref ist eine 7-stellig UIC-Bahnhofs-Nummer und NICHT identisch mit der VRS-Nummer.
Die ref:ibnr ist eine 6-stellige (Bus-)Haltestellen-Nummer und NICHT identisch mit der VRS-Nummer.

Zur Auffindbarkeit einer Haltestelle unter Bahn.de bzw openptmap.de ist es sinnvoll, wenn vorhanden die uic_ref (7-stellig) einzutragen, oder unter ref_name die bahnspezifische Bezeichnung zu verwenden. Beispiel name="Kinderkrankenhaus= an der Linie 16 ref_name=“Riehl Kinderkrankenhaus, Köln”.

Stimmt das wollte ich noch gemacht haben :slight_smile:
Ist jetzt korrekt.
Grüße

Bis auf die Linie 1, 7 und 9 ist jetzt alles umgestellt.
Man könnte sich als nächsten Schritt den Liniennetzplan der KVB vornehmen und schauen, ob überall, wo da das kleine Rollstuhlsymbol eingezeichnet ist bei uns auch ein wheelchair=yes steht. Nur so als Anregung :wink:
Grüße!