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

[Michael Reichert]

-----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-----