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

Mein Vorschlag:

mit anderen ÖPVN-Mapper in Kontakt treten:
VRN: https://wiki.openstreetmap.org/wiki/Ver … ein-Neckar
Mentz: https://wiki.openstreetmap.org/wiki/MENTZ_GmbH

WIKI-Projekt: https://wiki.openstreetmap.org/wiki/Wik … Nahverkehr

Dazu hatte ich hier schonmal etwas geschrieben.
Allerdings wäre meiner Ansicht nach in Köln wohl route=tram auch für die 7, 16, 18 und 68 die richtige Wahl, die Eisenbahnanteile sind z.B. im Vergleich zu Karlsruhe so gering, dass ich sie aus Gründen der Einheitlichkeit vernachlässigen würde.

Schön, dass mal jemand um die vernachlässigte Kölner Stadtbahninfrastruktur kümmern will.

hsimpson wrote:

Hallo zusammen!

Ich bin noch ein recht neuer Mapper, der sich grade die Tiefen des Straßen und ÖPNV-Mappings aneignet.
Seit einiger Zeit bin ich auch regelmäßig in Köln unterwegs und musste feststellen, dass das ÖPNV-Bild auf OSM noch einige Lücken aufweist. Der Wiki-Eintrag vom VRS ist auch seit fünf Jahren nicht mehr aktualisiert worden.

Einige Punkte, die mir in letzter Zeit aufgefallen sind:

Stadtbahn:
- Chaos in den Werten für railway=*: oberirisch meist tram, unterirdisch vollkommen wahrlos mal tram und mal subway. Bei den Linien-Realtionen sind alle Niederflur als Tram und alle Hochflur als Subway getaggt. Das führt dazu, dass Subway-Relationen Tram-Strecken liegen und umgekehrt.

Da hast du Recht. Noch immer sind Teile (es waren mal mehr) als railway=subway getaggt, was ich als falsch empfinde. Auch wenn die Strecken zum Teil im Untergrund liegen, sind es noch keine U-Bahnen. U-Bahnen haben nämlich keine höhengleichen Kreuzungen mit dem Individualverkehr. Wenn sie diese jedoch habe – und das ist bei den oberirdischen Abschnitten in Köln der Fall – dann sind es Stadtbahnen (railway=light_rail).

Wo die Stadtbahn auf Eisenbahnstrecken fährt, würde ich die Infrastruktur genauer anschauen. Wo andere Eisenbahnzüge die Infrastruktur mit benutzen, ist railway=rail richtig. Wo sie es nicht können, weil der Gleismittenabstand zu gering ist und/oder das Lichtraumprofil es nicht hergibt (z.B. wegen Bahnsteigen, die ins Lichtraumprofil ragen), ist es railway=light_rail + workrules=DE:EBO.

Die Niederflurbahnen sind etwas tricky. Die muss ich mir erst mal noch auf Mapillary anschauen. Ich bin zwar schon in Köln mit der Stadtbahn gefahren, aber das war bislang recht wenig (und ist größtenteils 5 1/2 Jahre her und war vor meiner Zeit als Mapper). Wenn ihr Gleiskörper überwiegend vom Straßenverkehr getrennt ist (höhengleiche Kreuzungen sind weiterhin möglich und zahlreich vorhanden) und es an fast allen Stationen richtige Bahnsteige gibt [1], wäre IMHO railway=light_rail korrekt. Hochflurigkeit ist ein starkes Argument für Stadtbahn und gegen Straßenbahn, aber Niederflurigkeit ist noch lange kein Argument gegen eine Stadtbahn. Niederflurigkeit ist heutzutage einfach modern, weil man billiger Bahnsteige bauen kann (Hochflurbahnsteige brauchen mehr Platz, u.a. für die Rampen zum Bahnsteig hoch) und auch bei Platzmangel barrierfreie Einstiege realisieren kann.

hsimpson wrote:

- Linienrelationen im Tagging veraltet und Namensgebung nicht einheitlich.

Das ist in mancher anderen Stadt auch noch so.

hsimpson wrote:

- Strecken ungenau gemappt, vor allem bei den Linie 3-5 nur ein Gleis wo zwei liegen, bzw Gleise in die Straßen reingemalt. Dazu fehlen haufenweise Gleiswechsel (ist aber erstmal nebensächlich) Problem hier: Bing-Bilder sind meist nicht hilfreich, da Tunnelstrecken oder durch Bäume verdeckt.

Wenn es keinen bahnaffinien Mapper vor Ort gibt, ist das die Konsequenz. (Ich komme aus Karlsruhe und bin einer von min. zwei Bahnaffinen. Bei uns sind schon die Signale und Weichennummern gemappt)

hsimpson wrote:

- Sehr viele Lücken im Netz. Allerdings sind zumindest die meisten Haltestellen eingetragen, wodurch das mappen zusammen mit den aktuellen Liniennetzplänen weitestgehend möglich ist.

Gab es nicht mal einen VRS-Import? Vielleicht mal nachfragen, ob man euch eine aktuelle Liste geben will, die man dann Stück für Stück arbeitet (Vorsicht, die Koordinaten dieser Listen sind u.U. mit OSM rechtlich inkompatibel bzw. ungenau).

hsimpson wrote:

Mein wesentlicher Punkt, über den ich hier diskutieren möchte ist ein einheitliches Schema für die Stadtbahn Köln. Meiner Ansicht nach ist eine Unterscheidung zwischen Hoch- und Niederflurnetz genau so falsch wie zwischen unter- und überirdisch, da hier das Prinzip gelten sollte "ein System = ein Schema".

Das beißt sich aber mit der Heterogenität von Netzen wie dem Kölner, das teils unter-, teils oberidisch, teils in der Straße, teils mit eigenem Gleiskörper, teils Hoch- und teils Niederflur ist.

hsimpson wrote:

Nach dem englischen Wiki wäre light_rail eigentlich das naheliegenste Schema, allerdings wird dieses in Deutschland für S-Bahnen verwendet.
Folglich bleiben noch tram und subway als option, wobei ich eher für tram wäre, da dies mehr der Entstehungsgeschichte des heutigen Systems Rechnung trägt (Innenstadttunnel wurde urgsprünglich als "Unterpflasterstraßenbahn" geplant und gebaut) und man auf den Straßenbündigen Außenästen schlecht eine subway auf die Straße klatschen kann.

Meinst du Routenrelationen oder die Infrastruktur? route=light_rail gibt es in PTv2 nicht mehr. Deshalb ist route=tram richtig.

Für S-Bahnen (ausgenommen Karlsruhe, das die Marke S-Bahn auch verwendet) ist route/railway=light_rail falsch, da es sich um Vollbahnsysteme auf Vollbahninfrastruktur (ggf. komische Stromzuführung, die alles bloß teurer macht) handelt.

Einzige Ausnahme sollten die EBO-Strecken nach Frechen und Bonn bleiben, da hier ein Systemwechsel stattfindet. Diese sind bereits jetzt als train gemappt.

hsimpson wrote:

Ich werde jedoch nix dergleichen angehen, ohne mich vorher über das Vorgehen abzustimmen, sonst investiere ich hier haufenweise Arbeit rein und der nächste ändert das wieder zurück.

Des weiteren würde ich gerne die Strecken genauer mappen (s.o.), hierbei fehlen mir jedoch die Daten. Wenn mir hier jemand aushelfen kann wäre ich sehr dankbar.

Mein Tipp lautet Mapillary. Und wenn das nicht vorhanden ist: Selber machen. Ich bin im Mai/Juni 2015 große Teile des Karlsruher Straßenbahnnetzes abgefahren und habe durch die Heckscheibe hindurch (wir haben Einrichtungsfahrzeuge) Bilder gemacht. Wenn du eine etwas längere Brennweite als ein Handy hast, kannst du auch durch einen Füherstand hindurch Bilder machen. (Das habe ich neulich zwischen Karlsruhe und Rastatt gemacht). Mai bis Juli sind dafür besonders gut, da die Sonne recht hoch steht (weniger schlimmes Gegenlicht) und der Tag recht lang ist (mein billiges Semesterticket gilt Mo.-Fr. erst ab 18:00 Uhr).

Viele Grüße

Michael

[1] Kein Aussteigen auf der Straße, wie das z.B. noch in vielen ostdeutschen Städten (Halle, Magdeburg) noch verbreitet ist (Karlsruhe hat das auch noch an min. drei Haltestellen).

Hi hsimpson,
ich finde es gut, dass Du das Thema angehst. Und gerne helfe ich mit bei der Umsetzung. Wegen der Richtlinien solltest Du unbedingt in die Verteilerliste der openrailwaymap.org gehen. Dort sind vor einigen Wochen auch Straßenbahnrichtlinien begonnen worden, erste Vorlagen für JOSM sind auch schon da.

Eine eigene Meinung habe ich nur eingeschränkt. Es sollte nur eine Richtung für ein konsistentes Schema geben. Die wirklich aktiven Eisenbahn- und ÖPNV-Mapper nutzen in NRW das Public Transport Schema II und die erwähnten openrailway-Standards.

Tipp: Openrailwaymap mailing list -->
Openrailwaymap@openrailwaymap.org
http://lists.openrailwaymap.org/lists/l … railwaymap
(ok, eben hat sich "Nakaner" schon selber gemeldet)

Mein Schwerpunkt liegt auf Signalisierung / Beschilderung und ab und zu aktualisiere ich auch Relationen und so'n Kram mit. Innerhalb Kölns bin ich fast nur in der Nordostecke und via Bahn unterwegs (Linien 3,13,18,1,(4)).

Eine Meinung hab ich noch: Bei den neueren U-Strecken (Mülheim 13/18 inkl. Brücke, Deutz-Kalk 1/9 ohne Brücke, Nord-Süd-Bahn) finde ich "subway" auf den Gleisen passend, denn sie sind (fast?) durchgängig zügig und in enger Folge zu befahren und sie sind, soweit mir bekannt, kreuzungsfrei angelegt.
Mit einer Divergenz zwischen Routen (Linien) und Infrastruktur kann ich leben, das entspricht ja der Realität ;-).

Schöne Grüße
ohligser

Falls Ihr da was machen wollt: Ich hab mal auf http://gafte.de/koeln.err und http://gafte.de/koeln.stops zwei Textdateien gelegt (am Besten speichern und per Texteditor ansehen) mit einer Fehlerliste und einer Haltestellenliste. OSM-Stand ist von gestern Abend.

frohes Mappen
Weide

PS: Falls Ihr das brauchen könnt, kann ich auch gelegentlich Updates machen. (Kann man mit dem da rumliegenden Programm putr auch selbst machen)

Danke für die schellen Rückmeldungen!

Zum Newsletter habe ich mich eben angemeldet.

Nakaner wrote:

Wo die Stadtbahn auf Eisenbahnstrecken fährt, würde ich die Infrastruktur genauer anschauen. Wo andere Eisenbahnzüge die Infrastruktur mit benutzen, ist railway=rail richtig. Wo sie es nicht können, weil der Gleismittenabstand zu gering ist und/oder das Lichtraumprofil es nicht hergibt (z.B. wegen Bahnsteigen, die ins Lichtraumprofil ragen), ist es railway=light_rail + workrules=DE:EBO.

Auf den EBO-Stracken wird parralleler Güterverkehr meist von der HGK betrieben (bzw. behält sich die HGK zumindest das Recht vor, dort Güterverkehr durchzuführen, etwa zwischen Wesseling und Bonn). Das führt z.B. dazu, dass auf der Strecke nach Bonn keine Hochbahnsteige gebaut werden können, da diese in das Lichtraumprofil der Güterzüge reichen würden. Auf der Strecke nach Frechen ist das kein Problem, da dort Niederflurwagen fahren.

Generell haben die Nieder- und Hochflurwagen die selben Abmessungen und die neuen Baureihen sind sogar untereinander Verwand, da nach dem Versagen des Prototypes von Siemens eine Bestellung Niederflurwagen von Bombardier einfach in Hochflurwagen umgestellt wurde. Folglich sind die Niederflurwagen auch breiter als die klassischen Straßenbahnwagen, was allerdings bei den alten Düwag auch schon der Fall war.

Das Niederflurnetz ist inzwischen Flächendeckend mit 35cm Bahnsteigen ausgestattet, im Hochflur Netz gibt es durch Überschneidungen mit Niederflur und weil der Ausbau noch nicht fertig ist, auch noch 35cm Bahnsteige. Aussteigen auf die Straße ist aber inzwischen Geschichte (Die neuen Hochflurwagen haben deswegen auch nur noch Stufen bis 35cm).

Sowohl bei Hoch- als auch bei Niederflur gibt es sowohl Tunnelstrecken, als auch Strecken mit eigenem oder besonderem Bahnkörper, EBO-Strecken und klassische Straßenbahnstrecken, was bedeutet, dass die einzige Unterscheidung, die man zwischen den beiden Netzen treffen kann, die Einstiegshöhe ist.

Nakaner wrote:

Das beißt sich aber mit der Heterogenität von Netzen wie dem Kölner, das teils unter-, teils oberidisch, teils in der Straße, teils mit eigenem Gleiskörper, teils Hoch- und teils Niederflur ist.

Meiner Ansicht nach ist es doch genau diese Eigenschaft, die das System "Stadtbahn" von anderen Systemen abgrenzt.

Nakaner wrote:

route=light_rail gibt es in PTv2 nicht mehr. Deshalb ist route=tram richtig.

Aha das war mir noch nicht bekannt. Was sind die Gründe dafür? Wenn man ein light_rail System hat muss es doch auch light_rail Routen geben, oder nicht?

Also in Rhein-Main gibt es noch vereinzelt light_rail Routen, in Berlin und Hamburg ist die komplette S-Bahn light_rail und in Stuttgart die komplette Stadtbahn...
Eig hatte ich wegen Berlin und Hamburg Bedenken, das Natz auf light_rail umzustellen, da zwei verschidenene Systeme im selben Land mit den selben Tags noch unsinniger ist und es nicht absehbar ist, dass die Berliner und Hamburger ihre Natze umzeichnen. Dann hab ich aber gesehen, dass das in Stuttgart schon flächendecken eigesetzt wird, von daher...

Nakaner wrote:

Mein Tipp lautet Mapillary.

Ist leider in Köln noch lange nicht Flächendeckend. Und ich bin auch nicht oft genug in Köln, dass ich Zeit hätte, das komplette Netz abzufahren...

bjoern262 wrote:

Allerdings wäre meiner Ansicht nach in Köln wohl route=tram auch für die 7, 16, 18 und 68 die richtige Wahl, die Eisenbahnanteile sind z.B. im Vergleich zu Karlsruhe so gering, dass ich sie aus Gründen der Einheitlichkeit vernachlässigen würde.

Hier wird es noch komplizierter, die Bonner nutzen nämlich auch subway für ihre Hochflur-Routen. Heißt muss sich vorher mit noch einer Community abstimmen wenn man das angehen will.

ohligser wrote:

Bei den neueren U-Strecken (Mülheim 13/18 inkl. Brücke, Deutz-Kalk 1/9 ohne Brücke, Nord-Süd-Bahn) finde ich "subway" auf den Gleisen passend, denn sie sind (fast?) durchgängig zügig und in enger Folge zu befahren und sie sind, soweit mir bekannt, kreuzungsfrei angelegt.

Bin immer noch für "ein Netz = ein Schema" 😉 Viele der Strecken sind ja trotz allem an vielen Stellen mit dem historischem Netz verknüpft. So fädelt die Linie 5 z.B. am Dom höhengleich aus der Nord-Süd Stadtbahn aus und dann direkt wieder höhengleich in den Innenstadttunnel ein, weil dieser Teil noch eine Vorleistung aus den 50ern war.
Und ich meine die Stichstrecke an der Deutz-Kalker-Straße fädelt auch höhenfrei in die Tunnelstrecke ein. Hier gab es zumindest früher auch mal Linienbetrieb.

Ich bin außerdem noch mit dem Mapper Martin2009 in Kontakt getreten, der ist auch wie ich grade dabei, sich die Tiefen des ÖPNV-mappings anzueignen und sehr viel in Köln aktiv. Allerdings kann er sich nicht hier im Forum registrieren ("This forum is not accepting new registrations.").
Ihm ist wohl noch empfohlen worden, sich an die Social Media Abteilung der KVB zu wenden mit der Bitte um aktuelle Gleispläne und die Berechtigung, diese für OSM zu verwenden.

Alles in allem bin ich inzwischen versucht, das Netz komplett auf railway=ligh_trail umzustellen und die Relationen auf route=tram.

Weide wrote:

Falls Ihr da was machen wollt: Ich hab mal auf http://gafte.de/koeln.err und http://gafte.de/koeln.stops zwei Textdateien gelegt (am Besten speichern und per Texteditor ansehen) mit einer Fehlerliste und einer Haltestellenliste. OSM-Stand ist von gestern Abend.

frohes Mappen
Weide

PS: Falls Ihr das brauchen könnt, kann ich auch gelegentlich Updates machen. (Kann man mit dem da rumliegenden Programm putr auch selbst machen)

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

hsimpson wrote:

Ich bin außerdem noch mit dem Mapper Martin2009 in Kontakt getreten, der ist auch wie ich grade dabei, sich die Tiefen des ÖPNV-mappings anzueignen und sehr viel in Köln aktiv. Allerdings kann er sich nicht hier im Forum registrieren ("This forum is not accepting new registrations.").

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

Weide

Weide wrote:

hsimpson wrote:

Ich bin außerdem noch mit dem Mapper Martin2009 in Kontakt getreten, der ist auch wie ich grade dabei, sich die Tiefen des ÖPNV-mappings anzueignen und sehr viel in Köln aktiv. Allerdings kann er sich nicht hier im Forum registrieren ("This forum is not accepting new registrations.").

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.

hsimpson wrote:

Stadtbahn:
- Chaos in den Werten für railway=*: oberirisch meist tram, unterirdisch vollkommen wahrlos mal tram und mal subway. Bei den Linien-Realtionen sind alle Niederflur als Tram und alle Hochflur als Subway getaggt. Das führt dazu, dass Subway-Relationen Tram-Strecken liegen und umgekehrt.

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

hsimpson wrote:

- Linienrelationen im Tagging veraltet und Namensgebung nicht einheitlich.

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

hsimpson wrote:

- Strecken ungenau gemappt, vor allem bei den Linie 3-5 nur ein Gleis wo zwei liegen, bzw Gleise in die Straßen reingemalt. Dazu fehlen haufenweise Gleiswechsel (ist aber erstmal nebensächlich) Problem hier: Bing-Bilder sind meist nicht hilfreich, da Tunnelstrecken oder durch Bäume verdeckt.

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

hsimpson wrote:

- Zugänge zu den Haltestellen oft nicht eingetragen -> führt zu routing Problemen, da nächstgelegener Weg nicht zwingend auch einen Zugang zur Haltestelle bedeutet..

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 :-)

hsimpson wrote:

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

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

Martin2009 wrote:

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.

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.

hsimpson wrote:

Martin2009 wrote:

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.

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 😉

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.

{{DisplayRoute|network=VRS|ref=1}}
...
{{DisplayRoute|network=VRS|ref=9}}

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

Martin2009 wrote:

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.

{{DisplayRoute|network=VRS|ref=1}}
...
{{DisplayRoute|network=VRS|ref=9}}

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

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

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?

Martin2009 wrote:

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.

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

Nakaner wrote:

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.

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.

hsimpson wrote:

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?

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/h … 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?

hsimpson wrote:

Nakaner wrote:

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.

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

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.

hsimpson wrote:

- evtl Linie 4 Berliner Straße (im Vergleich sehr kurzer Abschnitt und keine Haltestelle in diesem Abschnitt)

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

hsimpson wrote:

- Linie 5 Nußbaumerstraße bis Margaretastraße, evtl auch der Teil zwischen Ehrefeldgürtel und Eisenbahnunterführung.

Ja, eindeutig.

hsimpson wrote:

- Linie 7 auf der Dürener und der Siegburger Straße ab dem Poller Kirchweg

dto.

hsimpson wrote:

- Linie 9 ab Abzweig Neumarkt komplett bis Sülz Endhaltestelle

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

hsimpson wrote:

- Linie 12 ab Eifelstraße bis Endhaltestelle Zollstock

siehe mein Posting weiter oben

hsimpson wrote:

- evtl (im Regelbetrieb nicht mehr genutzte) Schleife der Linie 13 auf der Neuenhöfer Alle und der Berrenrather Straße

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

hsimpson wrote:

- ganz vlt Linie 1+9 im Bereich Moltkestraße-Rudolfplatz

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 🙂

hsimpson wrote:

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

Nakaner wrote:

Martin2009 wrote:

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.

{{DisplayRoute|network=VRS|ref=1}}
...
{{DisplayRoute|network=VRS|ref=9}}

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

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

hsimpson wrote:

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

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/1 … 5&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...

Weide wrote:

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.
Weide

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

Hallo,

hsimpson wrote:

Meine Vermutung ist, dass er veraltete Daten verwendet hat...

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 … F_U-Bahnen funktionieren jetzt wieder.
Dazu habe ich das DisplayRoute-Template um den optionalen Parameter "type=route_master" erweitert.

Martin2009 wrote:

Die Relations-Links für die Straßenbahnen in https://wiki.openstreetmap.org/wiki/VRS … F_U-Bahnen funktionieren jetzt wieder.

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

hsimpson wrote:

Martin2009 wrote:

Die Relations-Links für die Straßenbahnen in https://wiki.openstreetmap.org/wiki/VRS … F_U-Bahnen funktionieren jetzt wieder.

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).

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.

hsimpson wrote:

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?...

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".

bjoern262 wrote:

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.

Stimmt das wollte ich noch gemacht haben 🙂
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 😉
Grüße!

hsimpson wrote:

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 😉

Bitte nicht. Oder ist das von der damaligen VRS-Freigabe gedeckt? Außerdem wäre das ein Import, den man nicht einfach so in diesem Thread diskutieren kann. Solche Daten sollten vor Ort erfasst werden.

Ich kenne leider die Freigaben vom VRS nicht. Dafür müsste man mal ältere Kölner Mapper befragen...

Nur mal so aus Interesse, was wäre denn der richtige Ort um einen Import zu diskutieren?

Btw, bei mir kommt bei kurzen Kommentaren immer ein Versandfehler mit dem Inhalt "Es müssen mindestens".
Hilft natürlich ungemein 😉 Weiß jemand, was damit gemeint ist?

Grüße

hsimpson wrote:

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 😉
Grüße!

Schauen kann man. Ändern kann man nur, wenn man sich das auch angeschaut hat.

Also die erste große Überabeitung im Stadtbahnnetz ist von meiner Seite aus durch. Alle Strecken, außer den klassischen Stadtbahnstrecken, sind auf light_rail umgestellt und alle Gleise sind inzwischen eingetragen (Danke dafür an Martin2009). Des weiteren hab ich das Tagging ausgemistet und alle Verweise auf die Anzahl der Gleise oder die Linien, die dort fahren, gelöscht, da da dies inzwischen Flächendeckend korrekt eingetragen wurde. Dazu hab ich die Keys "voltage", "frequency" und "gauge" an alles rangeklatscht, was mir in die Finger gefallen ist, teilweise auch "railway:preferred_direction" und wo erstichtlich auch "service". "operator=KVB" fehlt allerdings im Kölner Norden noch an einigen Stellen.
Viel Arbeit waren auch falsch ode gar nicht eingetragene Bahnübergänge, hier wäre später noch eine Bestandsaufnahme der Sicherungsarten nicht verkehrt, da mehr als ein "railway=(level_)crossing" oft nicht vorhanden ist, sowie das eintragen von "railway=switch" bzw. "railway=railway_crossing". Das sollte jetzt aber auch überall vorhanden sein.
Wo es ging hab ich Gleise zusammengefügt und vereinfacht, da diese teilweise sehr zerstückelt waren.
Die routen sind inzwischen alle auf PTv2 mit route=tram umgestellt.
An vielen Haltestellen feht noch eine stop_area oder diese ist sehr veraltet oder lückenhaft.

Ansonsten viele Grüße,
hsimpson

Ach ja, Weide, es wäre super, wenn du deine Fehlerliste jetzt nochmal aktualisieren würdest!
Grüße

hsimpson wrote:

Ach ja, Weide, es wäre super, wenn du deine Fehlerliste jetzt nochmal aktualisieren würdest!
Grüße

-))

Ich hab jeden Tag neue gemacht weil jeden Tag ein paar Downloads da waren obwohl es keine Links außerhalb dieses Forums gibt ... ich hatte gedacht, dass das die Kölner Aktiven sind.

Egal, solange ich sowieso wegen anderer Sachen die NRW-Datei der Geofabrik jeden Tag update ist das alles kein Problem ... der Köln-Ausschnitt braucht IIRC 7 Sekunden. Unter http://www.gafte.de/koeln.err und http://www.gafte.de/koeln.stops liegen seit ein paar Minuten jedenfalls die neuen Dateien mit Stand von gestern abend.

Falls jemand das für seine Gegend selbst machen will: Das "putr" für Linux und das "putr.exe" für Windows sind inzwischen statisch gelinkt ... man muss also nichts mehr zusätzlich installieren und kann das Programm einfach starten. Das Programm ist aber nicht grafisch und man braucht ein Kommandofenster (oder wie immer das in Windows heißt ... von Windows hab ich keine Ahnung). Die PBF-Dateien der eigenen Gegend bekommt man bei der Geofabrik (http://download.geofabrik.de). In den ebenfalls bei http://www.gafte.de liegenden Quellen ist eine Datei "commands.txt": da findet man Befehle für Linux um eigene Ausschnitte zu machen oder ein ÖPV-Overlay für Garmin-Geräte zu erzeugen. Rückfragen sind willkommen.

Weide

Weide wrote:

Ich hab jeden Tag neue gemacht weil jeden Tag ein paar Downloads da waren obwohl es keine Links außerhalb dieses Forums gibt ... ich hatte gedacht, dass das die Kölner Aktiven sind.

Also, einer der sich die Datei regelmäßig herunter lädt, bin ich, da ich dabei bin, möglichst viele der darin aufgeführten Fehler zu beheben.

An einige Meldungen traue ich mich jedoch noch nicht heran, da ich nichts "ver(schlimm)bessern" will.
Wir werden sehen, was in einigen Wochen von den Meldungen übrig bleibt.

Manchmal, wenn ich mir die Datei herunter geladen habe, würde ich gerne irgendwie heraus bekommen können, von wann die Datei ist.
Also auf welchen OSM-Datenstand sie basiert.
Von daher ist es gut zu wissen, das sie regelmäßig aktualisiert wird.
Danke auch dafür an Weide.

Viele Grüße
Martin

Martin2009 wrote:

Manchmal, wenn ich mir die Datei herunter geladen habe, würde ich gerne irgendwie heraus bekommen können, von wann die Datei ist.
Also auf welchen OSM-Datenstand sie basiert.

Die einfache Antwort: Irgendwann vormittags meist vor 9 Uhr kommt da eine neue Datei mit dem Stand vom Abend davor (meist zwischen 21 und 24 Uhr).

Oder genauer:
Bei der Geofabrik findet man unter http://download.geofabrik.de/europe/ger … s/000/001/ die Changes für NRW (heute ab 6:45 die Datei 092.osc.gz, morgen die 93 usw.). Da liegt auch eine entsprechende Datei 092.state.txt mit dem OSM-Stand der Changes (heute stand da "timestamp=2016-03-10T20\:14\:02Z"). Wenn ich bemerke, dass da eine neue Datei ist, lasse ich den Kram ablaufen und schiebe die Kölner Ergebnisse auf den Server. Es kann aber auch mal was dazwischen kommen... (Wenn ich außerhalb von NRW aktiv bin, dann hol ich statt NRW eine andere Gegend und dann kommt nichts mehr für Köln. Sorry.)

Weide

Da es zu der hier diskutierten Überarbeitungsaktion (danke nochmal) von hsimpson gehört, hänge ich es einfach mal hier an.

hsimpson hat entlang der nach EBO betriebenen Vorgebirgs- und Rheinuferbahn (Linie 16/18 zwischen Köln und Bonn) an den Haltepunkten und Bahnhöfen bei den Haltepositionen (public_transport=stop_position) railway=tram_stop ergänzt. Es gibt also dort einen Node mit railway=station/halt und zusätzlich ein oder zwei Nodes (je nach Anzahl der Gleise) mit railway=tram_stop. Siehe dazu die Diskussion in https://www.openstreetmap.org/changeset/37668148

Meine Meinung dazu:

Es handelt sich um Eisenbahnstrecken, also sind es keine "tram stops", auch wenn die Fahrzeuge Tram Trains sind und die Haltestellenausstattung Straßenbahn-ähnlich ist. Dem jetzigen Tagging zufolge gibt es dort einen Haltepunkt und eine Straßenbahnhaltestelle.

Die Wahl zwischen railway=halt/station und railway=tram_stop richtet sich nach der Schieneninfrastruktur. Zwar sind die Strecken nicht für Güterzüge geeignet (die Hochbahnsteige ragen in deren Lichtraumprofil), aber wenn man ein Eisenbahnfahrzeug hat, das am Bahnsteig vorbei passt und eine Trasse gekauft hat, darf man dort fahren (es ist öffentliche Eisenbahninfrastruktur).

Wenn ich der Argumentation von hsimpson folgen würde, müsste ich Maximiliansau West in railway=tram_stop umtaggen, weil der Bahnsteig von der Albtal-Verkehrs-Gesellschaft (Betreiber der Strecke ist DB Netz!) betrieben wird und diese den gleichen Baustil für Wartehäuschen hat wie die Verkehrsbetriebe Karlsruhe. (Neureut Kirchfeld wäre sogar ein Fall wie die Vorgebirgsbahn und die Rheinuferbahn)

Meiner Meinung nach taggen wir vornehmlich nach der Nutzung oder Bedeutung eines Objekts. Eine Straße bekommt ein highway=tertiary, wenn sie eine tertiaryübliche Verkehrsbedeutung hat, egal ob sie unter Landes- oder kommunaler Trägerschaft steht oder ob sie asphaltiert ist oder noch hundertjahrealte Pflastersteine hat. In ein Gebäude, in dem eine Kirchengemeinde Gottesdienste feirt, kommt ein amenity=place of worship, egal ob es ein dedizierter Sakralbau ist, eine ehemalige Fabrikhalle oder eigentlich ein Wohnhaus ist, auch ganz unabhängig davon, nach welchem Baurecht das Gebäude errichtet wurde.

Und wenn jetzt an diesem besagten Halt nur Straßenbahnen halten, dann soll das Ding in meinen Augen auch Straßenbahnhalt heißen. Schließlich werd ich als User wohl auch so eine suchen, wenn ich auf die Karte schaue.

Edit: Und wenn das bei den oben genannten Halten ebenso der Fall ist, ja dann müsste man sie wohl ändern.

hsimpson wrote:

Beitrag vom 2016-02-26 13:04:37

Ich bin außerdem noch mit dem Mapper Martin2009 in Kontakt getreten, der ist auch wie ich grade dabei, sich die Tiefen des ÖPNV-mappings anzueignen und sehr viel in Köln aktiv. Allerdings kann er sich nicht hier im Forum registrieren ("This forum is not accepting new registrations.").
Ihm ist wohl noch empfohlen worden, sich an die Social Media Abteilung der KVB zu wenden mit der Bitte um aktuelle Gleispläne und die Berechtigung, diese für OSM zu verwenden.

Stimmt, ich hatte mich damals an die Social Media Abteilung der KVB gewendet.

Nach ca einer Woche hatte ich die Antwort erhalten, dass meine Anfrage KVB-Intern weitergegeben wurde.
Obwohl mir damals eine Antwort zugesagt wurde, warte ich bis heute auf eine Rückmeldung der KVB.

Schade, aber KEINE Antwort ist auch eine Antwort.
Inzwischen habe ich die Hoffnung, noch irgendeine Antwort von denen zu erhalten so gut wie aufgegeben. 🙁

OT: Zum Thema KVB muss man sich nur mal deren App angucken. Ich hatte denen irgendwann auch schon mal eine Mail geschrieben, dass man z.B. nicht die früheren Verbindungen angezeigt haben möchte, wenn man auf "später" klickt. Naja, scheint die nicht zu interessieren. Ziemlich peinlich dieser Laden, was das betrifft.

Gestern hat jemand extra einen neuen User angelegt, um hier https://www.openstreetmap.org/changeset/84712228 großflächig alle Kölner Linien von tram auf light_rail zu ändern. Mal davon abgesehen, dass er nur route_master geändert hat (und nicht den ganzen Rest, was technisch falsch bzw. unsauber ist) halte ich die Änderung auch für inhaltlich falsch bis fragwürdig - oder zumindest für diskussionswürdig. Was meint Ihr?

Hallo,

hsc666 wrote:

Gestern hat jemand extra einen neuen User angelegt, um hier https://www.openstreetmap.org/changeset/84712228 großflächig alle Kölner Linien von tram auf light_rail zu ändern. Mal davon abgesehen, dass er nur route_master geändert hat (und nicht den ganzen Rest, was technisch falsch bzw. unsauber ist) halte ich die Änderung auch für inhaltlich falsch bis fragwürdig - oder zumindest für diskussionswürdig. Was meint Ihr?

Das ist falsch. Deshalb habe ich es revertiert. Im PTv2-Schema gibt es kein "light_rail", nur "tram" und "train".

Viele Grüße

Michael

EDIT: subway gibt es auch als "gültigen" Wert.

Hallo zusammen,

ich gebe zu der Übeltäter zu sein. Leider dachte ich, meine Veränderung wäre nicht richtig übernommen gewesen und hatte es jetzt erneut geändert. Sorry Nakaner.

Wo "tram" inhaltlich richtiger ist als "light_rail" habe ich jedoch nicht verstanden. Was das mit dem PTv2-Schema zu tun hat, sehe ich auch noch nicht. Vielleicht könnt ihr mich erleuchten.

Liebe Grüße
Phill

philld91 wrote:

Was das mit dem PTv2-Schema zu tun hat, sehe ich auch noch nicht.

PTv2 ist die beschlossene Art, ÖPV zu mappen (https://wiki.openstreetmap.org/w/index. … did=625726). Das was davor üblich war, nennen wir PTv1. Zu PTv2 gehören z.B. die route_master-Relationen und ihre route-Relationen.

Da wird der Charakter der Linie angegeben damit man ihn mit den Fahrwegen vergleichen kann. Zulässig sind "train", "subway", "monorail", "tram", "bus", "trolleybus", "aerialway" und "ferry". Bei Überprüfungen wird für jeden dieser Werte die Liste der möglichen Fahrwege mit den angegebenen verglichen.

Deshalb ist z.B. der Pferdebus im Linienverkehr mit "route_master=bus" richtig zu beschreiben. Für Taxen, die z.B. in Schweden sehr oft als Fahrzeuge einer Buslinie eingesetzt werden wenn zu der Zeit erfahrungsgemäß kaum einer mitfährt gilt ebenfalls "bus". Und ein schienengebundener Pferdebus hat daher "train".

Weil es diese Liste zulässiger Werte gibt wäre z.B. bei einer RoRo-Fähre die Angabe "route_master=roro_ferry" statt des richtigen "route_master=ferry" destruktiv, denn wenn da nicht "ferry" steht laufen die Checks ins Leere. Ähnlich falsch ist "coach". Mit der Bezeichnung wird eben nicht das Fahrzeug sondern der Liniencharakter beschrieben.

Natürlich ist die Einteilung nicht perfekt. Z.B. können Trolleybusse heute nicht mehr nur auf elektrifizierten Straßen fahren ... die rasante Entwicklung der Akkutechnik hat die Unterscheidung von Trolleybus und Bus praktisch obsolet gemacht. Da werden wir im nächsten Schema einiges ändern müssen. Aber bis dahin sollten wir nach PTv2 mappen. (PTv1 geht auch und ist bei nur schnipselweise bekannten ÖPV-Linien praktischer)

Naja, nichtsdestotrotz ist das Kölner Stadtbahn System genauso wie Hannover falsch getaggt. Das muss ja korrigiert werden.

philld91 wrote:

Naja, nichtsdestotrotz ist das Kölner Stadtbahn System genauso wie Hannover falsch getaggt. Das muss ja korrigiert werden.

und was ist falsch ?

Zusatzfrage @philld91: Du hast Dich intensiv mit dem Wiki beschäftigt und z.B. hier https://wiki.openstreetmap.org/wiki/DE: … light_rail informiert und dabei auch den folgenden wichtigen Satz gefunden?

Zur Vermeidung von Streit und Aufregung sei im deutschsprachigen Raum jedoch jedem empfohlen, sich vor einem Umtaggen oder beim Eintragen neuer Strecken, einen Konsens im Forum und/oder Mailinglisten zu finden.

Ja habe ich gelesen. Ändert aber nichts an der Tatsache, dass das Stadtbahnnetz als tram getaggt ist. Das ist falsch, da sehe ich auch keinen Diskussionsbedarf.

Hallo philld91,

es mag zwar sein, dass du route_master=tram, route=tram und tram=yes an Masterrouten/Routenrelationen/Bahnsteigen/Haltepositionen falsch findest und light_rail bevorzugst, weil das mehr nach Stadtbahn klingt. Wie andere Mapper, insbesondere Weide aufgezeigt haben, ist es jedoch OSM-technisch falsch, da im anerkannten und etablierten PTv2-Schema es keine Stufe zwischen einer Straßen- und einer U-Bahn gibt. Bitte betrachte diese Tag-Schlüssel und Tag-Werte
nicht ausschließlich aus der Schienverkehrsperspektive sondern. Die Wahl eines Schlüssels oder Werts in OSM orientiert sich zwar an realsprachlichen Begriffen der Britisch-Englischen Sprache. Es gibt jedoch Fälle, wo es nicht zielführend ist, sich an der exakten, realsprachlichen Bedeutung aufzuhängen. Betrachte daher im ÖPNV-Bereich die Schlüssel und Werte in einigen Fällen, u.a. hier, als aussprechbare Aneinanderreihungen von Unicode-Zeichen (kurz: Strings).

Ich habe bemerkt, dass du nach meinem Revert erneut versucht hast, die von dir angestrebten Änderungen anzubringen. hsc666 hat das mittlerweile dankenswerterweise revertiert. Bitte beachte, dass wir Editwars bei OpenStreetMap grundsätzlich nicht dulden und das Fortsetzen eines Editwars nicht mit den Grundsätzen des OpenStreetMap-Gemeinschaftsprojekts vereinbar ist (d.h. du wirst dann gesperrt).

Viele Grüße

Michael

Hallo Michael,

auf die erneute Anpassung bin ich ja oben schon eingegangen, zusätzliche Arbeit wollte ich niemanden machen und von einem Editwar zu sprechen finde ich noch etwas überzogen.
Das PTv2 ist ein deutsches Schema vermute ich mal? Andernfalls würde es ja gar keinen Sinn machen, dass es überhaupt light rail-tags gibt und sie international eingesetzt werden. Mich interessiert aber vor allem wieso jede deutsche Stadt das mit dem Taggen anders handhabt. Der VRR tägt seine Stadtbahnen als U-Bahn, andere als Straßenbahn. Aber was ist mit Städten wie Bielefeld, Karlsruhe und Stuttgart, die ihre Systeme als light rail getaggt haben. Das wäre dem PTv2-Schema nach dann ja auch falsch. Von Berlin und Hamburg mal ganz zu schweigen, die ihre S-Bahnen als light rail taggen. Also ein einheitliches System wird bisher ja offensichtlich nicht umgesetzt.
Ich verstehe aber auch nicht, wieso man sich auf ein Schema stützt, dass light rail nicht anerkennt, obwohl es diesen Tag international gibt. Ich würde ja beim betrachten der entsprechenden ÖPNV-Karten erwarten, dass die legende überall einheitlich verwendet wird. Also das passt doch vorne und hinten nicht.

Grüße, Phill

philld91 wrote:

Das PTv2 ist ein deutsches Schema vermute ich mal?

PTv2 ist keine lokale Angelegenheit. PTv2 wurde OSM-weit beschlossen und gilt OSM-weit. Es ist das einzige beschlossene ÖPV-Schema in OSM.

philld91 wrote:

Andernfalls würde es ja gar keinen Sinn machen, dass es überhaupt light rail-tags gibt und sie international eingesetzt werden.

Das light_rail tag gibt es für Gleise und ist da völlig anerkannt. Für die ÖPV-Verbindungen ist es ein Fehler. Dort werden nicht Schienenarten, Fahrzeugarten und ähnliches erfasst sondern Klassen von ÖPV-Linien. Dass "light_rail" auch im ÖPV-Bereich an manchen Stellen benutzt wurde liegt daran, dass eine Änderung des Abstimmungstextes nach der Abstimmung nicht verhindert wurde.

philld91 wrote:

Ich würde ja beim betrachten der entsprechenden ÖPNV-Karten erwarten, dass die legende überall einheitlich verwendet wird. Also das passt doch vorne und hinten nicht.

Das finde ich auch :-) Es sollte endlich konsequent nach dem einzigen OSM-weit beschlossenen ÖPV-Schema PTv2 gemappt werden. Und das bedeutet, dass light_rail nicht zu den ÖPV-Routenarten gehört.

Nochmal eine Frage zu dem tagging. Gibt es denn den Willen, die ganzen falsch getaggten Systeme anzupassen. Beispiele gibt es ja genug (siehe Stuttgart, Karlsruhe, Berlin, Hamburg, Düsseldorf, Frankfurt, Bielefeld, Houston, Dallas, Portland, Los Angeles, Phoenix , Newark, Boston, Sevilla, Valencia und und und).

Ich frage mich ohnehin ob es Sinn macht sich an eine Schema zu halten, dass die Wirklichkeit zu stark vereinfacht und von so gut wie niemanden umgesetzt wird. Die Logik hat sich mir noch nicht erschlossen.

Was soll denn z. B. konkret an Stuttgart falsch sein? (da kenne ich mich halt aus)

Dort wird ja auch der Tag Stadtbahn verwendet und wie wir hier gelernt haben, ist er ja falsch.

Apropos Stuttgart ...
Vor vielen Jahren waren da mal Stadtbahn UND S-Bahn light_rail, das ist aber schon 5 Jahre korrigiert. Trotzdem erscheint die S-Bahn in der openptmap immer noch grün, werden deren Overlay-Kacheln nicht mehr aktualisiert?

Schienennagelhammerträger wrote:

Apropos Stuttgart ...
Vor vielen Jahren waren da mal Stadtbahn UND S-Bahn light_rail, das ist aber schon 5 Jahre korrigiert. Trotzdem erscheint die S-Bahn in der openptmap immer noch grün, werden deren Overlay-Kacheln nicht mehr aktualisiert?

Antwort siehe https://forum.openstreetmap.org/viewtop … 04#p789604