-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stop rendering shop=yes #2099
Comments
So why do we not render any shop=*? |
@aceman444 We do not want to hide typos for example. shop=suprmarket would be not valid (or a bad idea at least), so the default map should not provide the feedback that this is a correct entry. |
A general problem-icon could be usefull - this could be a small question mark. This could mark the node as questionable - but the name could be shown. Hiding problem-nodes is the worst "solution" for all:
|
Holger, typoed values would only show as the dot, not the specific icon, so that would be visible. |
Oh, sure. This requires that you are familiar with the rendering of all valid shop values. |
this style is no QA map. Many websites are using the tiles. There a question mark would be very confusing. |
My personal preference is to render shop=* as a dot, but instead we decided to whitelist specific shops. Given this choice, I'm not sure it makes sense to render shop=yes. |
The example is a shop=flower_pot. Maybe, if shop=yes is not rendered anymore, people tend to use related, but wrong tags. I could imagine that someone would use shop=florist instead to get it rendered, and that would be worser than shop=yes… |
For simplicity, render shop=* (except shop=no or shop=vacant) as dot. Whitelist-only rendering both: is unrewarding for mappers and painful for style developers. UPD: gorn explained my proposal better below |
i agree with sommerluk here, we get highly different names for the same stuff, especially regarding AE/BE there will be different writing of the same stuff then and it will be harder to clean it up afterwards... |
I think that the solution is really easy. Render shop=* (except shop=no or shop=vacant) as dot and have specific icon for some often used types of shops. That way if the shop is something common you give visual feedback, that the type is set correctly (icon vs dot) and if it is a rare shop, than you do not encourage fake it by marking it as common category yet rendering it. |
Either
or
|
Good point gorn. If any shop will not show at least the dot, people may fake the shop value to get it rendered. Faking as in using some close enough shop type, or just marking everything a supermarket or convenience. |
I think we should follow the buildings way: there are some special cases (major building rendered in dark brown and popular shops with their own icons), but most of them are just standard and we can just render them accordingly (light brown for most of the buildings, violet dot for shops) - including At this moment we have two shop white lists - popular shops and shop types we consider sane - which is an overkill for general style. One list should be enough. We have about 100 lines (3-4%) just to filter the less used ones and it would probably grow over time to include new types which have passed the lower limit. It also means we try to take the responsibility to review this list from time to time to get rid of deprecated ones. And it's not happening - I've tried to do it year ago, but got stuck in discussions on Tagging list, because in reality it's a cleaning/defining work, and it's even harder than proposing new types. @HolgerJeromin is right: osm-carto is not a QA tool. Maybe this attitude was useful some time ago, but the OSM ecosystem is growing and we should let some things go where they really belong to. Therefore I'd like to implement @gorn proposition. [UPDATE:] |
Well go ahead, because in my understanding everyone supporting his view of generic icon/rendering - incuding aceman444, moliha, pnorman and me I personally don't understand proposition by @jojo4u - how can have generic style for shops with
will we render shop=* instead of shop=yes? I think that's the same what pnorman and me said. Nobody objects gorn formulaiton? |
This same as gorn, only with additional proposition to drop generic shop=yes (somewhere in future) and use shop=* instead. Shop=yes is bad because it looses information and does not give a change to converge values via taginfo and wiki. |
Shop=yes is used only for 3.44% of all the shop types, so not a big problem and we can consider dropping it after some passage of time. Currently it may be misused to get less popular shops rendered, so probably it will get even lower than today. |
10% of shop=yes are combined with amenity=fuel (from old? JOSM preset) which are not rendered anyway as shop. |
BTW: there are quite a lot of actual "shop=*" tags in OSM database (though explicitly discouraged): |
I also don't like rendering shop=yes, because I share the concern that it will lead to less precise tagging. Rather than using a form shop= (which is not rendered at all for shop types not on our whitelist) some mappers will use shop=yes which is rendered. I would either drop rendering support for shop=yes or render every kind of shop besides shop=no/vacant (and maybe some other values). |
@dieterdreist The numbers show me that although shop=yes misuse is a real problem, it's not as big as we all thought. Do you agree to start with rendering rare shops now and revisit the issue of shop=yes later if needed, as @jojo4u proposed? For me this would be the easiest and safest solution for now. |
sent from a phone
+1 similarly issues are historic=yes, barrier=yes (both with significant use) |
Well, it's significant just in raw numbers, but the percentage is quite low and that's more important factor for me:
On the other hand we have also:
Any popular tag will have some general values and this may mean just lack of detailed knowledge. When the percentage is low, it's pretty healthy to state it clearly. Buildings may need some special treating, but I guess rendering is not the right tool to fix it. |
This issue should be closed as declined. |
I guess it's better to change the title so it describes the problem more precisely. |
See #3697 - I proposed this change again as usage of shop=yes is growing. |
Rendering shop=yes and not rendering rare shop values encourages to omit detail during tagging - for example I almost tagged https://www.openstreetmap.org/way/406428679#map=19/50.07983/19.87729 as shop=yes just to get it to render on map.
I think that it is not a desirable effect.
The text was updated successfully, but these errors were encountered: