Hi Michael,
After reading through this further, I could make the counter argument that
modern systems like (ETCS Level 2, LZB) include cab signalling where
signals along the line are not necessary and everything is shown on a
display in the engine does not meet the very On The Ground Rule of
OpenStreetMap. To map this information you will need additional
knowledge to identify the technology through government or company
documents to make a correct assessment on the specific system in use.
How is this different from what I am suggesting?
If we can both assume that we both have extensive working knowledge of
railroads or railways and that we can identify correctly the system in use.
Can we assume that we should be allowed to map it if we can look at the
ground and see that it is what it is? Or do we need to make the assumption
that we don't have a working knowledge of railroads or railways and that we
need to assume a role as an outsider when mapping railroads and only map
what we can see (signals, switches, balises, magnets, contacts etc.*)*?
This discussion appears to skirt around the On The Ground Rule of
OpenStreetMap.
Cheers,
Nathan P
email: natfoot(a)gmail.com
P.S.
Here is our Yard Limits board the Yellow "y" on top of the MilePost 40
marker:
Hi Michael,
Here in America what you are describing in train protection is Positive
Train Control (PTC). Positive train control has GPS based land stations and
locomotive GPS attachments and hardware.
As you say OpenStree Map has a very On The Ground Rule which would be hard
to identify PTC technology as it does not have
significantly different structure than the existing structures.
What is identifiable is CTC or ABS (Centralized Traffic Control)
(Automatic Block Signal) as it has on track equipment and signals (balises,
magnets, contacts etc.) Here the operating rules are often displayed with
signs along the right of way or will let you know when existing or entering
a specific territory. (Yard Limits, Restricted Limits, CTC, ABS, etc.) We
have signs that say "Begin CTC" Example from Mapillary:
https://www.mapillary.com/app/user/natfoot?lat=39.762375&lng=-104.995...
In our case a "Company Rule Book" would be needed to identify PTC as that
is not common knowledge. The only identifiable visual systems are GPS
receivers on railroad hardware, which could be PTC or just a GPS tracker.
Unless this information can be requested through the FRA, STB or the
general Federal Transportation Commission. Either way you are unlikely to
get detailed information needed and this continues to lack the on the
ground requirements of OpenStreetMap.
Best Regards,
Nathan P
email: natfoot(a)gmail.com
On Tue, Jun 9, 2020 at 2:00 PM Michael Reichert <osm-ml(a)michreichert.de>
wrote:
> Hi Nathan,
>
> Am 08/06/2020 um 17.49 schrieb Natfoot:
> > I would like to add my two cents to this topic. I am starting to
> realize
> > by going through this email that it appears that Track Authorization
> > (Traffic Control) is completely omitted from OSM. I hope to use the
> > railway tags from OSM/OHM data in a future project. With this in mind
> here
> > are my comments.
> >
> > 1) The description of railway:train_protection=no is inherently wrong.
> > Train protection is given or accepted by a set of rules either
> > provided by the rule book or the track territory. Now in the case of
> GCOR
> > (
https://en.wikipedia.org/wiki/General_Code_of_Operating_Rules) Rule
> 6.28
> > it says
> > "...trains or engines must move at a speed that allows them to stop
> within
> > half the range of vision short of: Train, Engine, Railroad car, Men or
> > equipment fouling the track, a Stop signal or Derail or switch lined
> > improperly." (6-13 GCOR—Seventh Edition—April 1, 2015)
> >
> > This rule basically says it's a free for all and that it is the
> > responsibility of the train crew to provide the train protection.
> >
> > In the case of Positive Train Control this then becomes an additional
> > responsibility of the computer or system.
> >
> >
> > 2) I am working on my own data set with as many details as possible.
> > Below are the issues of this topic. We have two layers of
> information
> > to be provided, one is Authorization, Track Authority or permission
> that is
> > given to a train and we have oversight or digital control. Another
> thing
> > to consider is that more than two options below could be in effect on
> any
> > one track.
>
> Train protection in the context of this discussion means technical
> equipment installed in or very close to the track ensuring that
>
> - trains do not pass signals showing a stop aspect
> - distant signals with warning aspect are recognized by the driver
> - trains break between the distant and main signal
> - trains do not exceed speed limits
>
> Many modern systems (ETCS Level 2, LZB) include cab signalling where
> signals along the line are not necessary and everything is shown on a
> display in the engine.
>
> In some cases, there can be no equipment on the line. Imagine a train
> protection system stopping trains of opposite direction on a
> single-track line based on GPS measurements on the engine.
>
> Train protection systems ensure that trains do not violate movement
> authoritations by the dispatcher.
>
> What you describe are the operational rules and interlocking.
> Operational rules are difficult to map in a project as OpenStreetMap
> which has a strong On The Ground Rule (i.e. things need to be verifiable
> on the ground). One can see equipment on the track (balises, magnets,
> contacts etc.) but the detailed operation rules are not reflected by
> signs (e.g. a board with something like "Company A Rulebook ends here").
>
> Best regards
>
> Michael
>
>