Welche Tags für Bahngleise?

seawolff · 2012-02-18T23:52:34.000Z

FK270673:

seawolff:

“gauge=1435”: brauchen wir den Standardwert in Deutschland?

Bitte betrachte die folgende Karte und überlege mal, was passiert, falls jemand die gauge=1435 löschen würde:
http://www.itoworld.com/product/data/ito_map/main?view=159&lat=50.772964721123444&lon=15.347468620199022&zoom=5

Dann wären die roten Linien grau und alle Strecken mit abweichender Spurweite wären deutlicher erkennbar

ITO stellt auch Karten zur Verfügung, die lanes=2 oder lit=no oder layer=0 anzeigen. Trotzdem werden diese Werte meist weggelassen.

Gibt es außer den ITO-Karten, die ja eher Tools für Mapper als für Endnutzer sind, Anwendungen, die gauge=1435 auswerten?

Viele Grüße
Stephan

seawolff · 2012-02-19T00:40:19.000Z

viw:

seawolff:

In Russland oder an Kontaktpunkten mit Schmalspurbahnen ist “gauge” natürlich sinnvoll.

Du tagst nur die Grenze und den Rest? Das ist sinnlos. Entweder es gibt einen Standard und der abweichende Rest muss getaggt werden. Da wir ein Weltweites Projekt sind weiß ich nicht warum Spanien Russland oder Südafrika nicht ihren “Standard” haben sollen. Damit muss das überall getaggt werden.

Dass Abweichungen vom Standardwert (in diesem Fall gauge=1435) getaggt werden müssen, ist selbstverständlich. Die Frage ist nur, wann der Standardwert explizit sinnvoll ist.

Ich schreibe den Standardwert üblicherweise explizit, wenn es Missverständnisse geben kann. Vor und hinter einem Straßenstück mit “lanes=4” schreibe ich auch “lanes=2”, bei primary bis motorway setze ich lanes, bei kleineren Straßen meist nicht. Wenn es in England eine Straße mit Rechtsverkehr gibt, würde ich es explizit erwähnen, in Deutschland nicht.

Das Wiki sagt zu Key:gauge : “As the “Standard gauge” of 1435mm is used on most of the world’s railways, it is suggested that mappers concentrate on adding this tag to railways that differ from this standard.” Deshalb wollte ich wissen, ob eine Anwendung den Wert benötigt.

viw:

seawolff:

viw:

Ich halte es nicht für sinnvoll. Denn es gibt viele verschiedene Möglichkeiten für Züge auf dem Gegengleis zu fahren. Notfalls sogar ohne Signale nur mit Befehl.

Das Argument gilt aber auch für jede Einbahnstraße.

Ich glaube kaum! Fahren auf Befehl ist ein durchaus gängiges Betriebsverfahren bei der Bahn. Aber es gibt auch verschiedene andere Signale. Alleine weil jetzt auf der Strecke keines zu sehen ist reicht da eben nicht aus.

Auf der Strecke Neumünster-Kiel fehlen auch die Gleiskontakte in Gegenrichtung, so dass bei Bauarbeiten ein Streckenposten an jedem Übergang steht. Da ist Fahren auf Befehl vermutlich nicht erlaubt. Ich weiß nicht, ob dies auf anderen zweigleisigen Strecken auch so ist.

Viele Grüße
Stephan

berndw · 2012-02-19T08:19:50.000Z

EvanE:

Geogast:

Wie taggt man eigentlich, dass ein Bahnübergang beschrankt ist oder nicht? Ich hab da schon so viel gelesen und gesehen…

Es gab auch Leute, die ein barier=(lift_)gate links und rechts der Gleise auf kreuzende Straße gesetzt haben. Eine Lösung, die ich erst einmal für nahe genug an der Wirklichkeit hielt, aber bei allen mir bekannten Beispielen hat das jemand wieder entfernt.

Was meinen denn berndw oder ajoessen (zwei aktive Bahn-Mapper) zu dem Problem?

Hi Edbert

Bei mir happert es eigentlich eher an sprachlichen Mängeln

Wenn mir jemand die englischen Wörter für Halbschranke, alternativ einseitige und beidseitige Schranke, bzw die für Vollschranke mit einem Baum nennen könnte?

Ansonsten würde ich barrier=liftgate:[single_full|single_half|double_half] und traffic_sign=[(alternating_)flashing|yes] nicht als falsch ansehen.

Noch was zu den Spurweiten, ich persönlich setze gauge=1435, da es der deutschen Realität entspricht, standard ist mir suspekt, da es anderen meinen Standard aufzwingt, z.B Russen, Spaniern und Portugiesen.

m2c
Bernd

berndw · 2012-02-19T08:31:44.000Z

seawolff:

Auf der Strecke Neumünster-Kiel fehlen auch die Gleiskontakte in Gegenrichtung, so dass bei Bauarbeiten ein Streckenposten an jedem Übergang steht. Da ist Fahren auf Befehl vermutlich nicht erlaubt. Ich weiß nicht, ob dies auf anderen zweigleisigen Strecken auch so ist.

Viele Grüße
Stephan

Fahren auf Befehl geht immer solange die Schienen da sind.

Und das Prinzip der doppelten Sicherheit bleibt dann gewahrt, da sowohl der FDL und der Tf, sowie Tf und Straßenverkehr bestimmte Regeln einhalten müssen.

Der BüP steht dort, damit weiterhin, wenn möglich, auf Signal gefahren werden kann, obwohl die Schrankenanlage außer Betrieb ist.

Bernd

seawolff · 2012-02-19T11:50:34.000Z

berndw:

Fahren auf Befehl geht immer solange die Schienen da sind.

Danke, jetzt habe ich wieder etwas über das Eisenbahnsystem gelernt.

Sollte man die Vorzugsrichtung eines Gleises in einem anderen Tag als oneway ablegen, oder ist diese Information irrelevant?

Viele Grüße
Stephan

berndw · 2012-02-19T13:17:25.000Z

seawolff:

berndw:

Fahren auf Befehl geht immer solange die Schienen da sind.

Danke, jetzt habe ich wieder etwas über das Eisenbahnsystem gelernt.

Sollte man die Vorzugsrichtung eines Gleises in einem anderen Tag als oneway ablegen, oder ist diese Information irrelevant?

Viele Grüße
Stephan

IMHO ist oneway irreführend. Oneway bedeutet, dass immer nur in einer Richtung gefahren wird, aber auf Befehl geht es auch anders rum, das wird Dir jeder Eisenbahner bestätigen.

In Deutschland ist das Regelgleis rechts und die überwiegende Zahl der Streckengleise ist nicht für eine andere Fahrtrichtung, zumindest signalmäßig, ausgelegt. ABS und NBS sind die Ausnahme, dort könnte man ein entsprechendes Tag setzen, das Regelgleis ist aber weiterhin rechts. Manche Hauptstrecke z.B. die 2324 hat streckenweise GWB o.ä., aber das ändert sich praktisch von Bahnhof zu Bahnhof.

Meine persönliche Meinung am Rande:
Ich halte gar nichts von Richtungsangaben bei Eisenbahnen, da die erstens nicht zum allgemeinen Routen gebraucht werden, zweitens für den Otto-Normal-Mapper nicht verifizierbar und drittens nicht unter allen Umständen korrekt sind.

Bernd

EvanE · 2012-02-19T14:12:44.000Z

berndw:

EvanE:

Geogast:

Wie taggt man eigentlich, dass ein Bahnübergang beschrankt ist oder nicht? Ich hab da schon so viel gelesen und gesehen…

Es gab auch Leute, die ein barier=(lift_)gate links und rechts der Gleise auf kreuzende Straße gesetzt haben. Eine Lösung, die ich erst einmal für nahe genug an der Wirklichkeit hielt, aber bei allen mir bekannten Beispielen hat das jemand wieder entfernt.

Was meinen denn berndw oder ajoessen (zwei aktive Bahn-Mapper) zu dem Problem?

Bei mir happert es eigentlich eher an sprachlichen Mängeln
Wenn mir jemand die englischen Wörter für Halbschranke, alternativ einseitige und beidseitige Schranke, bzw die für Vollschranke mit einem Baum nennen könnte?

Ansonsten würde ich barrier=liftgate:[single_full|single_half|double_half] und traffic_sign=[(alternating_)flashing|yes] nicht als falsch ansehen.

Hallo Bernd

Ich habe es mal auf dict.leo.org nachgesehen. Es scheint auf half/full barrier hinaus zu laufen.
Ich würde es wie folgt Taggen:

barrier=railway_barrier
railway_barrier=full/half/double_half/…

Das macht das Auswerten meines Erachtens einfacher. Wer an den Details nicht interessiert ist braucht nur das allgemeine barrier=… auszuwerten. Für Anrufschranken kann man eventuell noch on_demand=yes ergänzen.

Ähnlich bei den Verkehrszeichen:

traffic_sign=railway_crossing
railway_crossing=sign_only/flash_lights/traffic_signals/…

Edbert (EvanE)

Tordanik · 2012-02-19T15:39:46.000Z

Zum Thema Schranken an Bahnübergängen möchte ich noch auf den existierenden (aber nicht sehr oft verwendeten) Vorschlag

crossing:barrier = no/full/half

vorschlagen, als Zusatztag von railway=level_crossing.

Stammt offenbar aus diesem uralten Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Railway

EvanE:

Ich würde es wie folgt Taggen:

barrier=railway_barrier

railway_barrier=full/half/double_half/…

Das macht das Auswerten meines Erachtens einfacher. Wer an den Details nicht interessiert ist braucht nur das allgemeine barrier=… auszuwerten. Für Anrufschranken kann man eventuell noch on_demand=yes ergänzen.

Die Verwendung des barrier-Schlüssels ist u.U. problematisch, weil Barrieren Auswirkungen aufs Routing haben können - je nach access-Tags. Die genaue Auswertung durch Router ist ungeklärt, es ist sogar an verschiedenen Stellen im Wiki die Auffassung dokumentiert, dass ohne ausdrückliche Angabe von Access-Tags bei einem unbekannten barrier-Typ angenommen werden soll, dass er die Straße komplett und dauerhaft blockiert (Default access=no).

Bahnschranken sollten normalerweise keinen Einfluss aufs Routing haben. Man handelt sich durch die Einsortierung als barrier also womöglich ein paar vermeidbare praktische Probleme ein. Kann man meinetwegen trotzdem machen, wollte ich nur gesagt haben.

Ansonsten ist natürlich eine relevante Entscheidung, ob man die Schranke als Attribut des Bahnübergangs oder als eigenständigen Knoten erfasst. Spontan sehe ich bei beiden Ansätzen Vor- und Nachteile.

Nachteil separat getaggter Schranken: Man kann schwer nach “beschrankten Bahnübergängen” filtern, und ein Renderer kann sie entsprechend nicht ohne Weiteres mit einem eigenen Icon darstellen. Es ist auch unklar, in welche Richtung eine Schranke öffnet.
Vorteil separat getaggter Schranken: Die Darstellung mehrgleisiger Bahnübergänge wird leichter.

EvanE · 2012-02-19T19:42:37.000Z

Tordanik:

Zum Thema Schranken an Bahnübergängen möchte ich noch auf den existierenden (aber nicht sehr oft verwendeten) Vorschlag
crossing:barrier = no/full/half
vorschlagen, als Zusatztag von railway=level_crossing.
Stammt offenbar aus diesem uralten Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Railway

Gefällt mir nicht so richtig, weil crossing=… schon als Zusatz-Tagg für highway=crossing verwendet wird.
Das zweite Problem sind dann wieder die mehrgleisigen Bahnstrecken.
Ein Vorzug ist jedoch, dass man das Fehlen von Bahnschranken explizit angeben kann.

Tordanik:

EvanE:

Ich würde es wie folgt Taggen:

barrier=railway_barrier

railway_barrier=full/half/double_half/…

Die Verwendung des barrier-Schlüssels ist u.U. problematisch, weil Barrieren Auswirkungen aufs Routing haben können - je nach access-Tags. Die genaue Auswertung durch Router ist ungeklärt, es ist sogar an verschiedenen Stellen im Wiki die Auffassung dokumentiert, dass ohne ausdrückliche Angabe von Access-Tags bei einem unbekannten barrier-Typ angenommen werden soll, dass er die Straße komplett und dauerhaft blockiert (Default access=no).

Bahnschranken sollten normalerweise keinen Einfluss aufs Routing haben. Man handelt sich durch die Einsortierung als barrier also womöglich ein paar vermeidbare praktische Probleme ein. Kann man meinetwegen trotzdem machen, wollte ich nur gesagt haben.

Dein Einwand ist berechtigt, also sollte man ein access=yes bei diesem Vorschlag noch ergänzen.
Auf der anderen Seite kann eine Bahnschranke ein Indiz für einen Routing-Algorytmus werden, eine Zeitstrafe auf das Stück zwischen zwei Schranken zu setzen.
In der Hinsicht wäre es vermutlich besser, das Straßenstück gesondert mit z.B. railroad_crossing=yes ähnlich Brücken und Tunnels zu taggen.

Tordanik:

Ansonsten ist natürlich eine relevante Entscheidung, ob man die Schranke als Attribut des Bahnübergangs oder als eigenständigen Knoten erfasst. Spontan sehe ich bei beiden Ansätzen Vor- und Nachteile.

Nachteil separat getaggter Schranken: Man kann schwer nach “beschrankten Bahnübergängen” filtern, und ein Renderer kann sie entsprechend nicht ohne Weiteres mit einem eigenen Icon darstellen. Es ist auch unklar, in welche Richtung eine Schranke öffnet.

Vorteil separat getaggter Schranken: Die Darstellung mehrgleisiger Bahnübergänge wird leichter.

Wie gerade erwähnt, wäre eventuell das Aufteilen der Straße mit entsprechendem Tagging die bessere Lösung.
Ob man dann die Schranken als Punkte setzt oder als Zusatz-Taggs an dieses Straßenstück, müsste man noch überlegen.

Edbert (EvanE)

rurseekatze · 2012-02-20T12:21:30.000Z

Bezüglich Bahnübergängen hatte ich mir auch schon Gedanken gemacht:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Bahn.C3.BCbergang

Was haltet ihr von meinem Taggingvorschlag? Sollte ich noch etwas ergänzen?

Beim Tagging von Gleisen gibt es ebenfalls ein von mir konzipiertes Schema, das u.a. bei usage=* noch etwas ergänzt wurde.
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Gleis

Für Falschfahrten/Gleiswechselbetrieb würde ich folgendes Tagging vorschlagen:

railway:bidirectional=

regular (beide Fahrtrichtungen mit Signalen ausgestattet, regulärer Betrieb auf Gegengleis möglich / GWB)
signals (nur eine Fahrtrichtung mit Signalen ausgestattet bzw. Falschfahrt mit Signalen geregelt / SFB)
possible (Signaltechnisch keine Falschfahrt möglich, aber gegen Befehl möglich)

EvanE · 2012-02-20T17:47:51.000Z

rurseekatze:

Bezüglich Bahnübergängen hatte ich mir auch schon Gedanken gemacht:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Bahn.C3.BCbergang

Was haltet ihr von meinem Taggingvorschlag? Sollte ich noch etwas ergänzen?
…

Hallo Alexander

Das ist das Problem, wenn man eine Sache nur aus einem Blickwinkel (hier die Eisenbahn) betrachtet.

An mehrgleisige Bahnübergängen sind alle Einträge mehrfach zu setzen.
Dabei ist der Bahnübergang eine Einheit.
Die Straßensicht
“Wo ist die Schranke / das Verkehrszeichen / wo besser nicht stehen bleiben?”
bleibt außen vor.

Was mich an deinem gesamten OpenRailwayMap Vorschlag wirklich stört, ist die Behandlung der Zugsicherung. Für jedes System definierst du einen eigenen Schlüssel mit yes/no als Wert. Im Grunde geht es doch nur darum welches Sicherungssystem verwendet wird. Mehrere parallele Sicherungssysteme können über eine fortlaufende Nummer im Schlüssel erfasst werden.
(Diese Schlüssel mit yes/no als einzigen Wert empfand ich schon bei Public_Transport als großen Mangel.)

Das wäre besser mit railway:signaling:= mit x eine einstellige Zahl, für den Fall dass es mehr als ein Sicherungssystem gibt. Als Name kämen auch railway:train_protection: oder railway:train_control: in Frage.

Edbert (EvanE)

Tordanik · 2012-02-20T18:43:36.000Z

rurseekatze:

Was haltet ihr von meinem Taggingvorschlag? Sollte ich noch etwas ergänzen?

Konkret zum Thema Bahnschranken wäre wohl ein zusätzlicher double_half-Wert o.ä. zur Unterscheidung zwischen einfachen und doppelten Halbschranken noch sinnvoll.

EvanE:

Wie gerade erwähnt, wäre eventuell das Aufteilen der Straße mit entsprechendem Tagging die bessere Lösung.

Wäre es also ein denkbarer Ansatz, bei mehrgleisigen Übergängen das betroffene Straßenstück mit den Infos zu Beschrankung etc. zu taggen? Also einfach die diesbezüglichen Tags, die man sonst an den Kreuzungsknoten hängen würde, auf ein Straßenstück anzuwenden?

Ich sähe bei einem solchen Ansatz spontan erst einmal keine größeren Probleme.

EvanE · 2012-02-20T19:13:51.000Z

Tordanik:

EvanE:

Wie gerade erwähnt, wäre eventuell das Aufteilen der Straße mit entsprechendem Tagging die bessere Lösung.

Wäre es also ein denkbarer Ansatz, bei mehrgleisigen Übergängen das betroffene Straßenstück mit den Infos zu Beschrankung etc. zu taggen? Also einfach die diesbezüglichen Tags, die man sonst an den Kreuzungsknoten hängen würde, auf ein Straßenstück anzuwenden?

Ich sähe bei einem solchen Ansatz spontan erst einmal keine größeren Probleme.

Also konkret:

highway= ( = bekannte Standard-Werte)
railway_crossing=yes
railway_barrier=full/half/double_half/no
(Namen sind natürlich verhandelbar)

Lass mal überlegen, wie Renderer und Router heute damit umgehen.

Renderer:
Die Straße wird wie bisher gerendert,
Knoten mit railway=level_crossing werden dargestellt.
Router:
Straße wird wie bisher genutzt, Abwertung wegen Knoten mit
railway=level_crossing wird wie bisher gemacht oder unterlassen.

Das sollte also auf bestehende Anwendungen keinen negativen Einfluss haben.
Bis so etwas dann aber zu einer Änderung der Darstellung oder der Routing-Gewichte führt, dürfte allerdings einige Zeit dauern. Das hängt natürlich auch von der Geschwindigkeit der Verbreitung dieser Tagging-Variante ab.

Edbert (EvanE)

Fabi2 · 2012-02-20T22:41:46.000Z

EvanE:

Was mich an deinem gesamten OpenRailwayMap Vorschlag wirklich stört, ist die Behandlung der Zugsicherung. Für jedes System definierst du einen eigenen Schlüssel mit yes/no als Wert. Im Grunde geht es doch nur darum welches Sicherungssystem verwendet wird. Mehrere parallele Sicherungssysteme können über eine fortlaufende Nummer im Schlüssel erfasst werden.
(Diese Schlüssel mit yes/no als einzigen Wert empfand ich schon bei Public_Transport als großen Mangel.)

Ich kenn mich mit der Eisenbahn nicht aus, aber wenn es definitiv nur ein Sicherungssystem gibt, kann man sicherungssystem=* taggen, wenn in der Praxis an dem Objekt aber mehrere Sicherungssysteme möglich sind, ist yes/no definitv besser. Leider ist aber die Vorlagen-Unterstützung in JOSM für z.B. die Auswahl des Keys aus einer Mehrkeyliste, dem dann ein *=yes hinzugefügt wird, nicht vorhanden.

viw · 2012-02-21T06:15:01.000Z

Es ist definitiv möglich mehrere Sicherungssysteme auf einmal zu haben. Also PZB und LZB schließen sich gegenseitig überhaupt nicht aus. Sogar ECTS ist oft noch parallel zu konventionellen Systemen, da ein diskriminierungsfreieren Zugang zum Netz gewährt werden muss.

Jimmy_K · 2012-02-22T09:42:13.000Z

EvanE:

rurseekatze:

Bezüglich Bahnübergängen hatte ich mir auch schon Gedanken gemacht:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Bahn.C3.BCbergang

Was haltet ihr von meinem Taggingvorschlag? Sollte ich noch etwas ergänzen?
…

Hallo Alexander

Das ist das Problem, wenn man eine Sache nur aus einem Blickwinkel (hier die Eisenbahn) betrachtet.

An mehrgleisige Bahnübergängen sind alle Einträge mehrfach zu setzen.
Dabei ist der Bahnübergang eine Einheit.

Die Straßensicht
“Wo ist die Schranke / das Verkehrszeichen / wo besser nicht stehen bleiben?”
bleibt außen vor.
…

Edbert (EvanE)

Ist eigentlich die selbe “Frage” wie bei den Straßenverkehrs-Ampeln, wo man glaube ich auch noch immer keine Lösung für die Zusammenfassung von Ampeln, Haltelinien, Zebrastreifen, usw. gefunden hat.

EDIT: 1435 ist die Standardspurweite, weil sie die internationale UIC so genormt hat. Jeder Eisenbahninteressierte in Spanien, Russland, usw. weiß, dass sie eine Breitspur haben.

rurseekatze · 2012-02-22T13:55:35.000Z

EvanE:

Das ist das Problem, wenn man eine Sache nur aus einem Blickwinkel (hier die Eisenbahn) betrachtet.

An mehrgleisige Bahnübergängen sind alle Einträge mehrfach zu setzen.
Dabei ist der Bahnübergang eine Einheit.

Die Straßensicht
“Wo ist die Schranke / das Verkehrszeichen / wo besser nicht stehen bleiben?”
bleibt außen vor.

Ob zwei Bahnübergänge zusammengehören, ließe sich in einer Datenbank einfach herausfinden. Entweder haben mehrere den gleichen Wert von railway:position, dann kann man die anderen hinauswerfen, oder man clustert sie, da die einzelnen Bahnübergänge nur wenige Meter auseinander liegen.

Und die Position der Schranke und der Verkehrszeichen müsste man auch so ungefähr ermitteln können. Zumindest für ein Navi sollte das reichen.

EvanE:

Was mich an deinem gesamten OpenRailwayMap Vorschlag wirklich stört, ist die Behandlung der Zugsicherung. Für jedes System definierst du einen eigenen Schlüssel mit yes/no als Wert. Im Grunde geht es doch nur darum welches Sicherungssystem verwendet wird. Mehrere parallele Sicherungssysteme können über eine fortlaufende Nummer im Schlüssel erfasst werden.
(Diese Schlüssel mit yes/no als einzigen Wert empfand ich schon bei Public_Transport als großen Mangel.)

Das wäre besser mit railway:signaling:= mit x eine einstellige Zahl, für den Fall dass es mehr als ein Sicherungssystem gibt. Als Name kämen auch railway:train_protection: oder railway:train_control: in Frage.

Dein Vorschlag macht es doch nur noch unnötig kompliziert. Alleine schon zum Auswerten ist es ungeeignet. Will ich alle Strecken mit LZB rendern, dann muss ich folgende Abfrage machen:
select … where railway:signalling:1=lzb or railway:signalling:2=lzb

Siehtst du das Problem? Wenn mehrere Sicherungssysteme auf einer Strecke vorhanden sind, in welcher Reihenfolge soll man sie dann angeben?
Außerdem verstehe ich nicht, was dein Vorschlag vereinfachen soll. Bei den Sicherungssystemen gibt es eben eine Mehrfachauswahl, daher sind yes/no-Werte angebracht.
In anderen Fällen bevorzuge ich auch lieber auch lieber die Angabe eines Wertes im Value. Beispiel: Straßenkategorien. Dort schließen sich die Werte gegenseitig aus und es gibt keine Mehrfachauswahl.

Basstoelpel · 2012-02-22T14:21:16.000Z

Jimmy_K:

EDIT: 1435 ist die Standardspurweite, weil sie die internationale UIC so genormt hat. Jeder Eisenbahninteressierte in Spanien, Russland, usw. weiß, dass sie eine Breitspur haben.

Solange wir funktionierende Grenzpolygone haben, kann es eigentlich reichen, nur die Spurweiten zu taggen, die nicht die Standardspur im jeweiligen Land sind.

Baßtölpel

EvanE · 2012-02-22T14:39:55.000Z

Basstoelpel:

Jimmy_K:

EDIT: 1435 ist die Standardspurweite, weil sie die internationale UIC so genormt hat. Jeder Eisenbahninteressierte in Spanien, Russland, usw. weiß, dass sie eine Breitspur haben.

Solange wir funktionierende Grenzpolygone haben, kann es eigentlich reichen, nur die Spurweiten zu taggen, die nicht die Standardspur im jeweiligen Land sind.

Hallo Baßtölpel

Halte ich für problematisch.

Erstens musst du immer nachsehen, wo du gerade bist.
Zweitens musst du wissen, welche Spurweite in diesem
Land gerade die Übliche ist.

Weißt du welche Spurweite in Irland verwendet wird oder in Japan / Südafrika / Indien / Vietnam?

Irland: 1600mm (weiß kaum einer)
Japan: 1067mm
Südafrika: 1067mm
Indien: Meist Breitspur
Vietnam: Weis ich selber nicht.

Es ist das gleiche Problem wie bei maxspeed für Stadt-/Außerortstraße und Autobahnen.

Edbert (EvanE)

EvanE · 2012-02-22T15:08:37.000Z

rurseekatze:

EvanE:

Das ist das Problem, wenn man eine Sache nur aus einem Blickwinkel (hier die Eisenbahn) betrachtet.

An mehrgleisige Bahnübergängen sind alle Einträge mehrfach zu setzen.
Dabei ist der Bahnübergang eine Einheit.

Die Straßensicht “Wo ist die Schranke / das Verkehrszeichen / …?” bleibt außen vor.

Ob zwei Bahnübergänge zusammengehören, ließe sich in einer Datenbank einfach herausfinden. Entweder haben mehrere den gleichen Wert von railway:position, dann kann man die anderen hinauswerfen, oder man clustert sie, da die einzelnen Bahnübergänge nur wenige Meter auseinander liegen.

Und die Position der Schranke und der Verkehrszeichen müsste man auch so ungefähr ermitteln können. Zumindest für ein Navi sollte das reichen.

Das funktioniert maximal bei einer zweigleisigen Strecke. Sobald du drei Gleise hast, gibt es mindestens zwei Strecken(nummern) und damit auch unterschiedliche Kilometrierung.

Warum sollen wir uns mit “ungefähr” begnügen, wenn es im Rahmen unserer Möglichkeiten auch genauer geht?

rurseekatze:

EvanE:

… Für jedes System definierst du einen eigenen Schlüssel mit yes/no als Wert. Im Grunde geht es doch nur darum welches Sicherungssystem verwendet wird. Mehrere parallele Sicherungssysteme können über eine fortlaufende Nummer im Schlüssel erfasst werden.

Das wäre besser mit railway:signaling:= mit x eine einstellige Zahl, für den Fall dass es mehr als ein Sicherungssystem gibt. Als Name kämen auch railway:train_protection: oder railway:train_control: in Frage.

Dein Vorschlag macht es doch nur noch unnötig kompliziert. Alleine schon zum Auswerten ist es ungeeignet. Will ich alle Strecken mit LZB rendern, dann muss ich folgende Abfrage machen:
select … where railway:signalling:1=lzb or railway:signalling:2=lzb

Siehtst du das Problem? Wenn mehrere Sicherungssysteme auf einer Strecke vorhanden sind, in welcher Reihenfolge soll man sie dann angeben?
Außerdem verstehe ich nicht, was dein Vorschlag vereinfachen soll. Bei den Sicherungssystemen gibt es eben eine Mehrfachauswahl, daher sind yes/no-Werte angebracht.
In anderen Fällen bevorzuge ich auch lieber die Angabe eines Wertes im Value. Beispiel: Straßenkategorien. Dort schließen sich die Werte gegenseitig aus und es gibt keine Mehrfachauswahl.

In deinem Beispiel wäre das komplexer. Wenn du allerdings die Frage stellst, welche Sicherungssysteme alle an einer Strecke vorhanden sind, musst du 25-30 Schlüssel kennen und abfragen. Das sehe ich keineswegs als einfacher wie alle Schlüssel mit railway:train_control:= abzufragen. Die Nummerierung muss dabei ja keine Rangfolge bedeuten.

Es gibt ja noch die Alternative mit ‘;’ mehrere Werte anzugeben. Aber irgendwie will da wohl niemand dran, das den Anwendungen zuzumuten. Das scheint mir der eigentliche Grund für deine und meine Verrenkungen.

BTW: Sind die (Euro-)Balisen für Neigetechnik schon enthalten?

PS: Ich dachte immer im SELECT wären auch Wildcard-Zeichen zulässig.
Also: select … where railway:signalling:*=lzb

Edbert (EvanE)