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

Stefan Keller sfkeller at gmail.com
Sun Mar 31 16:07:07 UTC 2019


Hi,

24. März 2019 12:05 bkil wrote:
> What about these (also added to the wiki talk page)?

Thanks for compiling this list of (over-)namespaced tags currently
which contain mainly yes and are mentioned in this wiki and/or
currently in use in OSM. I renamed the wiki subtitle from "What about
these?" to "List of namespaced tags with yes values" [1].

This steadily growing list gives an indication how critical the
situation in OSM is, given the fact and killer-argument, how difficult
it is to maintain (store, index, group) and search over-namespaced and
prefix fooled keys (as I described here [2]).

This deteriorates the quality of OSM - and it hurts, given the fact,
that there is a proven alternative with semi-colon separated values,
which even allows tagging no-values (e.g.
service=no_retail,retail,repair,second_hand).

:Stefan


[1] https://wiki.openstreetmap.org/wiki/Talk:Namespace#List_of_namespaced_tags_with_yes-values
[2] https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling

Am So., 24. März 2019 um 12:05 Uhr schrieb bkil <bkil.hu+Aq at gmail.com>:
>
> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list