[Tagging] RFC - Discourage railway=preserved

Mateusz Konieczny matkoniecz at tutanota.com
Fri Apr 16 13:12:07 UTC 2021




Apr 16, 2021, 13:11 by sfkeller at gmail.com:

> I did not propose railway=rail;preserved. That was a proposal from Mateusz.
>
it was NOT something that I proposed. I was trying to understand what
you want to use an alternative, and this was fitting description
(as I understood it).

> I see now that railway is a primary tag.
> And I agree that multiple values on primary tags should be avoided.
>
+1

> 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 |... <<
>
Still will end with ;-delimited expressions

> It's because processing namespaces maky typical queries impossible -
>
This is untrue with nearly any sane system method of making queries.
In fact in most of them namespaced tags are nicer to handle
(this is not sufficient to prefer namespaced tags, but...).

> 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)!
>
Neither railroad_type=* nor railway:*=* are actually useful queries.

For actually used queries indexing boolean results will be typically
much easier and better supported than indexing fulltext searches.

> This problem (GUI; interpretation; wrong
> values) is the other main obvious deficiency of namespaced tags.
>
All that problems are present in both systems 

And taking iD as an interesting choice.
As it has bigger problems  with ;-delimited values than namespaced tags.
iD even introduced entire groups of namespaced tags because it was
solving limitations of iD presets
(this is not sufficient to prefer namespaced tags, but taking iD
as proof that namespacing is harder to process is weird).

>
>
> 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
>>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210416/647eb705/attachment.htm>


More information about the Tagging mailing list