with the "actively set railway:train_protection=no", is it possible to have this as a default rather than requiring it to be actively set to "no" - ie, assume no train protection unless someone has explicitly set it? In the absence of a known system, assuming there isn't one is possibly better than assuming that there is ..... 

Andy

On Mon, 1 Jun 2020 at 12:19, Rainer <r.elbing@gmx.de> wrote:
Hi Maarten,

I agree that the tags railway:pzb, railway:etcs etc. are chosen
awkwardly. The tag should express that these are train control systems;
now with railway:pzb=* you have to know that pzb is a train control
system. If somewhere in the world the system xyz is added, it is not
recognisable from the tag as train protection.
Therefore I suggest to change railway:pzb|etcs|lzb|atc|...=yes|no into
railway:train_protection:pzb|etcs|lzb|atc|...=yes|no . This would
provide more clarity and make it possible to actively set a
railway:train_protection=no to express that no train protection system
exists and to distinguish it from the lack of information.

Translated with www.DeepL.com/Translator (free version)

- Rainer

Am 31.05.20 um 23:31 schrieb Maarten Deen:
> On 2020-05-31 21:04, JJJ Wegdam via Openrailwaymap wrote:
>> Dear ORM community,
>>
>> As far as I know, the signalling layer renders train protection
>> absence as soon as a way contains railway:pzb=no and railway:lzb=no. I
>> implemented this throughout over 10 European countries. A user from
>> Belgium is now complaining about this. He argues that Belgium doesn't
>> have the PZB nor the LZB system anywhere in the country and that thus
>> these tags should not be in the country. Could you please provide your
>> thoughts on this complaint? You can contribute to the discussion at
>> https://www.openstreetmap.org/changeset/85628039#map=13/50.8173/4.3336
>> or reply to this email.
>
> I agree completely that you should not tag railway:pzb=no or
> railway:lzb=no in countries where there is no PZB or LZB. There is no
> default saying that having no train protection tags means it has PZB
> or LZB.
> Even in countries using PZB or LZB it should be considered superfluous
> to tag this since the default is no.
> Also tags like railway:etcs=no and railway:tbl=no that are still on
> some ways there I would like to disencourage very much. The default is
> no, so you don't have to tag that it is not there.
>
> It I look at the openrailwaymap signalling layer it says "no
> information" or "no protection" or PZB/ATB/LZB/ETCS.
> I assume that the renderer knows which tags are for train protection
> (a bad scheme IMHO, see 1) below) and only renders lines without any
> of those systems as "no information" and renders lines without
> PZB/ATB/LZB/ETCS as "no protection". If that is so then the solution
> is easy: change the legend tag "no protection" to "other train
> protection". And "no information" should be "no protection" if there
> is no positive tag saying there is train protection. Sure, you will
> have a lot of false negatives, but people will notice and will amend
> the tags.
>
> I wholeheartedly agree with Eimai. Do not go out and tag all the
> railway lines in the world with railway:pzb=no and/or railway:lzb=no
> just to get that map looking like you want to. He is right, this is
> tagging for the renderer.
> I see an area around Laon as well: railway:etcs=no, railway:kvb=no,
> railway:lzb=no, railway:pzb=no. Come one. There are 60 other train
> protection tags, add them as well, or why not?
>
> 1) It should be more like railway:train_protection:pzb=yes/no. Why is
> railway:pzb a train protection tag and railway:gnt not. This makes
> automation around these tags very difficult. When you add a new train
> protection tag, the program needs to know about it. If you use
> railway:train_protection:xyz, then everything starting with
> railway:train_protection: is about train protection, and if you don't
> recognize the type, then you know it is "other" for your purposes. If
> you add railway:xyz as a new train protection tag, you have to
> reprogram everything that is working with these tags.
>
> Maarten