Openstreetmap-carto: stop rendering shop=yes

[matkoniecz]

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 https://github.com/gravitystorm/openstreetmap-carto/issues/2099#issuecomment-254543095 and https://github.com/gravitystorm/openstreetmap-carto/issues/2099#issuecomment-254580699 ). It was used 81 483 times ( https://github.com/gravitystorm/openstreetmap-carto/issues/2099#issuecomment-254836689 )

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

[matkoniecz]

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]

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]

Related issues: see https://github.com/openstreetmap/iD/issues/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]

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]

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]

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]

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]

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]

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]

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]

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]

👍

[boothym]

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]

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]

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).

[matkoniecz]

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

[Marc-marc-marc]

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]

I find it slightly amusing that there is a rampage to suppress slightly unspecific, but not wrong tagging, but on the other hand https://github.com/gravitystorm/openstreetmap-carto/pull/371 still goes unfixed that actively promotes wrong tagging.

[imagico]

@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]

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

[simonpoole]

@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]

Yes, removing rendering of access restrictions is definitely an option to consider - to be discussed on the respective issues - see https://github.com/gravitystorm/openstreetmap-carto/issues/214#issuecomment-524541966.

[matkoniecz]

@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.