Alles genau hier zu erklären, wäre wahrscheinlich ein bisschen zu umfangreich.
Schaut es euch einfach an und bei Verständnisfragen oder Fragen wie “Warum
soll etwas auf diese Weise getaggt/erfasst werden?” kann ich euch einzelne
Dinge genauer erläutern.
Sollten hier vorerst keine weiteren Ergänzungswünsche oder Kritikpunkte
auftreten, werde ich mir die Arbeit machen, die Seiten ins Englische zu
übersetzen und als Proposal einzutragen.
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?
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.
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.
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
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.
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?
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.
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.).
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.
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.
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.
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=*.
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?
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.
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=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?
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:
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.
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).
OK, habe ich teilweise entfernt. on_demand, operator und network sind aber auch für den Bahnlaien verständlich und erkennbar.
(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)
