Jo, der Spagat zwischen EBO und BOStrab macht das ganze kompliziert …
Eigentlich ist auch das Karlsruher Straßenbahnnetz relativ stadtbahnnah, weil oft eigener Gleiskörper.
Wegen der Karlsruher Besonderheiten habe ich damals den Wechsel tram/light_rail
auf der Gleichstromstrecke S1/S11 mit dem Wechsel EBO/BOStrab zusammengelegt
auf den Zweisystemstrecken mit der Stelle, wo es für Gleichstromer keinen Sinn mehr ergibt, weiter zu fahren, weil keine Gleichstromhaltestelle mehr … Und light_rail solange die Gleise unabhängig von der sonstigen Bahn praktisch getrennt sind.
Jo.
Obiges zu KA bezog sich auf die Infrastruktur.
Die Linien mit S bekamen einheitlich light_rail, ob nun auf tram, light_rail oder rail fahrend …
commuter wäre für beides sinnvoll.
für die Linien, die ein S haben und nicht in KA oder der Ortenau fahren
und für Strecken, die fast ausschließlich von diesen befahren werden als Zusatztag.
Es gab ja glaub mal proposals, wo man taggen hat wollen, was da unterwegs ist.
Die S-Bahn hat sich auch aus der Vollbahn nach EBO heraus entwickelt, die klassisch eben von der DB betrieben wurde, die U-Bahn dagegen als innerstädtisches System nach BOStrab von Privaten, später zur BVG fusioniert, übrigens in zwei Varianten: Kleinprofil und Großpofil.
Im Prinzip ja, wobei ich für ersteres plädiere. Das ist direkter.
Wichtig ist vor allem, dass so ein Vorschlag irgendwo im Wiki dokumentiert ist.
Eventuell braucht man auch beides.
route=commuter für die Linie und ihre Varianten
commuter=yes analog zu tram/bus=yes für die Haltestellen,
wenn man S-Bahn Haltestelle von anderen unterscheiden will.
Wenn du so ein Proposal machen willst, denke bitte daran, dass es den Begriff S-Bahn praktisch nur im deutschsprachigen Raum gibt. Ähnliche Schnellbahn-Systeme gibt es jedoch weltweit.
Auf jeden Fall hast du meine Unterstützung und meine Stimme für so einen Vorschlag.
OK, hab ich noch nie gemacht, aber man wächst ja an seinen Aufgaben.
commuter=yes hab ich nur gedacht für das neue Schema, um Haltestellen den Tag zu geben; nicht als Zusatz-Tag zu route=train oder so.
Mal abgesehen vom Schreiben der Proposal-Seite: was muss man denn noch machen? “Wahlkampf”?!
Komisch, bei der S28 zwischen Kaarst und Mettman gabs da keine Probleme. Betreiber (seit Anfang an): Regiobahn.
Demnächst werden hier auch noch 2 Linien aus dem DB-Konzern ausscheiden.
Es gibt da immer mehrere Möglichkeiten. Eine ist es zum Beispiel Lizenzkosten zu zahlen. Eine zweite Möglichkeit ist das der Verkehrsverbund/Ausschreiber diese Kosten trägt etc.
Gut. Ich hab jetzt mal ein Proposal geschrieben.
Für Verbesserungen und Vorschläge bin ich sehr offen! Ist “commuter rail” genau genug definiert? Ist klar genug, warum wir diesen neuen Tag brauchen?
Ja; sauberer ist es natürlich, einen richtigen Tag dafür zu haben.
Auf der tagging-Liste leider auch. Was kann man da tun? Deutschland-Liste?
Wünschenswert wäre das allemal! Sonst werden zig S-Bahn-Linien dort nicht gerendert, solle man auf route=commuter umstellen.
Noch was: Auf der transit-Liste schlug jemand vor, als Zusatz zu route=train gleich einen neuen key zu erfinden: route:type=* und dann commuter oder Fernverkehr oder so. Damit es für größere Komplexität in der Zukunft offen ist. Was meint ihr?
Was ich daran nicht sehr logisch finde: route=train ist ja schon eine Näherbestimmung von type=route. Dann wäre route:type dazu doppelt gemoppelt. Folgerichtiger fände ich train:type=commuter/etc.
Durch die beiden tags lässt sich eine Hierarchie besser abbilden. So bleibt es dem Mapper und renderer überlassen, ob sie nur Zug oder detaillierter Nahverkehr/S-Bahn/Fernverkehr spezifizieren wollen.
Mit nur einem tag muß man einen Haufen Werte durchsuchen, wenn man es nicht genau haben will.
Seh ich auch so. Das wär dann kompatibel zum Bisherigen. Die, die wollen, werten den neuen “S-Bahn-Tag” mit aus. Die, die nicht wollen, haben dann wenigstens keine leere Karte.
Kann es sein, dass ihr mich falsch verstanden habt? Ich stell oben nicht in Frage, dass es sinnvoll ist, hierarchische Tags zu haben. Da bin ich - wenn ich mich nicht irre - einer Meinung mit euch. Sondern, ich finde, dass route:type=* nicht so unlogisch ist wie train:type=*.
Leuchtet ein, aber dann braucht man für die Spezifizierung von Busdiensten noch ein neues tag.
Leider ist es so, dass man in der postgreSQL-Datenbank für jeden auszuwertenden Spezial-tag eine eigene Spalte anlegen und anschliesend den Planeten neu importieren muß, was die Datenbank aufbläht und auf dem dev-Server vermutlich nicht so einfach möglich ist, oder key und value aus der hstore-Spalte rauspfriemeln muß, was die Verarbeitung ausbremst.
Ich wäre ja auch mit service=commuter einverstanden, aber da wird sich möglicherweise jemand dran stören, weil service=* schon zur Klassifzizierung der Gleise verwendet wird.
