stop rendering shop=yes #3697

matkoniecz · 2019-02-24T17:39:51Z

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 #2415 all shop values except 'no', 'vacant', 'closed', 'disused', 'empty' are rendered.

In #2099 I proposed to stop rendering shop=yes to encourage more specific tagging but it was rejected.

I propose to reconsider this as since that time usage of shop=yes is increasing what is undesirable.

In 2016 "Shop=yes is used only for 3.44% of all the shop types" and "10% of shop=yes are combined with amenity=fuel (from old? JOSM preset) which are not rendered anyway as shop." (quoted from #2099 (comment) and #2099 (comment) ). It was used 81 483 times ( #2099 (comment) )

Currently shop=yes usage is growing and reached 149 194 uses (4.05% of all shops). It includes 9 476 shop=yes on amenity=fuel (6.35% of shop=yes), for 139 718 unspecified shops.

EDIT: 149 222 at 2019-02-25

The text was updated successfully, but these errors were encountered:

matkoniecz · 2019-02-24T17:44:32Z

What changed since #2099:

usage of shop=yes keeps growing (no matter how it is measured)
now rarely used shop types are displayed (in fact, any shop value except explicitly blacklisted is rendered) so retagging shop=yes is always a viable solution
for the same reason there is no longer pressure to mistag say shop=flower_pot as shop=florist to get it rendered, so shop=yes escape clause is now longer needed

kocio-pl · 2019-02-24T18:40:00Z

After #2415 it sounds sane for me.

I don't feel 3.44%->4.05% in ~3 years is a serious problem growth, but since with a little effort (adding anything more specific - we don't force what should it be) rendering can be fixed, I guess we can go for it anyway.

matkoniecz · 2019-02-24T18:41:32Z

Related issues: see openstreetmap/iD#5955 and https://josm.openstreetmap.de/ticket/17377

I will wait before making a PR, maybe people will present good reasons why shop=yes is a valid tagging.

And in any case it is desirable that validators (or at least JOSM validator) will emit warnings before rendering changes.

Adamant36 · 2019-02-25T00:58:05Z

maybe people will present good reasons why shop=yes is a valid tagging.

In cases where there isn't a good sub-tag to use but its still useful for the name and default dot to display?
I ran into that problem yesterday when I was mapping a ear piercing shop. There's no shop=ear_piercing tag that I could find, but it was still useful to display the name of the shop with shop=yes. Since it has the word "ear piercing" in it.

Its also helpful to have the dot there with the other ones when your zoomed out so you know the building isn't empty or not mapped yet.

kocio-pl · 2019-02-25T01:06:50Z

The idea is to start tagging shop=ear_piercing even if it does not exist today, because it gives more information than shop=yes. Even shop=unknown/unsure works better.

Adamant36 · 2019-02-25T01:14:10Z

Even shop=unknown/unsure works better.

Except I know its an ear piercing shop. Shop=yes isn't technically incorrect either. Since its a shop. Although I agree the better route would be to just tag it as shop=ear_piercing, I guess.

I tend not to just tag things randomly like that though, because it usually spurs messages later by certain users about how I should have used a different tag instead. That's a side issues though, but its probably part of why people use shop=yes when they do.

kocio-pl · 2019-02-25T01:21:07Z

It is technically fine, but since shop is so generic, I'd like to avoid generic value and promote specific ones this way. If the scale of it were broad (like building=yes - 82% instead of 4%) or the fixing was hard (lack of rendering for other values, as before #2415), I would not support this solution, but I think it's time to try this.

Adamant36 · 2019-02-25T02:03:17Z

Maybe it will force people to come up with new shop tags for the types of shops that don't have any yet at least.

matkoniecz · 2019-02-25T08:32:14Z

There's no shop=ear_piercing tag that I could find, but it was still useful to display the name of the shop with shop=yes

You are free to be first one to use the new tag and that would be better than using shop=yes.

And with current rendering any shop values are displayed so nothing would be lost as far as displaying in this map style goes (not sure about other map styles, but anyway better data is better than better rendering in the immediate future).

matkoniecz · 2019-02-25T11:55:32Z

https://josm.openstreetmap.de/ticket/17377#comment:4 - JOSM now warns about shop=yes, except where it is with amenity=fuel (in trunk, this version is not yet released)

matkoniecz · 2019-02-25T12:03:11Z

And to explain why in some cases I was unsure whatever stopping rendering of far less popular tags is a good idea and opposed oy and now I want to stop rendering of something used 150k times: I see significant difference between "tag was used, considered as a good tagging and now it is declared deprecated" and "tag was never considered as a good tagging".

In the first case people deprecating things may be mistaken or overenthusiastic and I really would prefer to avoid using this map style for deprecating tags. Primarily to ensure that discussions "is it something that should deprecated" will not take place on this issue tracker - what would be a bad thing for multiple reasons.

While on other hand reducing use of tagging that was never desirable is perfectly OK - even if it is popular.

matthijsmelissen · 2019-02-25T23:10:51Z

👍

boothym · 2019-02-26T21:46:35Z

Just to clarify - at the moment all shop tags are rendered except 'no', 'vacant', 'closed', 'disused', 'empty', and you want to add 'yes' to that list?

If so, I would agree with that. I think I've added some shop=yes objects because there wasn't a good enough tag and to get it rendered. But if it's going to be rendered anyway, might as well try to come up with a better tag.

matkoniecz · 2019-02-26T22:49:33Z

Just to clarify - at the moment all shop tags are rendered except 'no', 'vacant', 'closed', 'disused', 'empty', and you want to add 'yes' to that list?

yes, exactly

matkoniecz · 2019-03-15T08:08:10Z

JOSM and Osmose are now complaining (see http://osmose.openstreetmap.fr/en/map/#zoom=17&lat=50.0681&lon=19.9404&item=9002&level=1%2C2%2C3&tags=&fixable= for JOSM deprecation warnings, including for shop=yes in Osmose).

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

matkoniecz · 2019-03-15T10:49:14Z

PR #3718 is created, I posted to talk mailing list (second one may be a mistake).

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

Marc-marc-marc · 2019-08-23T20:20:31Z

add link to this strange idea https://lists.openstreetmap.org/pipermail/talk/2019-March/082268.html (thread not related to the idea that shop=yes is an error, but about shop=yes can be improved)

simonpoole · 2019-08-24T10:39:42Z

I find it slightly amusing that there is a rampage to suppress slightly unspecific, but not wrong tagging, but on the other hand #371 still goes unfixed that actively promotes wrong tagging.

imagico · 2019-08-24T11:09:45Z

@simonpoole - the issue in question is #214 - #371 was rejected not because of the idea of fixing access tag rendering but because it only considers motorcar - which is not really sufficient to address the problem. Access tagging of roads is complicated - see

https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

and someone would need to develop a scheme to render this in a suitable form without introducing a too large number of different styling variants to reasonably display on a general purpose map.

jeisenbe · 2019-08-24T11:11:05Z

@simonpoole, I think you mean to reference issue #214? We can discuss there.

simonpoole · 2019-08-24T11:49:43Z

@imagico access tagging might be complicated, but either not rendering it at all (my suggestion) or alternatively rendering the restrictions for all vehicle types the same is not. As it stands you are directly promoting wrong tagging.

imagico · 2019-08-24T12:32:07Z

Yes, removing rendering of access restrictions is definitely an option to consider - to be discussed on the respective issues - see #214 (comment).

matkoniecz · 2019-08-24T19:59:34Z

@simonpoole Mainly because fix here was trivial to implement, while for better access rendering there is not even pseudo code.

Rendering motorcar as access would just encourage a different kind of incorrect rendering.

matkoniecz mentioned this issue Feb 24, 2019

stop rendering shop=yes #2099

Closed

kocio-pl added the POI label Feb 24, 2019

kocio-pl added this to the Bugs and improvements milestone Feb 24, 2019

matkoniecz mentioned this issue Feb 27, 2019

import new validator rules from JOSM osm-fr/osmose-backend#467

Closed

matkoniecz mentioned this issue Mar 15, 2019

stop rendering shop=yes [ready for review] #3718

Merged

imagico closed this as completed in #3718 Aug 22, 2019

jeisenbe added the remove rendering label Jun 3, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

stop rendering shop=yes #3697

stop rendering shop=yes #3697

matkoniecz commented Feb 24, 2019 •

edited

matkoniecz commented Feb 24, 2019 •

edited

kocio-pl commented Feb 24, 2019

matkoniecz commented Feb 24, 2019 •

edited

Adamant36 commented Feb 25, 2019

kocio-pl commented Feb 25, 2019

Adamant36 commented Feb 25, 2019

kocio-pl commented Feb 25, 2019

Adamant36 commented Feb 25, 2019

matkoniecz commented Feb 25, 2019

matkoniecz commented Feb 25, 2019 •

edited

matkoniecz commented Feb 25, 2019

matthijsmelissen commented Feb 25, 2019

boothym commented Feb 26, 2019

matkoniecz commented Feb 26, 2019

matkoniecz commented Mar 15, 2019

matkoniecz commented Mar 15, 2019

Marc-marc-marc commented Aug 23, 2019

simonpoole commented Aug 24, 2019

imagico commented Aug 24, 2019

jeisenbe commented Aug 24, 2019

simonpoole commented Aug 24, 2019

imagico commented Aug 24, 2019

matkoniecz commented Aug 24, 2019

stop rendering shop=yes #3697

stop rendering shop=yes #3697

Comments

matkoniecz commented Feb 24, 2019 • edited

matkoniecz commented Feb 24, 2019 • edited

kocio-pl commented Feb 24, 2019

matkoniecz commented Feb 24, 2019 • edited

Adamant36 commented Feb 25, 2019

kocio-pl commented Feb 25, 2019

Adamant36 commented Feb 25, 2019

kocio-pl commented Feb 25, 2019

Adamant36 commented Feb 25, 2019

matkoniecz commented Feb 25, 2019

matkoniecz commented Feb 25, 2019 • edited

matkoniecz commented Feb 25, 2019

matthijsmelissen commented Feb 25, 2019

boothym commented Feb 26, 2019

matkoniecz commented Feb 26, 2019

matkoniecz commented Mar 15, 2019

matkoniecz commented Mar 15, 2019

Marc-marc-marc commented Aug 23, 2019

simonpoole commented Aug 24, 2019

imagico commented Aug 24, 2019

jeisenbe commented Aug 24, 2019

simonpoole commented Aug 24, 2019

imagico commented Aug 24, 2019

matkoniecz commented Aug 24, 2019

matkoniecz commented Feb 24, 2019 •

edited

matkoniecz commented Feb 24, 2019 •

edited

matkoniecz commented Feb 24, 2019 •

edited

matkoniecz commented Feb 25, 2019 •

edited