Ausstattung von Zügen

Man müsste im Prinzip erfassen, was für Fahrzeuge dort jeweils eingesetzt werden und bräuchte ein standardisiertes Format um herauszufinden, was für eine Ausstattung die Fahrzeuge haben (letzteres besser ausserhalb von OSM). Das würde also vermutlich auf eine externe Fahrzeugdatenbank (was auch schon in einigen Bahn-Foren gewünscht wurde) und eine Verknüpfung unserer Relationen damit hinauslaufen.

Hier gibt es übrigens bei einigen Zügen teils Fahrzeuge mit Klapptritt (barrierefrei bis auf einzelne Sitzgruppen, mit weniger 1. Klasse und vereinfachtem Fahrkartenautomat) und teils fast identische mit Stufen (ebenso barrierefrei durch vier vom Personal ausklappbare Rampen, ohne zuvor genanntes).

Ich halte das in Kombination mit unserem aktuellen Datenmodell für nur sehr aufwändig umsetzbar. Denn den Zug an sich taggen wir ja nicht. Wir tragen ein, dass von A nach B ein RE, RB, S... fährt. Dummerweise fahren aber zwangsweise nicht immer die gleichen Züge. Ich kenne Verbindungen, da werden am Wochenende zu bestimmten Zeiten Züge eingesetzt, die mehr Fahrräder mitnehmen können. Teilweise ist es auch zufällig, ob da jetzt ein bereits renovierter Zug eingesetzt wird oder nicht.

Hinzu kommt, dass ich nicht mal im entferntesten einen Bezug zu Geodaten herstellen kann. Ich denke, dass es sicherlich sinnvolle Infos sind, aber in OSM halte ich es nicht für gut aufgehoben.

rayquaza wrote:

Man müsste im Prinzip erfassen, was für Fahrzeuge dort jeweils eingesetzt werden und bräuchte ein standardisiertes Format um herauszufinden, was für eine Ausstattung die Fahrzeuge haben (letzteres besser ausserhalb von OSM). Das würde also vermutlich auf eine externe Fahrzeugdatenbank (was auch schon in einigen Bahn-Foren gewünscht wurde) und eine Verknüpfung unserer Relationen damit hinauslaufen.

Warum so kompliziert?
Die S-Bahnen-Linien im Großraum Hannover kann man mit 2 Händen abzählen. Also an die entsprechenden route-Relations (oder route_master?) ein toilets=yes dran.

aighes wrote:

Ich halte das in Kombination mit unserem aktuellen Datenmodell für nur sehr aufwändig umsetzbar. Denn den Zug an sich taggen wir ja nicht. Wir tragen ein, dass von A nach B ein RE, RB, S... fährt. Dummerweise fahren aber zwangsweise nicht immer die gleichen Züge. Ich kenne Verbindungen, da werden am Wochenende zu bestimmten Zeiten Züge eingesetzt, die mehr Fahrräder mitnehmen können. Teilweise ist es auch zufällig, ob da jetzt ein bereits renovierter Zug eingesetzt wird oder nicht.

Also, bei meinen Beispielen oben ist das nicht so eine zufällige Geschichte. Der Metronom wird immer von den entsprechenden Fahrzeugen bedient - und die haben alle (außer, wenn kaputt) einen Getränkeautomat. Und die S-Bahnen in Hannover hatten immer ein Klo dabei.

aighes wrote:

Hinzu kommt, dass ich nicht mal im entferntesten einen Bezug zu Geodaten herstellen kann. Ich denke, dass es sicherlich sinnvolle Infos sind, aber in OSM halte ich es nicht für gut aufgehoben.

"Relevanzdiskussion, ick hör dir trapsen."
Sind fee=* und payment-Tags Geodaten im engeren Sinne?

Geogast wrote:

Also, bei meinen Beispielen oben ist das nicht so eine zufällige Geschichte.

Deshalb sag ich dir ja ein paar Beispiele, bei denen das nicht so einfach ist.

Was ich kenne:
auf der RB Eisenach-Halle verkehren am Wochenende manche Züge als Doppelstockwagen.
auf der EB Erfurt-Ilmenau verkehren zwei verschiedene Zugtypen, deren Ausstattung sich unterscheidet.
Die Züge der 612-Baureihe, die durch Thüringen rollen haben durchaus andere Ausstattungen und werden munter gemischt eingesetzt. Unterschiede wären: Kinderecke, Klappsitze im Multifunktionsabteil oder nicht...

Bei den ICs kann man Glück haben und der hat an jedem Sitz eine Steckdose oder er hat eben keine.

Geogast wrote:

Warum so kompliziert?

Nehmen wir mal an wir hätten eine Fahrzeugdatenbank mit Verbindung zu den OSM-Daten wie oben genannt. Dann gäbe es Informationen über die verschiedenen Baureihen, ihre Varianten und Umbauten und die einzelnen Fahrzeuge (z.B. Werbebeklebung oder in welchem Netz sie eingesetzt werden). Aus den OSM-Daten würde man dann die ID des Netzes haben und nachschauen, wie die dortigen Fahrzeuge ausgestattet sind. Soweit noch kein Problem, ein "barrierefrei" aller Fahrzeuge eines Netzes könnten wir auch mit wheelchair=yes erfassen. Allerdings sind manche Fahrzeuge barrierefreier als andere, was momentan in OSM ignoriert wird (und zu ständigem Umtagging und unterschiedlichem Tagging gleicher Situationen führt). Auch bei Umbauten (z.B. neu eingebaute Fahrkartenautomaten) könnte man berechnen, wie wahrscheinlich es ist ein solches Fahrzeug zu erwischen, was mit einem vending_machine=yes nicht ginge. Es ist eben nicht überall so einfach wie in HH, wo es nur Fahrzeuge mit Klapptritt und welche mit Klappstufe gibt.

Ausserdem wäre eine Fahrzeugdatenbank auch ausserhalb von OSM nützlich.

aighes wrote:

Bei den ICs kann man Glück haben und der hat an jedem Sitz eine Steckdose oder er hat eben keine.

Versuch's mal im Grossraum am Tisch, entweder am Fensterteiler oder unterm Mülleimer (ausser bei IR-Wagen) 😉

aighes: +1. Ich finde, sowas hat in OSM wenig zu suchen, weil es Eigenschaften von beweglichen Objekten sind, und wir nicht die Eigenschaften von beweglichen Objekten erfassen. Die Bahnlinien / Streckenverläufe dagegen sind Ansammlungen / Relationen von geografischen Objekten, nämlich Haltestellen und Gleisen.

Geogast wrote:

Sind fee=* und payment-Tags Geodaten im engeren Sinne?

Wenn es Eigenschaften eines geografischen, d.h. ortsfesten Objektes (Parkplatz, Mautstelle) sind: Ja.

aighes wrote:

Unterschiede wären: Kinderecke, Klappsitze im Multifunktionsabteil oder nicht...

Bei den ICs kann man Glück haben und der hat an jedem Sitz eine Steckdose oder er hat eben keine.

Also, bei dieser Steilvorlage fang ich gleich mit Relevanz an 😄
Aber abgesehen davon: Ausstattung mit Klo, Ticketautomat und Getränkeversorgung (ob Bistro, Restaurant oder Automat) sind doch ganz konstant auf einer Linie. Selbst bei wechselnd eingesetzten Wagen: auf ein und derselben Linie werden doch alle ein Klo haben, unter der Woche und am WE - oder eben nie (S-Bahn Berlin).
Die ICEs jeder Generation haben irgendwie einen Verkauf von Essen und Trinken. Ja, Steckdosenversorgung ist da nicht einheitlich. Deswegen will ich das ja auch nicht mappen. 😛

Geogast wrote:

Aber abgesehen davon: Ausstattung mit Klo, Ticketautomat und Getränkeversorgung (ob Bistro, Restaurant oder Automat) sind doch viel konstanter auf einer Linie. Selbst bei wechselnd eingesetzten Wagen […]

Nein, siehe oben: Hier haben nur die S-Bahn-Fahrzeuge Fahrkartenautomaten, die damit munter vermischt (der selbe Zug kann am einen Tag nur aus 425.1, am nächsten nur aus 425.2 und am darauf folgenden aus jeweils einem von beiden bestehen) eingesetzten Regio-Fahrzeuge nicht.

rayquaza wrote:

Geogast wrote:

Aber abgesehen davon: Ausstattung mit Klo, Ticketautomat und Getränkeversorgung (ob Bistro, Restaurant oder Automat) sind doch viel konstanter auf einer Linie. Selbst bei wechselnd eingesetzten Wagen […]

Nein, siehe oben: Hier haben nur die S-Bahn-Fahrzeuge Fahrkartenautomaten, die damit munter vermischt (der selbe Zug kann am einen Tag nur aus 425.1, am nächsten nur aus 425.2 und am darauf folgenden aus jeweils einem von beiden bestehen) eingesetzten Regio-Fahrzeuge nicht.

Oh, das wäre wirklich ein Gegenbeispiel. Wo ist das denn so?

Geogast wrote:

Wo ist das denn so?

S-Bahn RheinNeckar.

Geogast wrote:

Aber abgesehen davon: Ausstattung mit Klo, Ticketautomat und Getränkeversorgung (ob Bistro, Restaurant oder Automat) sind doch ganz konstant auf einer Linie. Selbst bei wechselnd eingesetzten Wagen: auf ein und derselben Linie werden doch alle ein Klo haben, unter der Woche und am WE - oder eben nie (S-Bahn Berlin).

Selbst das nicht. Die erwähnte Verbindung Erfurt-Ilmenau wird von Fahrzeugen bedient, die einen Automaten haben und von Wagen, die keinen haben.

Apropos Relevanz: Was interessiert mich ein Ticket- oder Getränkeautomat. Mir ist viel wichtiger, ob ich mein Rad tragen muss oder es rein rollen kann und wie viel Platz in dem Zug vorhanden ist. 😉

Geogast wrote:

Was haltet ihr davon?

Nischt.

Was hat die Ausstattung von Zügen mit OSM zu tun? Eine Schnapsidee. Sind schon alle Sackerl-fürs-Gackerl-Spender gemappt?

Geogast wrote:

Was haltet ihr davon?

Gar nichts, außer der Zug ist ausrangiert, stationär, und dient z.B irgendwo als Restaurant. Rollendes Material mit immer wieder (zeitlich) wechselnder Ausstattung zu taggen hat IMO nix in OSM verloren.

Ciao
Ryu =^_^=

Ryukia wrote:

Rollendes Material mit immer wieder (zeitlich) wechselnder Ausstattung zu taggen hat IMO nix in OSM verloren.

"Immer wieder wechselnd" ist es aber auch nur etwa so wie Öffnungszeiten, Wasserpreise oder Ladenbesitzer (genauer: etwa alle 5 bis 20 Jahre mal).

Der Vorschlag ist - mit Verlaub gesagt - Quatsch mit Soße. Bewegliche Objekte variabler Zusammenstellung in OSM - vergiss es. Warum nicht noch die Ausstattung der Linienbusse, Taxen, Anzahl und Größe der LKWs bei DHL und ähnlichen Blödsinn?

Dann schon lieber HKTS - die laufen wenigsten nicht weg. Bei denen vermisse ich allerdings noch den Tag für die Anzahl der noch vorhandenen Tüten.

Gruss
walter

Frage an die, die sich jetzt dagegen ausgesprochen haben (chris66, Wolfgang B, Ryukia, wambacher): Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Dagegen derartiges in die OSM-DB zu packen.

scai wrote:

Dagegen derartiges in die OSM-DB zu packen.

+1

Ich halte die OSM-Struktur dafür für reichlich ungeeignet. Ich sehe es schon als Aufwendig an, überhaupt auf allen Bahnstrecken die entsprechen Nah-und Fernverkehrs-Routen zu pflegen.

Ja und wenn, dann sind eh diese Routen der einzigste Aufhänger. Jeder Zug hat seine eindeutige Nummer. z.B. mein Hauptzug ist früh der IC 24312, Abend IC2431. Im Regional-Verkehr fahren alle 1 oder alle 1/2 Stunde ein Zug, jeder mit eigerner Nummer.
Die einzigste Möglichkeit, die ich sehe, wäre eine externe Lösung, die einzig und allein auf die Vorhandenen Daten (Routen in Verbindung mit Zeit) aufbaut.

Die Frage baut etwas auf Lösungen wie das Zugradar auf. Nur das eben nicht (nur) die Position, Fahrzeug und Verspätung angezeigt werden, sondern dann eben auch sie Ausstattung...

Aber wer soll das erstellen und Pflegen... 😐

Sven

Geogast wrote:

Was haltet ihr davon?

Auch nichts.

Züge sind mobil und nicht stationär. Das ist dann der Unterschied zu einem stationären Fahrkartenautomaten. Der bewegt sich nicht; er funktioniert nur nicht immer. Auch der Unterschied zu einem Laden mit Öffnungszeiten. Der Laden ist stationär und hat über einen gewissen Zeitraum seine festen Öffnungszeiten.
Züge sind (leider) eben auch nicht fest einer Linie zugeordnet: das sieht man immer wieder bei den diversen Eisenbahnunternehmen, wenn auf einmal andere Fahrzeuge (mit anderer Ausstattung) fahren (IC statt ICE, ...).
Züge sind nicht alle gleich. Selbst auf einer Strecke können sich Züge / Fahrzeuge unterscheiden. Und das kann durchaus der Fahrkartenautomat sein, der nicht in allen Zügen eingebaut ist.

Ich denke, dass auch hier durchaus eine Verknüpfung der Geodaten mit den Zuginformationen (ählich wie Zugradar) sinnvoll sein können. Hierbei müsste der Zug (ein Objekt mit Eigenschaften, die genau diesen Zug beschreiben) mit seiner Position verknüpft werden.

Übrigens beschreibt auch die Zugnummer nicht die Eigenschaften des Zuges. Hier können durchaus unterschiedliche Züge an verschiedenen Tagen zum Einsatz kommen. Und die sind ja nicht immer gleich.

rayquaza wrote:

Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Zum ersten Teil der Frage: Ja klar, in einer externen Datenbank kann jeder sammeln, was er will. Auch die Betätigungskräfte von Zugtüren, Farbe der Sitzflächen im Zug, Vorhandensein und Funktion einer Klimaanlage, Ausstattung mit Kaugummiautomaten sowie Wasser- und Papiervorrat der Bordtoiletten.
Zum zweiten Teil: eine ID, die sich auf die tatsächlichen (Strecken-/Routen-)Daten bezieht, ja. In der Regel sollte die bereits als ref=RExx etc. vorhanden sein. Eine ref:zug_popcornautomat_datenbank, nein danke. Da haben wir schon genug tote Tags von openGeoDB, AND, FreieTonne usw.

wambacher wrote:

Dann schon lieber HKTS - die laufen wenigsten nicht weg ...

Hallo Walter

Habe gestern meinen ersten HKTS erfasst. Einer von knapp über 5000 und damit der dritthäufigste 'Verkaufs'automat, nur übertroffen von Zigaretten und Parkscheinen.

Edbert (EvanE)

Im Prinzip gibt es so was doch schon: über die Public Transport Karte (www.openptmap.org). Hier gibt es die Möglichkeit mit Klick auf die jeweilige Haltestelle den Fahrplan der Bahn aufzurufen. Es wäre dann Sache der Bahn, die Ausstattung der dann eingesetzten Züge auszugeben (wenn nicht die Bahn, wer soll denn dann wissen, welche Waggons tatsächlich eingesetzt werden - obwohl, wenn man näher darüber nachdenkt, könnte man fast dabei einen James Dean-Film zitieren: "Denn sie wissen nicht, was sie tun" 😉) )

Lange Rede kurzer Sinn: Die Idee ist sicherlich nicht falsch, eine Lösung in OSM sollte nur in der Form aussehen, dass in einer Karte eine Verknüpfung zur Fahrplanauskunft (mit der jeweiligen Fahrzeugausstattung) des relevanten ÖPNV-Unternehmen erfolgt.

Geogast wrote:

"Relevanzdiskussion, ick hör dir trapsen."
Sind fee=* und payment-Tags Geodaten im engeren Sinne?

Im "engeren Sinne" nicht, aber: Es kommt auch darauf an, woran man eben z.B. "fee" heftet: An einem Parkplatz ist es eine nette Zusatzinfo. Dann ist das aus meiner Sicht beinahe so wie ein Straßenname an einem Haus, oder der Hinweis "building ist shop": Der Parkplatz ist das was gemappt wird - und dieser wird mit Zusatzinformationen ergänzt, die nicht mehr "Geodaten im engeren Sinne" sind. Aber an einem Zug kann man für OSM ganz sicher nichts heften - weil der übergeordnete Zug selbst dort nicht vorhanden ist (und dort auch nichts verloren hat). Kartendaten versuchen möglichst statische Infos vorzuhalten, während Züge versuchen eher weniger statisch zu sein. Ewig hält zwar nichts, und somit ist genau genommen gar nichts statisch - aber beim Vergleich Parkplatz vs. Zug fällt eine Unterteilung in statisch / nicht statisch auch nicht sonderlich schwer.

Joachim Moskalewski wrote:

Ewig hält zwar nichts, und somit ist genau genommen gar nichts statisch - aber beim Vergleich Parkplatz vs. Zug fällt eine Unterteilung in statisch / nicht statisch auch nicht sonderlich schwer.

Statisch ist hier das Gleis und die daran angebundene ÖPNV-Relation. Nur wenn der Mapper Stein und Bein schwört, dass auf dieser Linie garantiert nur dieser eine Wagentyp fährt, könnte man dessen Eigenschaften "statisch" als Zusatzinformation an die Relation heften.
Übrigens: Auch beim Parkplatz mit "fee" kann es mal sein, dass das Kassiererhäuschen nicht besetzt ist. Das Thema also bitte nicht zu dogmatisch nehmen.

Also, das grundsätzliche Argument, dass bewegliche Objekte nicht in eine Geodatenbank gehören, dass kann ich durchaus nachvollziehen.
Wobei: Unsere Daten sind z.T. schon deutlich jenseits von "Geo"-Daten: die Farben von U-Bahn-Routen z.B. Aber das wird hier ja diskutiert.

Aber bevor hier nun weiter ausgebreitet wird, wie unterschiedlich Züge ausgestattet sein können: Das ist mir ja klar. Dann taggt man das eben nicht. Niemand würde ja auf die Idee kommen, die Öffnungszeiten eines Geschäfts zu taggen, das gar keine regelmäßigen Öffnungszeiten hat. Und wenn die Regionalbahn XY mit dermaßen unterschiedlichen Wagen bedient wird, dass es nicht einheitlich ist, ob ein Klo an Bord ist, dann taggt man einfach nichts.
Wenn aber die Sicherheit, dass ein Zug ein Klo hat oder eben nicht, nahe bei 100% liegt (wie eben S-Bahn Hannover bzw. Berlin), dann zieht das Argument "immer wieder wechselnde Ausstattung" doch nicht.

Oli-Wan wrote:

rayquaza wrote:

Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Zum ersten Teil der Frage: Ja klar, in einer externen Datenbank kann jeder sammeln, was er will. Auch die Betätigungskräfte von Zugtüren, Farbe der Sitzflächen im Zug, Vorhandensein und Funktion einer Klimaanlage, Ausstattung mit Kaugummiautomaten sowie Wasser- und Papiervorrat der Bordtoiletten.

Was willst du damit sagen? Dass Toiletten, Ticket und Getränkeautomaten irrelevant sind - so irrelevant wie deine ironischen Beispiele?

finde das zugmapping in osm auch verkehrt und kenne auch linien der frankenbahn,wo die ausstattung mit kartenautomaten nicht regelmäßig die gleiche ist.
Aber in einer externen DB (deutsche bahn? ;-))kann man sich sicherlich mit vielem versuchen

Frage an die, die sich jetzt dagegen ausgesprochen haben (chris66, Wolfgang B, Ryukia, wambacher): Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Wenn, dann bitte so etwas. Die Ausstattung der Züge gehört in eine extra Fahrzeugdatenbank, die dann über einen Klick auf das Zugsymbol abgerufen werden kann.

Dafür bräuchte man die Fahrplandaten, die viele VU leider nicht rausrücken wollen…

rayquaza wrote:

Frage an die, die sich jetzt dagegen ausgesprochen haben (chris66, Wolfgang B, Ryukia, wambacher): Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Könnt ich schon mit leben. Du musst aber damit leben können, daß dieser Verweis auf die externe DB schon mal verschwinden kann, wenn ein Mapper nicht aufpasst. Ein Back-Link von der externen DB -> OSM ist dagegen nicht sinnvoll, da sich OSM-IDs jederzeit ändern können.

Ein weiteres Problem mit externen Datenbanken - so sehr ich die befürworte - sehe ich darin, daß die Zugriffsmöglichkeiten problematisch sein könnten: Wer darf darin was erfassen oder ändern? Also die Benutzeradministration im Allgemeinen. Oauth wäre hier wohl von Interesse.

Gruss
walter

Nachtrag: Du bewegst dich ja im WIKI-Umfeld. Da sind die Links zum WIKI bei OSM etabliert und jeder Mapper "schleppt" die mit. Eine vernünftige Userverwaltung mit allem Drum und Dran ist ja auch vorhanden. Aber wenn jetzt "irgendwer" "irgendwo" eine externe DB aufbaut, hab ich schon so meine organisatorischen Bedenken. Technisch ist das aber kein Problem - solange ich selber das nicht realisieren muß 😉

rayquaza wrote:

Frage an die, die sich jetzt dagegen ausgesprochen haben (chris66, Wolfgang B, Ryukia, wambacher): Sammlung davon in einer externen DB und Einfügen einer ID in die OSM-Daten wäre in Ordnung?

Das kommt ganz drauf an. Wenn es ähnlich der Wikipedia ist könnte ich damit leben. Wenn nun aber 10 Fahrzeugdatenbanken entstehen und jeder seine ID in OSM kippt, dann wäre ich gegen eine ID.

Besser halte ich in jedem Fall, wenn man in der externen Datenbank zusätzliche Infos zur Identifizierung speichert. Also bei Bussen bspw. operator und ref. Das sollte ausreichen, um das Objekt in OSM eindeutig zu finden.

Evtl. sollte man auch erstmal über mögliche Anwendungen nachdenken und anhand dessen auch schauen, wie die Infos ausgewertet werden müssen.

wambacher wrote:

Ein weiteres Problem mit externen Datenbanken - so sehr ich die befürworte - sehe ich darin, daß die Zugriffsmöglichkeiten problematisch sein könnten: Wer darf darin was erfassen oder ändern? Also die Benutzeradministration im Allgemeinen. Oauth wäre hier wohl von Interesse.

Das legen typischerweise die Admins der externen DB fest.

aighes wrote:

Das legen typischerweise die Admins der externen DB fest.

klaro, aber wenn rayquaza fragt, ob das mit der externen DB ok wäre, gehe ich davon aus, daß er auch einen Bezug zu dieser DB hat - also eine Vorstellung davon hat, welche DB diesen Job machen könnte. Daraus folgt - für mich - auch, daß er sich um diese DB kümmert oder einen "Kümmerer" hat. Und DER sollte z.B. über Oauth nachdenken.

Gruss
walter