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.
Oh, das wäre wirklich ein Gegenbeispiel. Wo ist das denn so?
S-Bahn RheinNeckar.
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. 
Nischt.
Was hat die Ausstattung von Zügen mit OSM zu tun? Eine Schnapsidee. Sind schon alle Sackerl-fürs-Gackerl-Spender gemappt?
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 =^_^=
“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.
+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
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.
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.
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.
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.
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.