DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
7:02 p.m.
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)
--
.........................................................
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(a)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
.........................................................
4:23 p.m.
-----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)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJX4UZwAAoJEB87G9rMCMyIaQoQAIqnUngLPEQJewFAuXBFESdM
X94p+hJ3Xd13oI1q23rfiOcTcygC3JI04S9xQVLDMWj+UoR3Usvix4Y3xUVqaWjY
I113fmTrz82Uedg1gujl+6ZopPP8sQi19boR1mS2S0tq7986XyCfe+GkEl1/7jig
fgTaGe4WxHNifyptHBamj0qrrvXsTgogEiIoa8YLL6kqOywzOO9OdCvV92B4nFnL
tlSplYr16gxzZWuBhRSyU4YPSfeqcfbljCg8LYzhE+pTyKM+EQOrNueqfH2hvJMP
uWPAR4FaJoJQRkTiqmcq26X6iKJIENv6tMODQcndSgjOKlL9AGMQ+v2cXL56PsKS
SYVYfSIUyGIk2cGYHwN5K2U4N1Ne/J5CuSaPX0n0NWax3fN+3xQcSSFKJOmEAUCN
SuvaVi1TEbQm68hjzXalin12EdorTLGiCVqD1ibZ7IspgMRuzsWGRR01bDad4vZv
K0LWYIQdGl8xQfEmJokgG2rU7k12W067yfNJgPP/dKkAr+2XYDjtjQdn0NtTsdfw
zIgmpZyTo6evJuJXHW6uslqUGtt5tDNvcWF0HS7P4CqqXZvI/Qmbxpm1uemXyYbC
quP1iBjpgO3+6cUZpeQ8Q5ZV2p3yQlqRp4txYcT/O+pTLZNE00lDZVp+Ri1IK/Ck
AgG8cwKPLkGQFlRxrzsf
=ZhAW
-----END PGP SIGNATURE-----
9:57 p.m.
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
10:10 p.m.
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
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
2:04 p.m.
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(a)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
.........................................................
10:29 p.m.
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
10:40 p.m.
New subject: DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
Off-topic: Are there any (OSM-based) routing engines for railway
vehicles?
osmtrainroutes.bplaced.net (Code:
https://github.com/sb12/OSMTrainRouteAnalysis)
Eike
9:39 a.m.
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(a)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(a)openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
12:01 p.m.
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
2995
days inactive
3015
days old
openrailwaymap@openrailwaymap.org
8 comments
6 participants
participants (6)
-
Alexander Matheisen
-
Denis Stein
-
Michael Reichert
-
Pepijn Schoen
-
Roland Hieber
-
Rolf Eike Beer