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