[Tagging] RFC - Discourage railway=preserved

Stefan Keller sfkeller at gmail.com
Tue Apr 20 18:06:40 UTC 2021


Am Fr., 16. Apr. 2021 um 15:19 Uhr schrieb Mateusz Konieczny via
Tagging <tagging at openstreetmap.org>:

> > railroad_type = museum | touristic | model | heritage |... <<
> Still will end with ;-delimited expressions

Exactly - and this is no problem compared to namespaced queries -
except just for the half-boolean case "key:namespace=yes".

Just to remember again:

> > It's because processing namespaces maky typical queries impossible -

> This is untrue with nearly any sane system method of making queries.

So please show me the SQL query for a search of "railway:*=*".

> Neither railroad_type=* nor railway:*=* are actually useful queries.

This is a dis-respecting (or trolling? or just unexperienced?) argument.

> All that problems are present in both systems

MySQL/MariaDB and Oracle do not even have a Boolean type (they use
TINYINT(1) instead).

In other databases, like PostgresQL, booleans take same space a whole byte.

An index on a boolean column is only useful 1. in data warehouse
scenarios (where it can be combined with other indexes via a bitmap
index scan) and 2. if only a small fraction of the table has the value
TRUE (or FALSE for that matter).

> > And taking iD as an interesting choice.

Did you understand the severe bug I described in iD (interpreting any
non-no value of a namespaced tag as "yes)?

~ Stefan

Am Fr., 16. Apr. 2021 um 15:19 Uhr schrieb Mateusz Konieczny via
Tagging <tagging at openstreetmap.org>:
>
>
>
>
> 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
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list