Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
On Mon, 1 Apr 2019 at 08:38, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 31. Mar 2019, at 22:44, bkil wrote: > > > > I guess that you want to indicate a recycling container that also > > includes a non-recycling communal waste compartment. > > > None of these are tags I have ever used (in this combination), they are > examples from taginfo. > Like you I can only guess what the mappers might have wanted to express. > We've got bins in our local shopping centre that are triples! Rubbish goes in this part, bottles & cans in there, & paper / cardboard / plastic in that part. Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
sent from a phone > On 31. Mar 2019, at 22:44, bkil wrote: > > I guess that you want to indicate a recycling container that also > includes a non-recycling communal waste compartment. None of these are tags I have ever used (in this combination), they are examples from taginfo. Like you I can only guess what the mappers might have wanted to express. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
sent from a phone > On 31. Mar 2019, at 22:41, Stefan Keller wrote: > > No, because amenity=school and amenity=place_of_worship are aka > "top-level" keys (= main entities, main concepts) with one to several > sub-keys. this is also my interpretation, but this distinction is not always clear, and it may shift with the time (first used as qualifying tag for something (subtag), then it becomes a main key). And “school;place_of_worship” could be a class on its own, who knows, it isn’t documented, but neither are multiple values for top level tags. Ciao, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
I strive to separate all entities by function to a reasonable extent. > what about amenity=school;place_of_worship > is this desirable tagging? > > What does it mean? A mix of a school and a place_of_worship or a place of > worship and a school? > Could you please give us more information on this one? > amenity=bench;wastebasket > It would be best to create two separate nodes, one with amenity=bench and another one with amenity=waste_basket placed at the exact positions. Although there already exists a sane tagging shortcut for just this: amenity=bench + bin=yes https://wiki.openstreetmap.org/wiki/Key:bin > amenity=wastebasket;recycling > I guess that you want to indicate a recycling container that also includes a non-recycling communal waste compartment. By mechanically translate the wiki page, we arrive at the following: amenity=recycling + recycling=paper;glass_bottles;waste Or even better would be to create two separate nodes, one with amenity=recycling + recycling=paper;glass_bottles and another one with amenity=waste_basket placed at the proper container positions. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
Hallo Martin Am So., 31. März 2019 um 22:01 Uhr schrieb Martin Koppenhoefer : > what about amenity=school;place_of_worship > is this desirable tagging? No, because amenity=school and amenity=place_of_worship are aka "top-level" keys (= main entities, main concepts) with one to several sub-keys. :Stefan Am So., 31. März 2019 um 22:01 Uhr schrieb Martin Koppenhoefer : > > > > sent from a phone > > > On 31. Mar 2019, at 18:07, Stefan Keller wrote: > > > > 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). > > > what about amenity=school;place_of_worship > is this desirable tagging? > > What does it mean? A mix of a school and a place_of_worship or a place of > worship and a school? > > amenity=bench;wastebasket > amenity=wastebasket;recycling > > > Cheers, Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
sent from a phone > On 31. Mar 2019, at 18:07, Stefan Keller wrote: > > 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). what about amenity=school;place_of_worship is this desirable tagging? What does it mean? A mix of a school and a place_of_worship or a place of worship and a school? amenity=bench;wastebasket amenity=wastebasket;recycling Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
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 : > > 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
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
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 > > ":=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
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
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 ":=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 : On Thu, 27 Dec 2018 at 02:05, Stefan Keller 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
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
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 ":=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. 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 : > > On Thu, 27 Dec 2018 at 02:05, Stefan Keller 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 > > ___
Re: [Tagging] Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop over-namespacing and prefix-fooling
On Thu, 27 Dec 2018 at 02:05, Stefan Keller 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
