[Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling

Sun Mar 24 11:03:21 UTC 2019

What about these (also added to the wiki talk page)?
https://wiki.openstreetmap.org/wiki/Key:currency#Subtags
https://wiki.openstreetmap.org/wiki/Key:payment#Keys
https://wiki.openstreetmap.org/wiki/Key:drink#Keys
https://wiki.openstreetmap.org/wiki/Key:brewery#Usage
https://wiki.openstreetmap.org/wiki/Key:diet#Tagging
https://wiki.openstreetmap.org/wiki/Key:fuel
https://wiki.openstreetmap.org/wiki/Key:socket#Tags
https://wiki.openstreetmap.org/wiki/Key:authentication#List_of_sub_tags
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmonitoring_station#Required
https://wiki.openstreetmap.org/wiki/Key:ref#Key_variations
https://wiki.openstreetmap.org/wiki/Key:recycling#Materials
https://wiki.openstreetmap.org/wiki/Key:recording
https://wiki.openstreetmap.org/wiki/Key:monitoring:weather#Instruments
https://wiki.openstreetmap.org/wiki/Kathmandu_Living_Labs/exposuresurvey#Services_rendered
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dgaelic_games
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkneipp_water_cure#Tagging

https://wiki.openstreetmap.org/wiki/Key:toll
https://taginfo.openstreetmap.org//search?q=toll%3A

Although this one had a reasonable purpose of describing performance,
most values seem to be "yes":
https://wiki.openstreetmap.org/wiki/Key:generator:output

Some correctly documented ones are misused quiet often:
https://wiki.openstreetmap.org/wiki/Key:building:use
https://taginfo.openstreetmap.org/search?q=building%3Ause%3A
https://wiki.openstreetmap.org/wiki/Key:vending
https://taginfo.openstreetmap.org/search?q=vending%3A
https://wiki.openstreetmap.org/wiki/Key:playground
https://taginfo.openstreetmap.org/search?q=playground%3A
https://wiki.openstreetmap.org/wiki/Seasonal
https://taginfo.openstreetmap.org/search?q=seasonal%3A

TagInfo reveals many more combinations for the above documented ones,
but here exist undocumented ones too:
https://taginfo.openstreetmap.org/search?q=project%3A
https://taginfo.openstreetmap.org/search?q=sells%3A
https://taginfo.openstreetmap.org/search?q=tickets%3A
https://taginfo.openstreetmap.org/search?q=communication%3A
https://taginfo.openstreetmap.org/search?q=emergency%3A
https://taginfo.openstreetmap.org/search?q=shop%3A
https://taginfo.openstreetmap.org/search?q=medical_service%3A
https://taginfo.openstreetmap.org/search?q=language%3A

https://taginfo.openstreetmap.org/search?q=education_system%3A
https://taginfo.openstreetmap.org/search?q=education_level%3A
https://taginfo.openstreetmap.org/search?q=education_form%3A
https://wiki.openstreetmap.org/wiki/Proposed_features/Education_2.0

https://taginfo.openstreetmap.org/search?q=health_specialty%3A
https://taginfo.openstreetmap.org/search?q=counselling_type%3A
https://taginfo.openstreetmap.org/search?q=medical_system%3A
https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0
https://taginfo.openstreetmap.org/search?q=provided_for%3A
https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0/Specialties

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 [1] (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" [2] as a negative example well because it's key
> > fragmentation in the form
> > "<anyshop_or_service>:<WhateverValue>=yes/no". Looking at the example
> > in [2]:
> >
> > 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 [2]). 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 [5]! Multiple values are undoubtedly a data modeling
> > requirement. They have been handled so far nolens-volens by the
> > semi-colon value separator [6] - 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 [3]) and presets key (like "service:vehicle" [4]). 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).
> >
> > [1] https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling
> > [2] https://wiki.openstreetmap.org/wiki/Proposed_features/shop_subtags
> > [3] https://github.com/openstreetmap/iD/issues/5291
> > [4] https://wiki.openstreetmap.org/wiki/Key:service:vehicle
> > [5] https://wiki.openstreetmap.org/wiki/Multiple_values
> > [6] 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
> https://lists.openstreetmap.org/listinfo/tagging