Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
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 signature.asc Description: This is a digitally signed message part ___ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] 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? 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 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 > ___ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] 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 signature.asc Description: This is a digitally signed message part. ___ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
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 signature.asc Description: This is a digitally signed message part ___ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
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]
[2]
[3]
--
.
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
st...@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
..
Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
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) signature.asc Description: OpenPGP digital signature ___ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
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
___
Openrailwaymap mailing list
Openrailwaymap@openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Re: [openrailwaymap] DE: Optimale Position von railway:switch-Nodes u.a. / EN: optimum position of railway:switch nodes etc.
-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-
___
Openrailwaymap mailing list
Openrailwaymap@openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
