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...@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 <61sundow...@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 > > > <selfishseaho...@gmail.com>: > > >> On Thu, 27 Dec 2018 at 02:05, Stefan Keller <sfkel...@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@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
