DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
ENGLISH PART BELOW
Liebe ORM-Community,
[Kurzform: Was ist optimaler geografischer Ort für Tags von Weichen o.ä. Vorschläge und Diskussion siehe V* weiter unten.]
Hochgenaue und gleisgenaue Streckenarten sind u.a. für die Lokalisierung von Schienenfahrzeugen notwendig. Für (experimentelle!) Anwendungen sind die Daten aus OSM hilfreich, insbesondere wenn (noch) keine Informationen vom Netzbetreiber vorliegen.
Bislang gibt es m.E. kein einheitliches Vorgehen, auf welches Bauteil einer Weiche man den Ort (lat, lon in node) des zugehörigen Tags setzt (z.B. railway=switch oder railway:switch=default). Besonders schwierig wird es bei komplexen Weichen, da sie mehrere Funktionen vereinen.
Möglicherweise hängen die Anforderungen und Wünsche auch von (zukünftigen) Anwendungsfällen. Deshalb folgen einige Ideen, die einerseits auf die Realisierbarkeit in der derzeitigen Praxis abzielen und andererseits den Blick in die Zukunft bei Verfügbarkeit von noch genaueren Vermessungen der Strecke lenken. Mein Wunsch ist die Festlegung eines einheitlichen Vorschlages für zukünftiges Tagging.
V1. Vorschläge für Tag-Position für einfach Weichen (EW, IBW, ABW): V1(a) Weichenzungenspitze (Ort der Fahrwegänderung, ungefähr erkennbar am Ort des Weichenantriebs in Luftbildern o.ä.) V1(b) Herzstückspitze ("massives" Bauteil, ungefähr erkennbar am Schnittpunkt der inneren Schienen) V1(c) anderer Vorschlag?
V2. Vorschläge für Tag-Position an Kreuzungen (Kr): V2(a) Mitte der Kreuzung, d.h. Schnittpunkt der beiden Gleismitten V2(b) anderer Vorschlag?
V3. Vorschläge für Tagging von komplexen Weichen (EKW, DKW, DW): V3.1 Wo immer möglich in Einzelbestandteile zerlegen, d.h.: - EKW = 2x EW + 1x Kr - DKW = 4x EW + 1x Kr - DW = 2x EW (damit ist auch eindeutig festgelegt, welche Fahrbeziehungen insbesondere an EKWs möglich sind) V3.2 Tags für Einzelbestandteile wie für V1 und V2 festgelegt setzen.
_Mein favorisierter Vorschlag_ ist: V1(a) + V2(a) + V3.1 + V3.2, der sowohl die Position von Weichen und Kreuzungen als auch die Fahrbeziehungen an komplexen Weichen eindeutig festlegt.
Fragen (hinsichtlich Tagging, Eisenbahnbezug etc.): - An welchen Ort habt ihr bislang das Tag von Weichen und Kreuzungen gelegt? - Was spricht für diesen Vorschlag? - Was spricht gegen diesen Vorschlag? - Welche weiteren Anwendungen neben den Fahrbeziehungen würden von diesem Vorschlag ebenfalls profitieren? - Welche Bauteile mit ähnlichen "Problemen" wurden nicht berücksichtigt?
Ich danke schon mal im Voraus herzlich für Ihr/euer Feedback.
Viele Grüße aus Karlsruhe,
Denis Stein. (steindcom)
####################################################################
GERMAN PART ABOVE
Dear all,
[Briefly: The geographical position of railway tags, such as switches, is currently ambiguous. Please, find proposals P* and discussion below.]
Applications, e.g. train localization, require precise and track-selective maps of the railway network. For experimental issues OSM data is useful, especially if these maps are not (yet) available from the operator.
Currently, there is no common definition, which part of a switch shall be used as the (unique) position (with regard to lat, lon of the node) of the corresponding tag (e.g., railway=switch or railway:switch=default). Furthermore, complex switches fulfill several "tasks" and one position is obstructive therefor.
The requirements may depend also on future applications. However, my intention is to propose a common scheme for tagging those railway elements considering both the current practice and future potentials of the availability of measurements with higher accuracy.
P1. Proposals for the position of tags for single turnouts (abbreviation: ST; including both straight as well as curved ones): P1(a) Tip of the switch blade (i.e., the position where the route changes; might be also recognized by the point machine in aerial images) P1(b) Tip of the frog ("massif" part; can be approximated from the intersection of both inner rails) P1(c) another proposal?
P2. Proposals for the position of tags for diamond crossings (abbreviation: DC): P2(a) Center of DC, i.e. intersection of both track centerlines P2(b) another proposal?
P3. Proposals for tagging of complex switches: P3.1 Decompose them whenever applicable: - diamond crossing with ... slips: * single = 2x ST + 1x DC * double = 4x ST + 1x DC - three-way switch = 2x ST (solves also the route ambiguity problem in single slip case) P3.2 Tag those parts according to P1 and P2.
_My favorite_ is: P1(a) + P2(a) + P3.1 + P3.2, which considers the position of turnouts and diamond crossing and clearly defines the drivable routes on them clearly.
However, some questions arise (regarding current practice, tag meaning with regard to railway "theory"): - Which positions are you currently using for the corresponding switch and diamond crossing tags? - What are the arguments in favor of my proposal? - What arguments are opposing my proposal? - Are there further applications (besides the branching relations) that might also benefit from my proposal? - Are there further elements that share the same "problems" as switches?
I am looking forward to receiving your helpful comments. Many thanks in advance!
Kind regards,
Denis Stein. (steindcom)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Denis,
Am 19.09.2016 um 19:02 schrieb Denis Stein:
The requirements may depend also on future applications. However, my intention is to propose a common scheme for tagging those railway elements considering both the current practice and future potentials of the availability of measurements with higher accuracy.
P1. Proposals for the position of tags for single turnouts (abbreviation: ST; including both straight as well as curved ones): P1(a) Tip of the switch blade (i.e., the position where the route changes; might be also recognized by the point machine in aerial images) P1(b) Tip of the frog ("massif" part; can be approximated from the intersection of both inner rails) P1(c) another proposal?
In history, mappers usually mapped the point at the common crossing or a location between the point blades and the common crossing because the common crossing is better visible on aerial imagery. You have to have a little bit more understanding of railways than Joe Average-Mapper and need very good aerial imagery to spot the point machines on Bing imagery.
I myself move all the points I find during mapping to the tip of the point blades because that's the location where the track centerlines split up.
P2. Proposals for the position of tags for diamond crossings (abbreviation: DC): P2(a) Center of DC, i.e. intersection of both track centerlines P2(b) another proposal?
Diamond crossings are mapped where the track centerlines intersect. If they are mapped differently, e.g. like this
\ / \ / \ / >-< / \ / \ / \ (a common piece of track, looks like two points),
they have been mapped long ago when only worse Bing or Yahoo imagery was available.
P3. Proposals for tagging of complex switches: P3.1 Decompose them whenever applicable: - diamond crossing with ... slips: * single = 2x ST + 1x DC * double = 4x ST + 1x DC - three-way switch = 2x ST
Did you mean a "Doppelweiche" (the blades of the second point are between the point blades and the common crossing of the first point)? http://www.tf-ausbildung.de/BahnInfo/dw.htm This should be mapped as two single points.
(solves also the route ambiguity problem in single slip case) P3.2 Tag those parts according to P1 and P2.
I prefer to map single and double slips like diamond crossings but with special tags. If we want to map the possible turnout directions of single slips, I would use turn restriction relations as used on roads. Routing engines have been supporting turn restrictions for many years. To reduce the number of turn restrictions which have to have mapped, I would not map a relations if it is just the opposite of another turn restriction on that point (i.e. copy of another relation but from and to members are switched).
While writing a routing engine for trains becomes easier if we map single/double slips as simple points, rendering a nice map (especially track layout diagrams becomes more difficult) becomes more difficult. There are several OSM-based routing engines which already support turn restrictions but there is no software which simplifies double slip points mapped in a way you propose. (In general, cartographic generalization of geospatial data beyond a simplification of the geometry is more difficult than parsing turn restrictions)
Best regards
Michael
- -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)
On 19.09.2016 19:02, Denis Stein wrote:
P1. Proposals for the position of tags for single turnouts (abbreviation: ST; including both straight as well as curved ones): P1(a) Tip of the switch blade (i.e., the position where the route changes; might be also recognized by the point machine in aerial images) P1(b) Tip of the frog ("massif" part; can be approximated from the intersection of both inner rails) P1(c) another proposal?
P2. Proposals for the position of tags for diamond crossings (abbreviation: DC): P2(a) Center of DC, i.e. intersection of both track centerlines P2(b) another proposal?
P3. Proposals for tagging of complex switches: P3.1 Decompose them whenever applicable: - diamond crossing with ... slips: * single = 2x ST + 1x DC * double = 4x ST + 1x DC - three-way switch = 2x ST (solves also the route ambiguity problem in single slip case) P3.2 Tag those parts according to P1 and P2.
_My favorite_ is: P1(a) + P2(a) + P3.1 + P3.2, which considers the position of turnouts and diamond crossing and clearly defines the drivable routes on them clearly.
Yes, that is what I tagged in the past and it's also my favourite because it's suited best for routing purposes as well as collision detection (in conjunction with track gauge). Especially because for roads we also tag the centerline, so there is the principle of least surprise, and algorithms can be reused for railways.
I currently cannot think of any opposing arguments, maybe because I'm used to thinking of infrastructure in a topological way.
- Roland
Hi Roland,
Am 20.09.2016 um 21:57 schrieb Roland Hieber:
Yes, that is what I tagged in the past and it's also my favourite because it's suited best for routing purposes as well as collision detection (in conjunction with track gauge). Especially because for roads we also tag the centerline, so there is the principle of least surprise, and algorithms can be reused for railways.
I currently cannot think of any opposing arguments, maybe because I'm used to thinking of infrastructure in a topological way.
At a simple crossing of two roads (no traffic islands, no turn lanes) you do not map the lines which are described by a car turning to the right/left. You just map the two roads and their intersection.
I agree that collision detection is a purpose which has to be kept in mind but I hope that the requirements of collision detection can be fulfilled by adding the radius of the diverging track (assuming that the curve is no clothoid). Except some exotic points, there are only a few different point radii in use in Germany.
Best regards
Michael
Dear all,
Thank you for your valuable answers and sorry for my delay. After checking several stations (Munich, Karlsruhe, Nuremberg, Frankfurt, Hamburg) and shunting yards (Nuremberg, Maschen) I would like to add some further remarks.
Am 20.09.2016 um 21:57 schrieb Roland Hieber:
On 19.09.2016 19:02, Denis Stein wrote:
P1. Proposals for the position of tags for single turnouts (abbreviation: ST; including both straight as well as curved ones): P1(a) Tip of the switch blade (i.e., the position where the route changes; might be also recognized by the point machine in aerial images) P1(b) Tip of the frog ("massif" part; can be approximated from the intersection of both inner rails) P1(c) another proposal?
P2. Proposals for the position of tags for diamond crossings (abbreviation: DC): P2(a) Center of DC, i.e. intersection of both track centerlines P2(b) another proposal?
P3. Proposals for tagging of complex switches: P3.1 Decompose them whenever applicable: - diamond crossing with ... slips: * single = 2x ST + 1x DC * double = 4x ST + 1x DC - three-way switch = 2x ST
Especially to Michael: Yes, "three_way" equals Doppelweiche in German, but seems to be used not that much [1, 2].
(solves also the route ambiguity problem in single slip case)P3.2 Tag those parts according to P1 and P2.
_My favorite_ is: P1(a) + P2(a) + P3.1 + P3.2, which considers the position of turnouts and diamond crossing and clearly defines the drivable routes on them clearly.
Yes, that is what I tagged in the past and it's also my favourite because it's suited best for routing purposes as well as collision detection (in conjunction with track gauge). Especially because for roads we also tag the centerline, so there is the principle of least surprise, and algorithms can be reused for railways.
I fully agree. This decomposition of switches is quite often used in Karlsruhe, but most of the other above mentioned places are not yet tagged like this (feel free to ask me for a detailed list of node-IDs; I checked especially "single_slip" (einfache Kreuzungsweiche)).
Am 20.09.2016 um 16:23 schrieb Michael Reichert:
I prefer to map single and double slips like diamond crossings but with special tags. If we want to map the possible turnout directions of single slips, I would use turn restriction relations as used on roads. Routing engines have been supporting turn restrictions for many years. To reduce the number of turn restrictions which have to have mapped, I would not map a relations if it is just the opposite of another turn restriction on that point (i.e. copy of another relation but from and to members are switched).
Using one node for the whole switch might be ok. However, there are only 280 nodes tagged as "single_slip" [3]. Unfortunately, turn restrictions are -- considering the seven places mentioned above -- only used in Karlsruhe (feel free to ask me for a detailed list of singe_slip node-IDs and a comprehensive overview on single/double_slip nodes in Karlsruhe). Thus, tagging one node as "single_slip" is fine. The ideal solution would be a decomposition in three nodes as previously proposed which in turn avoids the use of turn restrictions.
While writing a routing engine for trains becomes easier if we map single/double slips as simple points, rendering a nice map (especially track layout diagrams becomes more difficult) becomes more difficult. There are several OSM-based routing engines which already support turn restrictions but there is no software which simplifies double slip points mapped in a way you propose. (In general, cartographic generalization of geospatial data beyond a simplification of the geometry is more difficult than parsing turn restrictions)
In my opinion, there is no need for a automatic decomposition in a routing engine etc. My proposal considers only (future) "tagging guidelines".
Off-topic: Are there any (OSM-based) routing engines for railway vehicles?
Kind regards,
Denis.
[1] https://taginfo.openstreetmap.org/keys/railway%3Aswitch
[2] https://taginfo.openstreetmap.org/search?q=railway%3Aswitch%3Dthree_way
[3] https://taginfo.openstreetmap.org/search?q=railway%3Aswitch%3Dsingle_slip
Am Freitag, den 07.10.2016, 14:04 +0200 schrieb Denis Stein:
Off-topic: Are there any (OSM-based) routing engines for railway vehicles?
BRouter has a rail profile, but this is just a simple shortest-path algorithm: http://brouter.de/brouter-web/
The train routes shown in TRAVIC are generated by routing between the vehicle stops using the OSM railway network, but the code is not public and there is no API: http://tracker.geops.ch/?z=11&s=1&x=776922.6092&y= 6605874.8795&l=transport
Regards Alex
Off-topic: Are there any (OSM-based) routing engines for railway vehicles?
osmtrainroutes.bplaced.net (Code: https://github.com/sb12/OSMTrainRouteAnalysis)
Eike
Off-topic: Are there any (OSM-based) routing engines for railway vehicles?
Additionally, I've been working on a train profile for https://github.com/Project-OSRM/osrm-backend. I wanted to write a blog post on it but haven't managed to do so yet. The profile is available at https://gist.github.com/duizendnegen/e96d91afafaca9a54097a40779ada39e (it doesn't take into account actual train routes as https://github.com/sb12/OSMTrainRouteAnalysis does, unfortunately)
On Sat, Oct 8, 2016 at 10:40 PM Rolf Eike Beer eike@sf-mail.de wrote:
Off-topic: Are there any (OSM-based) routing engines for railway
vehicles?
osmtrainroutes.bplaced.net (Code: https://github.com/sb12/OSMTrainRouteAnalysis)
Eike_______________________________________________ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Am Samstag, den 08.10.2016, 22:40 +0200 schrieb Rolf Eike Beer:
Off-topic: Are there any (OSM-based) routing engines for railway vehicles?
osmtrainroutes.bplaced.net (Code: https://github.com/sb12/OSMTrainRouteAnalysis)
But I guess this is just an analysis of route relations, but not a real routing where you can dynamically set start/end points.
Regards Alex
openrailwaymap@openrailwaymap.org
-
Alexander Matheisen -
Denis Stein -
Michael Reichert -
Pepijn Schoen -
Roland Hieber -
Rolf Eike Beer