Rendering rare shop values #2415
Conversation
|
The decision to render specific shops was a conscious decision, we wanted to avoid rendering mistakes like At the time we made the decision I would have preferred rendering |
|
#2099 has proposed solution in the title, but the problem description:
shows that the title is not precise, because not showing rare shops is the real source and shop=yes is just a common workaround - a valid general value which is probably misused. BTW - the misuse is marginal comparing to building=yes (3,44% vs 82.12% of total uses with given key). Therefore I think we could start with fixing the source and wait some time to see if any other action is needed, as proposed here. I like this solution, that's why I didn't exclude shop=yes. Is it OK for you or you want to decide also this question now? |
|
Thanks for bringing up the WHEN shop IN ('no', 'vacant', 'disused') OR shop IS NULL THEN NULL ELSE 'other' END, |
|
I've added some more shop values indicating that shop is non-existing - I took them from |
|
I'm going to go ahead and merge this. There are arguments either way on if it's better to have a whitelist of minor shop values from a tagging and cartographic viewpoint. What settles it for me is the maintenance issues. We haven't been maintaining the lists, the same large list is supposed to be identical in four places, and the queries shops are part of are already some of larger ones in the style. |
|
For the record, I disagree with this approach. It was a major improvement to avoid catch-all rendering, which this PR re-enables. I understand the lack of maintenance on the shops list but it would be better to maintain the list rather than re-introduce a catch-all. The proliferation of shop values is outside the scope of the repo, but the trouble we are having here highlights that this is in itself a problem that I would prefer tackled too. This would most likely be by introducing categories and subcategories of shops, rather than having hundreds of artificially discreet values. I'm not suggesting that this to be reverted, I just want to make my point here. |
|
The point is we were not able to maintain this list and I haven't find a better way. But if somebody find the right tool to control it (here or on the data level), I would be fine with it. Categories may be a good thing, not only for shops, but also for other objects. I even tried to introduce it once, but nobody followed and I didn't know how the implementation should look like. Do you have any ideas about it? |
|
You still have a whitelist of shop types that have a specific icon. All others should get just the dot. In that way, you still see typos, like the mentioned 'supermarkte', because it will only get a dot, instead of the mapper's expected icon. But it is still a shop despite the typo, so it should appear on the map. |
|
@aceman444 |
|
sent from a phone
in the end you won't end up with less tags for distinct shop types, it would just be easier to find them - maybe. This is also something the editors can provide without having it hardcoded into the tags, josm and others are already doing it. +1 to giving the shops list more care. I suggest to give more importance to an existing wiki definition rather than just usage numbers, and lower the threshold to a few hundred. |
|
I'm not too fond of this change too. We are not the map of shops, but it sometimes seems we are. They have gotten far too much attention and we should render much less than more. |
|
I've created a ticket to sort the things out, because the problem is not easy to define (let alone to solve). The #2444 is a better place to discuss it than a PR closed a month ago. |
|
@HolgerJeromin why not? If one is in the whitelist with specific icon, you will see if it didn't get it. If none has a specific icon, it means the value is not important yet (few usages worldwide), so then it is not even sure which value is the correct one. |
|
My example was clear: beds 2700 vs bed 1. |
|
So does 'beds' have a special icon? |
|
No and thats the whole point |
|
So in that case, how did you determine 'beds' is the proper value and not 'bed'? Once it is important enough and gets a special icon, the typos may show up (with dot instead of the expected icon). |
|
Ok, take One propose of this style is "feedback mechanism for mappers to validate their edits". I think most people does not call |
|
So was baby_goods only with dot and no icon? I think the feedback can then be solved with having 2 lists:
|
fixes gravitystorm#3697 Originally only shop with their own icons were rendered. Later popular shop values were also rendered - as dots without icons. This was deliberate decision to not render cases like shop=supermarkte Since gravitystorm#2415 all shop values except 'no', 'vacant', 'closed', 'disused', 'empty' are rendered. Given that any, even never used shop value is rendered and shop=yes is unreasonably popular it is deisrable to encourage more specific shop tagging. It may encourage using some new shop values and in some cases people will mistakenly create new tags duplicating existing ones, but standard shop types are still encouraged by using icons. shop tag currently has long tail of unusual shop types (with most tagged correctly - for example , some shop like this really exist), so data consumers need anyway some startegy for handling rare shop types. is currenly reported as a tagging mistake by decent validators (for example JOSM and Osmose). Note that this is not deprecation of a tag but stopping to render a deprecated tag. This tag was never considered as a sufficient for tagging shop type
fixes gravitystorm#3697 Originally only shop with their own icons were rendered. Later popular shop values were also rendered - as dots without icons. This was deliberate decision to not render cases like shop=supermarkte Since gravitystorm#2415 all shop values except 'no', 'vacant', 'closed', 'disused', 'empty' are rendered. Given that any, even never used shop value is rendered and `shop=yes` is unreasonably popular it is desirable to encourage more specific shop tagging. Dropping `shop=yes` may encourage using some new shop values and in some cases people will mistakenly create new tags duplicating existing ones, but standard shop types are still encouraged by using icons. shop tag currently has long tail of unusual shop types (with most tagged correctly - for example `shop=maps`, some shop like this really exist), so data consumers need anyway some strategy for handling rare shop types. `shop=yes` is currenly reported as a tagging mistake by decent validators (for example JOSM and Osmose). Note that this is not deprecation of a tag but stopping to render a deprecated tag. This tag was never considered as a sufficient for tagging shop type
fixes gravitystorm#3697 Originally only shop with their own icons were rendered. Later popular shop values were also rendered - as dots without icons. This was deliberate decision to not render tags with mistakes like shop=supermarkte Since gravitystorm#2415 all shop values except 'no', 'vacant', 'closed', 'disused', 'empty' are rendered. Given that any, even never used shop value is rendered and `shop=yes` is unreasonably popular it is desirable to encourage more specific shop tagging. Dropping `shop=yes` may encourage using some new shop values and in some cases people will mistakenly create new tags duplicating existing ones, but standard shop types are still encouraged by using icons. shop tag currently has long tail of unusual shop types (with most tagged correctly - for example `shop=maps`, some shop like this really exist), so data consumers need anyway some strategy for handling rare shop types. `shop=yes` is currenly reported as a tagging mistake by decent validators (for example JOSM and Osmose). Note that this is not deprecation of a tag but stopping to render a deprecated tag. This tag was never considered as a sufficient for tagging shop type
fixes #3697 Originally only shop with their own icons were rendered. Later popular shop values were also rendered - as dots without icons. This was deliberate decision to not render tags with mistakes like shop=supermarkte Since #2415 all shop values except 'no', 'vacant', 'closed', 'disused', 'empty' are rendered. Given that any, even never used shop value is rendered and `shop=yes` is unreasonably popular it is desirable to encourage more specific shop tagging. Dropping `shop=yes` may encourage using some new shop values and in some cases people will mistakenly create new tags duplicating existing ones, but standard shop types are still encouraged by using icons. shop tag currently has long tail of unusual shop types (with most tagged correctly - for example `shop=maps`, some shop like this really exist), so data consumers need anyway some strategy for handling rare shop types. `shop=yes` is currenly reported as a tagging mistake by decent validators (for example JOSM and Osmose). Note that this is not deprecation of a tag but stopping to render a deprecated tag. This tag was never considered as a sufficient for tagging shop type
Resolves #2099.
All the white lists for
othershops:have been replaced with just basic checking if it's really a shop:
I'm not familiar with SQL, but testing shows that it works. Does it make any sense to check also if
shopis not null to exclude all the shops having their own icons?