Skip to content
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

Closed
matkoniecz opened this issue Mar 29, 2016 · 26 comments
Closed

stop rendering shop=yes #2099

matkoniecz opened this issue Mar 29, 2016 · 26 comments

Comments

@matkoniecz
Copy link
Contributor

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.

@aceman444
Copy link

So why do we not render any shop=*?

@HolgerJeromin
Copy link
Contributor

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

@moliha
Copy link

moliha commented Mar 29, 2016

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:

  • The responsible mapper gets no feedback.
  • Other mappers, who might be able to fix the problem, are not alerted because it is hidden.
  • Map users see nothing where 'something' (and a name) could be usefull.

@aceman444
Copy link

Holger, typoed values would only show as the dot, not the specific icon, so that would be visible.

@HolgerJeromin
Copy link
Contributor

Oh, sure. This requires that you are familiar with the rendering of all valid shop values.
But shop=frame would look the same as shop=frames and
shop=fabrics will look like the correct shop=fabric

@HolgerJeromin
Copy link
Contributor

this style is no QA map. Many websites are using the tiles. There a question mark would be very confusing.

@pnorman
Copy link
Collaborator

pnorman commented Mar 30, 2016

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.

@sommerluk
Copy link
Collaborator

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…

@d1g
Copy link

d1g commented Apr 21, 2016

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

@martinum4
Copy link

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

@gorn
Copy link

gorn commented May 22, 2016

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.

@jojo4u
Copy link

jojo4u commented May 22, 2016

Either

  • use whitelist and render shop=yes

or

  • drop whitelist and don't render shop=yes.

@aceman444
Copy link

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.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 18, 2016

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 building=yes and shop=yes.

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:] shop_values.rb was good as initial tool, but now we have already few exception in it and the fresh output is not directly applicable to the code, since we should also manually remove all the popular shops we have in the second list. So even adding new types is a maintainer's nightmare.

@d1g
Copy link

d1g commented Oct 18, 2016

Therefore I'd like to implement gorn proposition.

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

drop whitelist and don't render shop=yes.

will we render shop=* instead of shop=yes? I think that's the same what pnorman and me said.

Nobody objects gorn formulaiton?

@jojo4u
Copy link

jojo4u commented Oct 18, 2016

I personally don't understand proposition by @jojo4u - how can have generic style for shops with

drop whitelist and don't render shop=yes.

will we render shop=* instead of shop=yes? I think that's the same what pnorman and me said.

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.

@kocio-pl
Copy link
Collaborator

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.

@HolgerJeromin
Copy link
Contributor

10% of shop=yes are combined with amenity=fuel (from old? JOSM preset) which are not rendered anyway as shop.

@kocio-pl
Copy link
Collaborator

BTW: there are quite a lot of actual "shop=*" tags in OSM database (though explicitly discouraged):

http://taginfo.openstreetmap.org/tags/shop=*

@dieterdreist
Copy link

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

@kocio-pl
Copy link
Collaborator

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

@dieterdreist
Copy link

sent from a phone

Il giorno 19 ott 2016, alle ore 13:54, kocio-pl [email protected] ha scritto:

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.

+1
shop=yes could be discussed on the tagging ML, but it's use is already discouraged in the wiki: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dyes

similarly issues are historic=yes, barrier=yes (both with significant use)

@kocio-pl
Copy link
Collaborator

Well, it's significant just in raw numbers, but the percentage is quite low and that's more important factor for me:

  • historic=yes: 43 339 - 6.62%
  • barrier=yes: 54 765 - 0.80%
  • shop=yes: 81 483 - 3.44%

On the other hand we have also:

  • building=yes: 167 196 748 - 82.12%

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.

@gorn
Copy link

gorn commented Oct 19, 2016

This issue should be closed as declined.

@kocio-pl
Copy link
Collaborator

I guess it's better to change the title so it describes the problem more precisely.

@matkoniecz
Copy link
Contributor Author

See #3697 - I proposed this change again as usage of shop=yes is growing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests