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
