[Tagging] RFC - Discourage railway=preserved

Stefan Keller sfkeller at gmail.com
Fri Apr 16 11:11:17 UTC 2021


Martin wrote:

> and things get more complicated with exceptions, e.g. motorway_links are assumed to be oneway (as are motorways), so there are some cases where oneway=no is “required”.

Exactly. That's why modeling models facts in a self-descriptive way
mainly as value.

Kai, Jeroen

I did not propose railway=rail;preserved. That was a proposal from Mateusz.
I see now that railway is a primary tag.
And I agree that multiple values on primary tags should be avoided.
What we are speaking about here is a secondary tag.

I proposed for example(!):
 railway_train = museum | touristic | model | heritage | ... <<  or
 railroad_type = museum | touristic | model | heritage |... <<

Marc_marc had a probably even better proposal of key usage=* .

> While multiple values in a tag is inherently possible in OSM, there are
> a number of important tags that by convention do not do this to make
> live easier for data consumers such as navigation software and rendering
> frontends.

That is exactly one of the main arguments against namespaces making it
an anti-pattern in data modeling!

It's because processing namespaces maky typical queries impossible -
for something which is easy with multi-values separated with
semicolons:

With multi-values separated with semicolons it's easy to query
"railroad_type=*" while querying "railway:*=*" is heavy coding - and
almost impossible to index (because indexes require full attributes
names)!

With "railway:*=*" which is the consequence if you give "room" for
extensions of  "railway:*=*":
railway:preserved=yes
railway:model_train=yes
railway:history_train=yes

In iD (to take this well known editor) both - namespaced tags and
multi-valued tags - are somehow supported - but only somehow. The GUI
for namespaced tags works only either if there's an entry in the
presets - or if "yes" exists. => This means, that currently the iD
editor interprets "railway:preserved=non" as
"railway:preserved=yes"(!). This problem (GUI; interpretation; wrong
values) is the other main obvious deficiency of namespaced tags.

~Stefan



Am Mi., 14. Apr. 2021 um 15:22 Uhr schrieb Martin Koppenhoefer
<dieterdreist at gmail.com>:
>
>
>
> sent from a phone
>
> > On 14 Apr 2021, at 09:37, Jeroen Hoek <mail at jeroenhoek.nl> wrote:
> >
> > Tags like oneway=no act in
> > the same way. They are not needed for data consumers, but tell other
> > mappers that to be weary to change this tag to yes (with the
> > accompanying note often detailing the reason).
>
>
> and things get more complicated with exceptions, e.g. motorway_links are assumed to be oneway (as are motorways), so there are some cases where oneway=no is “required”.
> Or recently I had a discussion about overtaking=no being the typical situation on 2 lane roads in the US (it was at least presented like this), while overtaking=yes is the assumed default when the tag is missing.
>
> Cheers Martin
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list