Taggingschema OpenRailwayMap

Mecki · 2012-05-23T19:48:33.000Z

Hallo Alex,

eine Frage und einen Tipp hätte ich für dich.

Wie hast du dir das mit den Zugsicherungssystemen gedacht? Üblicherweise werden Strecken mehrfach ausgerüstet, z.B. ETCS Level 2, ETCS Level 1, LZB, PZB gleichzeitig oder aber auch nur teilweise wie z.B. reine ETCS Level 2-Strecken (kein Zugang für nicht L2-Züge). Wie soll das getaggt werden und vor allem wo bekommt man die Infos her? Hat die DB ein Copyright auf ihre Zugangsvoraussetzungen?

Ein Link der dir vielleicht für genormte Begriffe in English (und anderen Sprachen) hilfreich sein könnte: http://www.electropedia.org/iev/iev.nsf/index?openform&part=821

Gruß
Mecki

Mecki · 2012-05-23T19:53:50.000Z

Ok die erste Frage hat sich erledigt im Bezug auf verschiedene Systeme, aber wie ist es bei den verschiedenen Leveln von ETCS?

tunnelbauer · 2012-05-24T07:47:10.000Z

Level 0: keine ETCS Einrichtungen vorhanden (hier befährt nur ein ETCS-fähiger Zug eine PZB-gesteuerte Strecke)
Level 1: Eurobalisen (diese netten kleinen gelben Kästchen im Gleis) + PZB - sprich wird bei Bestandsstrecken vorkommen, welche nachgerüstet sind und auch Verkehr ermöglichen müssen ohne ETCS (S-Bahn-Systeme zB)
Level 2: Eurobalisen ohne PZB (derzeit geplante Neubaustrecken - wenn es dann auch die nachgerüsteten Triebfahrzeuge gibt)
Level 3: Noch nicht definiert - somit nicht existent

Copyright? Wie wollen sie das schützen, wenn ich neben der Strecke mit dem Rad fahre und mir mittels GPS-Track die Abschnitte notiere? Könnte schwer werden… (Kartenabmalen ist sicher geschützt - aber an diese Karten mit Streckenklassifikationen kommst du eigentlich eh nur aus dem DB-Intranet ran, somit wäre es ein klarer Fall von Urheberrechtsverletzung)

Mecki · 2012-05-24T14:05:57.000Z

ich hatte mich nur gefragt wie eine kombination von leveln zu taggen sei.

Deine Ausführungen sind leider nur teilweise richtig.
Bei ETCS ist es so, dass die Fahrzeuge immer abwärtskompatibel sein müssen, die Stecken sind es jedoch nicht (dies gilt für die level 1, 2 und 3).

Nun zur beschreibung der level auf der strecke:
L0: keine zusicherung oder nicht so aktiv
LSTM: class b system, z.b. pzb, lzb, usw.
L1: erteilung von fahrterlaubnissen über schaltbare balisen im gleis
L2: erteilung von fahrterlaubnissen über funk, positionsmessung über fixe balisen, gleisfreimeldung konventionell
L3: wie L2, nur mit zugintegritätsüberwachung statt gleisfreimeldung (erste anwendung ertms regional in schweden)

Beliebige kombinationen der level, sowie mehrere LSTM, sind möglich.

Mit dem copyright wollte ich sagen, das selbst ein fachmann vom hinschauen nicht sagen kann ob eine strecke nur L1 oder L1 und L2 ausgerüstet ist.

Für fragen steh ich gerne zur verfügung.

Gruß
Mecki

P.s.: Sorry für die kleinschreibung aber das ging so schneller mit dem handy.

Jimmy_K · 2012-05-24T20:34:14.000Z

Ich habe keine Ahnung, ob es ausnahmen gibt, aber:
Signale vorhanden und im Betrieb: L1
Signale nicht vorhanden bzw. dunkel: L2

Lg

Mecki · 2012-05-25T11:07:13.000Z

Im Grunde braucht man die Signale bei L1 nur noch, um mitzuteilen ob (schon) eine Fahrterlaubnis in der Balise am Signal vorhanden ist. Mit Euroloop oder Radio-Infill bräuchte man auch in L1 gar keine Signale mehr, aber dann könnte man auch gleich L2 installieren das kommt billiger.

Gruß

tunnelbauer · 2012-05-25T11:34:52.000Z

Deswegen habe ich ja geschrieben, dass L1 eigentlich nur nachgerüstet ist auf aktuellen Bestandsstrecken ohne ETCS - L2 wird ja deswegen derzeit nur bei Neubaustrecken geplant um “sortenrein” zu fahren (wobei das natürlich auch immer wieder Probleme mit sich bringt -irgendwo ist ja immer die Schnittstelle zu einer Strecke mit anderem Level…) und sich die Signale zu “sparen” (ein sofortiger Rückbau der Signale um eine reine L2 Strecke zu erhalten ist ja auch kontraproduktiv).

Und die Aussage “Signale vorhanden und im Betrieb: L1” stimmt ja nur dann, wenn Balisen vorhanden sind - andernfalls ist es ja eine normale PZB gestützte Strecke.

Mecki · 2012-05-25T13:11:01.000Z

Schön es wäre so, leider haben die Spanier ihre Neubaustrecken alle mit L1 unterlegt als Rückfallebene. Oder wie in Algerien oder war es Tunesien, wo ein paar schlaue geschäftemacher gleich das Komplettpaket verkauft haben

errt · 2012-05-25T14:34:36.000Z

Ich werfe mal unbedarft in den Raum, was mir beim Durchlesen des vereinfachten Taggings so auffällt:

‘test’ scheint mir zu usage zu gehören, da ist wohl die Tabelle kaputt
Wo genau ist der Unterschied zwischen usage=highspeed und highspeed=yes?
name scheint mir an jedem way, der ein Gleis beschreibt, nicht sinnvoll. Da wäre eine Relation wohl der richtige Weg.
Ich bin nicht davon überzeugt, Links zu Bildern von Brücken, Tunneln und Bahnhöfen in der OSM-Datenbank zu haben. Zumindest bei wichtigen wäre der Wikipedia-Link wohl besser / ausreichend.
railway:manual beschreibt ein Attribut von Weichen, sieht man dem Schlüssel aber nicht an
Warum Kilometertafeln einmal pro Gleis? Das widerspricht dem ‘Ein reales Objekt = ein OSM-Objekt’ Gedanken und macht Dinge, wie die in OSM erfassten Kilometertafeln zu zählen unmöglich / schwer.
railway:milestone:catenary_mast: a) Ist diese Information sinnvoll? b) Wäre es nicht praktischer, den Mast als eigenes Objekt zu erfassen, sprich ein eigenes Tag dafür zu haben und dann im Zweifelsfall auszuwerten, ob der Knoten beide Tags trägt?
Signale: Hier verstehe ich die Intention des Eintragens auf dem Gleis besser, trotzdem erschiene es mir, auch wenn es komplizierter ist, besser, das Signal einzeln zu erfassen und per Relation dem Gleis zuzuordnen

rurseekatze · 2012-05-25T20:25:17.000Z

errt:

Ich werfe mal unbedarft in den Raum, was mir beim Durchlesen des vereinfachten Taggings so auffällt:

‘test’ scheint mir zu usage zu gehören, da ist wohl die Tabelle kaputt

Danke für den Hinweis!

errt:

Wo genau ist der Unterschied zwischen usage=highspeed und highspeed=yes?

Beim Korrigieren des Fehlers oben habe ich gesehen, dass ich noch beide Versionen drin hatte. Es soll eigentlich nur highspeed=yes sein.
Nun zur eigentlichen Frage: Nach einigen Diskussionen auf der Mailingliste habe ich das umgestellt. Dort wurde kritisiert, dass usage=highspeed zum einen mit der bisherigen Definition von usage=main kollidiert, zum anderen, dass es oft auch keine reinen Hochgeschwindigkeitsstrecken gibt.

errt:

name scheint mir an jedem way, der ein Gleis beschreibt, nicht sinnvoll. Da wäre eine Relation wohl der richtige Weg.

Erfassen wir auch jede Straße, die aus mehreren Ways besteht, als Relation? Da funktioniert doch auch ein name an jedem Way. Warum soll es also hier nicht funktionieren?

errt:

Ich bin nicht davon überzeugt, Links zu Bildern von Brücken, Tunneln und Bahnhöfen in der OSM-Datenbank zu haben. Zumindest bei wichtigen wäre der Wikipedia-Link wohl besser / ausreichend.

Es muss und soll ja auch nicht jede kleine Bahnunterführung mit Bild verlinkt werden. Das Tag ist vor allem für bedeutsame Brücken gedacht, wie etwa die Hohenzollernbrücke in Köln. Grundsätzlich könnte man da sagen, dass jede Brücke, die auch einen passenden Wikipediaartikel besitzt, ein Bild erhalten sollte (Eine Software kann allerdings anhand des Wikipediaartikels auch das erste Bild in diesem Artikel als Bild nehmen, falls vorhanden; siehe OpenLinkMap). Mit einem image-Tag aber lässt sich aber auch ein bestimmtes Bild verlinken.

errt:

railway:manual beschreibt ein Attribut von Weichen, sieht man dem Schlüssel aber nicht an

Zur Zeit wende ich das Tag nur bei Weichen an. Da das Tag aber keinen Namensbezug zu Weichen hat, lässt es sich bei Bedarf auch auf andere Dinge erweitern (Signale, Bahnübergänge, Drehscheiben, etc.).

errt:

Warum Kilometertafeln einmal pro Gleis? Das widerspricht dem ‘Ein reales Objekt = ein OSM-Objekt’ Gedanken und macht Dinge, wie die in OSM erfassten Kilometertafeln zu zählen unmöglich / schwer.

Solange man nur eine Bahnstrecke betrachtet, ließen sie die doppelten Steine entfernen. Sonst hast du natürlich Recht. Aber wie sollte man es sonst machen? Ein Stein in die Mitte der Gleise? Das macht wiederum das Auswerten und die Zuordnung des Steins zur passenden Strecke schwierig.

errt:

railway:milestone:catenary_mast: a) Ist diese Information sinnvoll? b) Wäre es nicht praktischer, den Mast als eigenes Objekt zu erfassen, sprich ein eigenes Tag dafür zu haben und dann im Zweifelsfall auszuwerten, ob der Knoten beide Tags trägt?

a) Das habe ich weitgehend aus einem bereits existierenden Proposal genommen. Ob es sinnvoll ist? Darüber lässt sich streiten. Für Simulatoren ist es eventuell nötig, damit der die Tafel an den Oberleitungsmast rendert und nicht als selbststehendes Schild.
b) Jeden Mast zu erfassen ist völlig übertrieben. Das kann und will niemand mehr erfassen und pflegen.

errt:

Signale: Hier verstehe ich die Intention des Eintragens auf dem Gleis besser, trotzdem erschiene es mir, auch wenn es komplizierter ist, besser, das Signal einzeln zu erfassen und per Relation dem Gleis zuzuordnen

Eine Erfassung per Relation hatte ich auch erst vorgesehen, aber dann schnell gemerkt, dass das Eintragen auf dem Gleis vor allem einfacher für den Mapper ist. Ich sehe keine Vorteile dieser Lösung gegenüber einer Erfassung per Relation.

Geogast · 2012-05-27T09:19:54.000Z

Von mir nur Kleinigkeiten:
Es gibt für Zahnradbahnen schon rack=*. Das Präfix “railway=*” ist nicht nötig, finde ich.
Dasselbe gilt für structure_gauge.
Bei gauge sollte man keinen Standardwert von 1435 setzten (Spalte ganz rechts). Das ist Standard für Mitteleuropa und anderswo; aber in anderen Länder überhaupt nicht. Gut, am Tagging-Schema ändert das ja nichts.

Jimmy_K · 2012-05-27T11:16:45.000Z

tunnelbauer:

Und die Aussage “Signale vorhanden und im Betrieb: L1” stimmt ja nur dann, wenn Balisen vorhanden sind - andernfalls ist es ja eine normale PZB gestützte Strecke.

Das war für mich logisch, hatte ich leider nicht erwähnt.

Je nach Quelle sind rund 3/4 aller weltweiten Bahnen in der Spurweite 1435mm, damit finde ich es als “Standard”-Wert angebracht.

EvanE · 2012-05-27T12:52:03.000Z

Geogast:

Von mir nur Kleinigkeiten:
Es gibt für Zahnradbahnen schon rack=*. Das Präfix “railway=*” ist nicht nötig, finde ich.

Für Zahnradbahnen gibt es bereits das Schema railway=rail/light_rail/tram/… plus traction=rack.

Eine Zahnradbahn kann ja als Eisenbahn alles mögliche sein.
Von der normalen Eisenbahn mit Standardspurweite über Schmalspurbahn mit 1000 oder 750mm Spurweite (in Europa der häufigste Fall) bis hin zu einer kurzen Strecke, die als Straßenbahn betrieben wird (z.B. Stuttgart) und in den Verkehrsverbund eingebunden ist.

Da die Eigenschaft “Zahnradbahn” nicht beschreibt, um was für eine Art Eisenbahn es sich handelt, braucht man als Zusatztagg “traction=rack” oder wenn’s denn sein muss auch “rack=yes” an einem ‘normalen’ railway=*.

Edbert (EvanE)

Geogast · 2012-05-27T14:01:57.000Z

EvanE:

Geogast:

Von mir nur Kleinigkeiten:
Es gibt für Zahnradbahnen schon rack=*. Das Präfix “railway=*” ist nicht nötig, finde ich.

Für Zahnradbahnen gibt es bereits das Schema railway=rail/light_rail/tram/… plus traction=rack.

Eine Zahnradbahn kann ja als Eisenbahn alles mögliche sein.
Von der normalen Eisenbahn mit Standardspurweite über Schmalspurbahn mit 1000 oder 750mm Spurweite (in Europa der häufigste Fall) bis hin zu einer kurzen Strecke, die als Straßenbahn betrieben wird (z.B. Stuttgart) und in den Verkehrsverbund eingebunden ist.

Da die Eigenschaft “Zahnradbahn” nicht beschreibt, um was für eine Art Eisenbahn es sich handelt, braucht man als Zusatztagg “traction=rack” oder wenn’s denn sein muss auch “rack=yes” an einem ‘normalen’ railway=*.

Edbert (EvanE)

Ich hab mich verschrieben: Ich meinte rack=* mit Praefix, also railway:rack=* ist unnoetig.
Klar, rack=* ist ein Zusatztag für railway=*.

EvanE · 2012-05-27T14:18:57.000Z

Geogast:

Ich hab mich verschrieben: Ich meinte rack=* mit Praefix, also railway:rack=* ist unnoetig.
Klar, rack=* ist ein Zusatztag für railway=*.

Dann ist ja alles klar.

Edbert (EvanE)

rurseekatze · 2012-05-30T19:15:42.000Z

Habe das mit den Präfixen vor rack und structure_gauge korrigiert.

GeorgFausB · 2012-05-31T06:17:46.000Z

Moin,

rurseekatze:

errt:

railway:manual beschreibt ein Attribut von Weichen, sieht man dem Schlüssel aber nicht an

Zur Zeit wende ich das Tag nur bei Weichen an. Da das Tag aber keinen Namensbezug zu Weichen hat, lässt es sich bei Bedarf auch auf andere Dinge erweitern (Signale, Bahnübergänge, Drehscheiben, etc.).

Zwei Punkte kann man vielleicht nochmal überdenken:

Was versteht der Leser unter manual - es könnte m. E. mißverstanden werden:

Muskelkraft - das betrifft ja alles mit mechanischen Antrieben, aber eben sowohl ortsgestellt wie auch ferngestellt.

Ortsgestellt - das gibt es wiederum auch mit elektrischem Antrieb.

Mir fällt allerdings auch kein besserer englischer Begriff ein ... :/

switch ist amerikanisches Englisch, britisches Englisch wäre m. W. eher points (seltener turnouts).

Gruß
Georg

geri-oc · 2012-05-31T07:56:42.000Z

Frage zu railway=* (Hier: Weißeritztalbahn Freital-Hainsberg - Kipsdorf) von einem “Bahnlaien”:

narrow_gauge ist Schmalspurbahn → richtig

Die Bezeichnungen proposed, construction, preserved, disused, abandoned und razed kollidieren aber jetzt mit railway. Auch ändern sie sich.
Wären diese “Bezeichnungen” nicht wie bisher besser?

Ich nutzte bisher:

Dippoldiswalde - Obercarsdorf
construction=yes
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Freital - Dippoldiswalde (und Obercarsdorf - Schmiedeberg)
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Schmiedeberg - Kipsdorf:
proposed=yes
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Gut finde ich noch den Hinweis zu usage in Bahnhöfen.

Die Weiche als Punkt railway=switch (oder junction?)
Zur Betriebsart würde ich wieder auf switch=* (mechanic, electric, …) zurückgreifen. Das wäre dann auch für milesstone, signal, … m.E. nach geeignet (positition, direction, …)

railway=switch
switch=eletric

und dann würde ich für Laien noch etwas reduzieren z.B:
uic_ref
on_demand
railway:station_category
operator
network

sonst “erschrickt der Laie”. Also alles was man nicht gleich direkt vor Ort findet, dafür gibt es ja die ausführliche Seite.

rurseekatze · 2012-05-31T16:56:53.000Z

GeorgFausB:

Was versteht der Leser unter manual - es könnte m. E. mißverstanden werden:

Muskelkraft - das betrifft ja alles mit mechanischen Antrieben, aber eben sowohl ortsgestellt wie auch ferngestellt.

Ortsgestellt - das gibt es wiederum auch mit elektrischem Antrieb.

Mir fällt allerdings auch kein besserer englischer Begriff ein ... :/

Stimmt, das ist doppeldeutig und sollte genauer definiert werden. Ich würde vorschlagen, dass “manual” ortsbedient meint und die Art des Antriebs (Muskelkraft, elektrisch) in ein anderes Tag kommt. Dieses Tag könnte man dann auch für Signale und Schranken verwenden und damit angeben, ob z.B. eine Schranke per Motor oder Kurbel bedient wird.
Ich würde vorschlagen, die Tags wie folgt zu ändern:

railway:local=yes/no (ortsbedient)
railway:operation=manual/engine (Antriebsart)

Hat jemand vielleicht bessere Begriffe?

GeorgFausB:

switch ist amerikanisches Englisch, britisches Englisch wäre m. W. eher points (seltener turnouts).

railway=point wird laut Taginfo bisher erst 22 mal verwendet, railway=switch dagegen schon fast 24.000 mal. Außerdem ist es doch egal, ob es britisches oder amerikanisches Englisch ist, oder?

geri-oc:

Frage zu railway=* (Hier: Weißeritztalbahn Freital-Hainsberg - Kipsdorf) von einem “Bahnlaien”:

narrow_gauge ist Schmalspurbahn → richtig

Die Bezeichnungen proposed, construction, preserved, disused, abandoned und razed kollidieren aber jetzt mit railway. Auch ändern sie sich.
Wären diese “Bezeichnungen” nicht wie bisher besser?

Ich nutzte bisher:

Dippoldiswalde - Obercarsdorf
construction=yes
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Freital - Dippoldiswalde (und Obercarsdorf - Schmiedeberg)
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Schmiedeberg - Kipsdorf:
proposed=yes
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Bezeichnungen wie bisher? Bisher unterscheidet zum Beispiel Mapnik schon zwischen railway=abandoned oder railway=construction.

Nach meinem Schema würde ich die Abschnitte folgendermaßen taggen:

Dippoldiswalde - Obercarsdorf
electrified=no
gauge=750
name=Weißeritztalbahn
railway=construction

Freital - Dippoldiswalde (und Obercarsdorf - Schmiedeberg)
electrified=no
gauge=750
name=Weißeritztalbahn
railway=narrow_gauge

Schmiedeberg - Kipsdorf:
electrified=no
gauge=750
name=Weißeritztalbahn
railway=proposed

Das narrow_gauge ist sowieso nur für den Renderer da, damit er die Strecke anders rendern kann. Die Spurweite aber ist sowieso schon in einem eigenen Tag angegeben.

Das Ganze ist vergleichbar mit Straßen in Planung: Die werden auch erstmal nur mit highway=proposed getaggt und der Straßentyp wird in einem eigenen Tag angegeben. Dort taggt man auch nicht highway=motorway und construction=yes, weil eine Autobahn in der Planung eben keine Autobahn ist und nicht das Tag einer befahrbaren Autobahn bekommen sollte.

geri-oc:

Gut finde ich noch den Hinweis zu usage in Bahnhöfen.

Die Weiche als Punkt railway=switch (oder junction?)
Zur Betriebsart würde ich wieder auf switch=* (mechanic, electric, …) zurückgreifen. Das wäre dann auch für milesstone, signal, … m.E. nach geeignet (positition, direction, …)

railway=switch
switch=eletric

Mein Vorschlag dazu siehe oben.
railway:switch ist schon für den Weichentyp vergeben und dann noch ein switch=* finde ich etwas unschön und nicht eindeutig in der Bedeutung (meine Meinung).

geri-oc:

und dann würde ich für Laien noch etwas reduzieren z.B:
uic_ref
on_demand
railway:station_category
operator
network

sonst “erschrickt der Laie”. Also alles was man nicht gleich direkt vor Ort findet, dafür gibt es ja die ausführliche Seite.

OK, habe ich teilweise entfernt. on_demand, operator und network sind aber auch für den Bahnlaien verständlich und erkennbar.

Gruß
Alex

EvanE · 2012-05-31T21:11:10.000Z

rurseekatze:

GeorgFausB:

switch ist amerikanisches Englisch, britisches Englisch wäre m. W. eher points (seltener turnouts).

railway=point wird laut Taginfo bisher erst 22 mal verwendet, railway=switch dagegen schon fast 24.000 mal. Außerdem ist es doch egal, ob es britisches oder amerikanisches Englisch ist, oder?

Während switch in Verbindung mit railway wohl den meisten Leuten mit Basis Englisch verständlich sein wird, ist das bei dem korrekten britischen Begriff “point” nicht mal für Bahn-Interessierte gegeben. Von daher halte ich das für eine begründete Abweichung von der Regel. Schließlich sollen die Schlüssel und Werte für die Mehrheit der OSM-Mapper nachvollziehbar sein.

rurseekatze:

geri-oc:

und dann würde ich für Laien noch etwas reduzieren z.B:
uic_ref
on_demand
railway:station_category
operator
network

sonst “erschrickt der Laie”. Also alles was man nicht gleich direkt vor Ort findet, dafür gibt es ja die ausführliche Seite.

OK, habe ich teilweise entfernt. on_demand, operator und network sind aber auch für den Bahnlaien verständlich und erkennbar.

Sehe ich auch so. uic_ref kann man meiner Meinung nach auch für Laien drin lassen.
Man muss nur a) erklären, was das ist und b) sagen: Wenn du es nicht weißt, dann lasse es einfach weg.
(Punkt b) gilt ja auch für andere Eigenschaften.)

JM2C
Edbert (EvanE)