Taggingschema OpenRailwayMap

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 … m&part=821

Gruß
Mecki

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

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)

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.

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

Lg

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ß

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.

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 😉

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

errt wrote:

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 wrote:

- 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 wrote:

- 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 wrote:

- 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 wrote:

- 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 wrote:

- 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 wrote:

- 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 wrote:

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

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.

tunnelbauer wrote:

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.

Geogast wrote:

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)

EvanE wrote:

Geogast wrote:

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=*.

Geogast wrote:

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)

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

Moin,

rurseekatze wrote:

errt wrote:

- 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

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.

GeorgFausB wrote:

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 wrote:

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 wrote:

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 wrote:

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 wrote:

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

rurseekatze wrote:

GeorgFausB wrote:

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 wrote:

geri-oc wrote:

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)

Hallo zusammen,

ich habe eine frage über railway=disused und usage=* Tags. Entschuldigung, wenn ich in falsche Theme schreibe.

Zum Biespiel, wir haben ein Gleis, das früher zum Industriezwecken benutzt wurde, aber momentan nicht benutzt wird. Wie soll man es taggen? Wie ich verstehe, das Gleis soll railway=disused + usage=industrial haben.
Aber... Da es jetzt nicht benutzt ist, ist es richtig, usage=*-Tag anzuwenden? Meiner Meinung nach nein, denn dieses Gleis auf keine Weise benutzt wird!
Ich vorschläge, mit railway=disused nicht usage=*, sondern nur disused:usage=* zu benutzen und nur der letzte Tag an OpenRailwayMap zu unterstützen.

Was denkt ihr darüber?

Viele Grüße
Eduard

... irrtümlichen Beitrag gelöscht...

Hallo Eduard,

edward17 wrote:

Hallo zusammen,

ich habe eine frage über railway=disused und usage=* Tags. Entschuldigung, wenn ich in falsche Theme schreibe.

Zum Biespiel, wir haben ein Gleis, das früher zum Industriezwecken benutzt wurde, aber momentan nicht benutzt wird.

Ist es eine echte Industrie-, Bergwerks-, oder Hafenbahn oder nur ein Anschlussgleis vom Bahnhof bzw. der freien Strecke zu einem Gewerbebetrieb oder einer Kaserne? Die Nord-Süd-Bahn (Tagebau Garzweiler–Kraftwerk Goldenberg), die Gleisanlagen in großen Chemiewerken wie Ludwigshafen, Leverkusen oder Leuna und die Netze von Hafen- und Industriebahnen sind usage=industrial, während einfach Anschlussgleise service=spur (OHNE usage=*) sind.

edward17 wrote:

Wie soll man es taggen? Wie ich verstehe, das Gleis soll railway=disused + usage=industrial haben.
Aber... Da es jetzt nicht benutzt ist, ist es richtig, usage=*-Tag anzuwenden? Meiner Meinung nach nein, denn dieses Gleis auf keine Weise benutzt wird!

usage=* kann man nicht 1:1 in Nutzung übersetzen. Es beschreibt eher die Widmung – usage=main für Hauptbahnen (das sind auch Strecken wie Eppingen–Heilbronn–Crailsheim oder Dessau Hbf–Güsten), usage=branch für Nebenbahnen, usage=test für Teststrecken, usage=military für Militärbahnen usw.

Ich vorschläge, mit railway=disused nicht usage=*, sondern nur disused:usage=* zu benutzen und nur der letzte Tag an OpenRailwayMap zu unterstützen.

Was denkt ihr darüber?

disused:usage=* würde ich lieber für einen anderen Zweck verwenden. Es gibt Strecken, die stillgelegt werden, von denen aber die ersten paar Hundertmeter noch als Anschlussgleis genutzt werden (z.B. die Untere Queichtalbahn Landau (Pfalz) Hbf–Germersheim bei Landau). Da usage=* und service=* an einer Strecke dem gebräuchlichen Taggingschema widersprechen [1], habe ich dort railway=rail + service=spur + disused:usage=main getaggt, da die Strecke nur stillgelegt ist und recht leicht als Hauptbahn wieder betrieben werden könnte (die Widmung wird erst mit der Entwidmung aufgehoben).

Viele Grüße

Michael

[1] Nur die Kombinationen usage=industrial/military + service=* sind derzeit als "zulässig" festgelegt.

Hallo Michael,

vielen Dank für die Räte!

Nakaner wrote:

Ist es eine echte Industrie-, Bergwerks-, oder Hafenbahn oder nur ein Anschlussgleis vom Bahnhof bzw. der freien Strecke zu einem Gewerbebetrieb oder einer Kaserne?

Das ist einfache Anschlussgleis von der freien Strecke zu einem Gewerbebetrieb. Und es hat service=spur. Es ist mir entfallen, darüber zu schreiben.

Nakaner wrote:

einfach Anschlussgleise service=spur (OHNE usage=*) sind.

Kannst du bitte erklären, warum? 🙂 Ich habe über diese Regel nie gehört.

Viele Grüße
Eduard