This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.

[openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.

Denis Stein stein at fzi.de
Fri Oct 7 14:04:01 MEST 2016


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>

-- 
.........................................................
Dipl.-Inf. Denis Stein
Research Scientist
Research Division ISPE | Research Department MPS

FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany

Tel.: +49 721 9654-276

stein at fzi.de
www.fzi.de/mitarbeiter/stein

.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................



More information about the Openrailwaymap mailing list