[Tagging] insurance health

[Greg Troxel]

On 2020-04-14 21:16, Joseph Eisenberg wrote:
> OK, but are there any countries in the world where you can would
> normally buy health insurance in the same place as car or home or life
> insurance?

I don't know.  Many countries might not even allow this.

> If not, then this is a theoretical problem only.

The problem is having a messy namespace with tags that sort of mean the 
same thing, but aren't the same, which makes understanding the data much 
harder, for what I view as no good reason.

> "if you  want to  ask "how many insurance offices are there and what
> is the breakdown by type", it's much more natural to search one key..."
> 
> It's all one key either way ("office"), and database users already are
> very accustomed to searching for more than one tag to find a set of
> similar things. It only takes a few more seconds to add another tag to
> an Overpass-API query.

It's not the time to change the query.  It's the semantic load on 
everything that looks at the data.  Every renderer and search program 
has to learn about this.   That's not so bad in terms of work, but when 
they don't know about it, users get missing results.

> But it takes more time for each mapper to add 2 tags instead of one.
> Mapper time is the most precious resource in OpenStreetMap: we don't
> have enough mappers, and most are working for free, for fun.

I also have to often tag "barrier=wall" "wall=dry_stone".   Should we 
than have "barrier=wall_dry_stone" to save me a few keystrokes?  This 
way becomes madness if taken to the extreme with every detail promoted 
into the top-level tag.

In my mapping of POIs, the big amount time is actually going places. 
The next biggest is having to read the wiki to figure out what tags to 
use for things that I haven't mapped before.   When using vespucci, 
another big thing is actually typing the name correctly.

If there is a preset for "insurance" and  a subtype for what kind, I 
think most people would complete their tagging in seconds.   And this is 
something that isn't super common, and many people mapping it will be 
tagging one, very occasionally.

So I really think this de-normalized tagging, to use db terms, is a 
false optimization that doesn't help anyone.

> Let's make things as easy as possible for mappers: one tag for one main feature.

That is begging the question of "main feature", and what's easy.

We have to have summarization or we will have thousands of top-level 
tags.  To me, a business that sells insurance is a kind of thing, and 
sensible to label.   Labeling what kind is perhaps of value, but I don't 
see people shoppingfor health insurance by searching for such places.

And, having a preset with a choice pulldown makes it easy.  Having a 
top-level shop preset choice with 10x the number of things in it is not 
easier, as it becomes too big to scan through.