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):
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 
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
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:
Ist ein Aufruf des Templates DisplayRoute mit Angabe von “type=route_master” invalid, oder warum wird die Erweiterung nicht berücksichtigt ?
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 
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? 
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).
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.