I came across a strange set of mapping for the shuttle train between Niebüll and Sylt island.
This train carries cars and provides the only way to ride by car from Germany (continent) to Sylt, Germany (island).
This does not apply to this single spot only: the Eurotunnel between France and England seems to have the same issue.
The proposal seems to support this mapping at least it can be misunderstood to do so.
Analysis:
What I saw:
There is railway=track infrastructure mapped in OSM for two tracks (e.g. on the damm)
The tracks are used by some (normal) trains mapped as route relations: IC 26.1 and RE6
The tracks are used also by the shuttle train (route=train) Sylt-Shuttle. The relation has some extra tags (shuttle=yes, motor_car=yes, …)
There was (I deleted that) additional route=shuttle_rain infrastructure mapped in OSM as ways (!) following the railway=track infrastructure of 1. (between and in parallel, single and double) representing the tracks of/for the shuttle train (render=no)
There was (I deleted that) an additional route=shuttle_train relation in OSM based on the infrastructure mentioned in 4.
Either 4. or 5. are used by at least one routing engine (ADAC), maybe also by others.
For the Eurotunnel it seems similar, there is additional route=shuttle_train infrastructure in OSM as ways: way1 and way2 having also a strange turn restriction
This kind of mapping refers to a proposal route=shuttle_train which was introduced 13/11 years ago and never completed: it is abandoned (inactive).
a. this proposal introduces ways and relations as valid objects
Conclusion:
The mapping of the additional infrastructure is against the mantra “one feature, one object”.
I.e. if there is only one object in reality then there must not be more than one object in OSM.
The observed mapping/tagging follows/supports the approach “mapping for the routing engine”
Routes should not be mapped on ways/nodes. The agreed method to do this are relations as for all other public transport routes-
“route=shuttle_train” tagged on ways (railway=track) which are also used by normal trains is completely wrong, that would apply to all trains using the tracks.
There is no need for a new type of route: route=shuttle_train. A train is a train is train, … A “shuttle train” is a train which provides a special or an additional service, tagged with: service=shuttle_train or shuttle=yes and/or hgv=yes, bicycle=yes, motor_car=yes, …
Action:
Mark the proposal as deprecated (do not use at all) providing hints why and how to map that correctly
Let the routing engines learn how to use route relations: route=train + shuttle=yes + motor_car=yes, …
a. they would also learn how to use route=ferry relations for those ferries carrying cars, … and even trains
Delete those strange OSM objects
To be involved:
@ADAC_Touristische_InfoSysteme (first CS comment on my edit)
vng_me (contributed to CS comment) seems not to be on community server @chris66 (the author of the proposal) @Skippern (commented on proposal in 2012) @pimapper (commented on proposal in 2012) @emvee (commented on proposal in 2022)
“Alv”, “Sladen” and “Aceman444” (commented on proposal) seem not to be on community server
Edit: 2023-03-23 13:17 UTC - fix link to Eurotunnel
Edit: 2023-03-23 13:40 UTC - add “: route=train + shuttle=yes + motor_car=yes, …” to “Let routing engines learn …”
Reading better the (now archived proposal) and the examples I did update I did realize that the Sylt-Shuttle is going over a dam and for that I support the clean up.
The other category is Trains on boats and checking things I see they are nowadays mapped as railway=ferry, see also Train ferry.
I mapped the original Eurotunnel Le Shuttle routing from UK to France some years ago.
I did take the idea from the Niebüll - Sylt mapping as it was a working solution to my problem.
I cannot remember exactly why I looked for that solution but suspect there is a ‘problem’ of routers not wanting to route motor vehicles on railways. Other railway tags, such as max speed also do not apply.
The route=shuttle train also mimic ferry tagging which allows from duration to be tagged.
This is quite a major change to tagging which has been in existence for many years. Before moving forward with your suggestions I think you need some input from those who write routing engines, not just those who engaged with the proposal: they may consume the current approach to mapping.
The Channel Tunnel and the Vereinatunnel are major infrastructure projects where changes to the way routers calculate things can have major knock on effects. Unfortunately, taginfo does not capture this detail, and anyway there are many routing projects missing there. I think most should treat these in the same way as ferries, but there have been issues with ferry routing too over the years.
It is always important to consider such things as well as rectitude with respect to one feature one element. I think the best thing is to create appropriate relations, and then wait until we are sure that routers don’t consume the tagged ways. The absence of the Sylt one should enable such testing even if there is no response from router maintainers. But be aware that propagation of such changes downstream may take several months.
My major concern/motivation for writing this here was: route=shuttle_train on OSM ways and the double mapping of tracks - also in Eurotunnel.
Once routing engines learn how to make use of relations, there is only a tiny difference between route=shuttle_train (I do not favour this) and route=train + shuttle=yes (my favourite one)
route=ferry on ways is different to this topic as there are no physical ways on water: “water has no bars” as we say in German.
Yes, I do agree: this is a major change to the understanding and coding of routing engines.
The “proposal” was never published as a “proposal for voting” and I guess: it would have been rejected - just because of the route=shuttle_train on ways. We now see the consequences manifested in double mapping of tracks - just for those routing engines which want to navigate using trains (as ways) instead of learning how to make use of relations. The age of the “proposal” does not make it “valid” though.
I prefer a one-time change in code of routing engines instead of a permanent break of/exception to a fundamental rule in mapping: “one feature, one object”.
I don’t say that the one-time change of a routing engine towards “relation” is an easy task and that the additional runtime is tiny - I’m a SW developer myself. I would still go this path.
FWIW I believe the core engines of OSRM, Graphhopper and Valhalla are all able to consider route relations. Whether their default profiles/weightings use them in this scenario is a different question.
I don’t have a strong opinion on the tagging, but it’s important that bike routers are able to discern the difference between a turn-up-and-go shuttle service, and an intercity train service where bikes require booking. In particular I’m thinking of services like this:
which is an important part of a long-distance cycle route (the Alpe-Adria Radweg). Most bike routers will want to include this, but not the full rail network, in their routing graph. Something simple like shuttle=yes on the relation might be a good idea.
Yeah, and I think this is the difference between a hop-on and hop-off service and a train which requires booking in advance (days, weeks in advance). E.g. there were trains carrying cars between Munich and Hamburg, once a day (over night), … I would not call them “shuttle”.
How would you call these long-distance services? For booking we have the established reservation=* and access tags like bicycle or hgv to define which vehicles are allowed are probably needed anyway.
The more I think about it the more I come to the conclusion that “shuttles” which do not transport people without vehicle would even qualify for a different value of route=* like route=shuttle_train. Have you thought about this option?
At least, we need to think about more values for shuttle=*, like shuttle=only, I guess.
Not a good idea, as “shuttle_train” just does not say what will be “shuttled” here.
Would you also like to introduce a route=shuttle_bus for the bus between the Visitor Centre and the stones of “Stonehenge”?
I think, using the well established values for route=* plus the tags shuttle=yes, motor_car=yes, … is more generic.
Having foot=no + bicycle=no would disallow passengers w/o motorvehicle
That depends on what you want to describe with “shuttle”:
come-and-ride: first-come-first-serve
come-and-ride: fcfs but w/ or w/o priority reservation
adding some more info about the “who and what will be shuttled”
can be specified w/ bicycle=yes, foot=no, …
Edit 2023-03-17-14:21 UTC - adding “Having foot=no + bicycle=no would disallow passengers w/o motorvehicle”
Good question. The priority of service probably needs a separate tag and/or reservation=recommended is available. Access tag can be used for the served transport modes.
Let’s take a step back. I am still not sure which trains transporting motor cars deserve a shuttle=yes and which not. How about Hamburg-Altona → Sylt or even longer distance, see Autoreisezug Hamburg, or the Lötschberg-Simplon transition?
