[openrailwaymap] Re: Using pzb and lzb absence for "no train protection"

I'd love any information you can send regarding any sort of route number in use here like you're discussing. I've worked around the US rail industry for several decades (federal bridge engineer), and have never heard of such a thing, so I'm very curious. You're not talking about the FRAARCID in the FRA dataset, right? And I have to say, while "don't tag for the renderer" is almost always right, it also doesn't mean that a tag that works well already is automatically wrong, provided it also doesn't damage the validity of integrity of your dataset. Thanks! Chuck On Fri, Jun 12, 2020, 10:53 PM Christopher Parker < conductorchris(a)gmail.com&gt; wrote: > > 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"). > > It seems to me that in regards to mapping train protection/train > control/operating rules, that we have several considerations going for us: > > - There may be no physical infrastructure to an operating rule, but > there is consistent behavior. Consistent behavior can be observed, > physically. > > - It is appropriate to map speed limits on roads. While these are > generally accompanied by speed limit signs, legally (at least in the > United States) it is not the sign that governs, it is the legal status > of the limit. If protesters remove or change the signs, the legal speed > limit does not change. Thus when mapping operating rules, the "legal" > status of the tracks is what governs, not the presence of > infrastructure. If some vandal removed the signal, train crews are > still required to stop for it. > > - legal operating rules also matter for roadways that are public or > private. They should be mapped differently to avoid confusion even > though there may be no physical infrastructure to distinguish them. > > - This is information which would be useful to the community (including > myself, personally) and would not interfere with any existing features. > It is the kind of information that already appears on other maps and has > for at least a hundred years (I have such maps in my collection). Seems > to me that the default should be to favor usefulness. > > Christopher Parker >