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.
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.
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.
Wenn es Eigenschaften eines geografischen, d.h. ortsfesten Objektes (Parkplatz, Mautstelle) sind: Ja.
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.
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.
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.
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.
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.
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?
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…
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.
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.
Habe gestern meinen ersten HKTS erfasst. Einer von knapp über 5000 und damit der dritthäufigste 'Verkaufs’automat, nur übertroffen von Zigaretten und Parkscheinen.
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.
