[Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
bkil.hu+Aq at gmail.com
Sun Mar 24 11:03:21 UTC 2019
What about these (also added to the wiki talk page)?
Although this one had a reasonable purpose of describing performance,
most values seem to be "yes":
Some correctly documented ones are misused quiet often:
TagInfo reveals many more combinations for the above documented ones,
but here exist undocumented ones too:
On Mon, Jan 7, 2019 at 2:24 AM Warin <61sundowner at gmail.com> wrote:
> On 07/01/19 10:27, Stefan Keller wrote:
> > Hi,
> > After an answer by Rtfm/ti-lo at namespace wiki page  (thanks!) I
> > have to add some thoughts, especially regarding the multiple values!
> > Initially I thought it's just about namespaces which I'm calling
> > "prefix-fooling" or pseudo-boolean-namespaces. "Pseudo" because users
> > start adding other values to yes/no like yes/no/maybe.
> > My main concern with prefix-fooling or pseudo-boolean-namespaces is
> > not against namespaces in principle. But this "new-style" tagging has
> > a strong tendency to defragment OSM and to loose a sense of
> > reusability. I've listed several problems above. See e.g. "Shop
> > subtags proposal"  as a negative example well because it's key
> > fragmentation in the form
> > "<anyshop_or_service>:<WhateverValue>=yes/no". Looking at the example
> > in :
> > Now I realize, that there are three fundamental questions behind this
> > "new-style" tagging:
> > First it's about how to describe objects which contain two 'top-level'
> > tags, like shop=bicycle and shop=motorcycle (see rationale on ). We
> > have had this issue with businesses for long time on how to combine
> > e.g. restaurant, bar, hotel, bakery etc.. => IMO I'd handle this as
> > separate POIs as long as possible.
> I would like to see the same system used for these features that sell things, rather than have each business develop tags that are incompatible.
> For example https://wiki.openstreetmap.org/wiki/Key:service has 2 different methods .. depending on which shop your detailing ... Why?
> I would think a set of common tags for all shops and similar features that can use them, should be developed and then any other tags depreciated.
> > Second, it's about grouping subtags: Namespaces are an attempt to
> > this. But this is aka redundant to curated presets...
> > The third and to me most important issue is about handling multiple
> > values ! Multiple values are undoubtedly a data modeling
> > requirement. They have been handled so far nolens-volens by the
> > semi-colon value separator  - now with a trend to pseudo-boolean
> > namespaces. Admittedly, processing semi-colon separated fields is
> > complex and only few SW can process it. I suspect the reason behind is
> > it's that multiple values are't handled by programming languages out
> > of the box (databases like Postgres support that not only as data
> > types but also in queries).
> > Just recently the iD Editor maintainer added more multiCombo functions
> > (like ) and presets key (like "service:vehicle" ). Both is OK
> > per se, but the latter preset was undocumented on the Wiki, and
> > obviously the iD Editor maintainer prefers namespaces over semicolons
> > for handling multiple values - and both issues seem to be completely
> > undiscussed!
> > => So I urgently propose to discuss and sort of out this multiple
> > values, respectively "semi-colon vs. pseudo-boolean-namespaces" issue!
> > :Stefan
> > P.S. I'm now tending to accept new-style boolean-namespaces - but only
> > under certain conditions. These conditions start with the usual ones
> > (see the proposal process) complemented perhaps by the following:
> > * Is it just about grouping? If yes, obstain from namespaces and look
> > at presets and document it rather in the wiki.
> > * Can the proposed key be re-used with/by other objects? If yes,
> > obstain from (over-specific) namespaces and try to choose a more
> > common or generic and simple key-value tag.
> > * Is the proposed key namespace in Mixed Case? If yes, this is a
> > strong smell indicating that it's a value. So choose a more common or
> > generic and simple key should.
> > * (See also the six "consequences of prefix-fooling" in my mail above).
> >  https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling
> >  https://wiki.openstreetmap.org/wiki/Proposed_features/shop_subtags
> >  https://github.com/openstreetmap/iD/issues/5291
> >  https://wiki.openstreetmap.org/wiki/Key:service:vehicle
> >  https://wiki.openstreetmap.org/wiki/Multiple_values
> >  https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
> > Am Sa., 5. Jan. 2019 um 16:42 Uhr schrieb Markus <selfishseahorse at gmail.com>:
> >> On Thu, 27 Dec 2018 at 02:05, Stefan Keller <sfkeller at gmail.com> wrote:
> >>> It's really turning processing of key-values (or key-value pairs KVP,
> >>> entity-attribute-values EAV, dictionnaries, associative arrays, map
> >>> collections, Hash stores/hstores) ad absurdum. In addition to the
> >>> troubles of over-namespacing mentioned above there are following
> >>> consequences of prefix-fooling - among others (sticking at the example
> >>> "service:bicycle:retail=yes;service:bicycle:repair=yes;"):
> >>> * Existing code to validate and cleanup values is in vain: One can't
> >>> check with usual functions if a value is in range
> >>> "retail,repair,second_hand".
> >>> * Existing code to match is in vain too: Prefix-fooled keys pretend to
> >>> have mixed cases (which they should'nt).
> >>> * Worse, users still extend "yes/no" values to arbitrary values (which
> >>> again makes processing unnecessarily complicated).
> >>> * Even worse, users are encouraged to invent new sparsely used keys
> >>> (which we can't prevent, but it's less harmful in the values).
> >>> * Source code is flooded by boolean expressions (which would else be a
> >>> single function) and need to be predefined in the code (instead of
> >>> being put in values).
> >>> * Values in namespaces/prefixes/suffixes are hard or impossible to
> >>> search, match, count or group in computer languages, including SQL.
> >> I'm a bit late but thank you, Stefan, for your explanation!
> >> Regards, Markus
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging