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

Shop rendering suggestion #2619

Closed
ghost opened this issue Apr 24, 2017 · 6 comments
Closed

Shop rendering suggestion #2619

ghost opened this issue Apr 24, 2017 · 6 comments

Comments

@ghost
Copy link

ghost commented Apr 24, 2017

You might think "Oh no, not again."

I read a bit into #2444, but I don't think my ideas fit into the discussion.

I can do programming, but I dont know, how osm-carto works. Therefore I might suggest things already implemented.

  1. osm-carto should not limit the shop icons. If something is forked from it, this maybe useful (i.e. an interactive shopping map).
  2. osm-carto should only map the 20 (or what-number-ever) most often shops (see https://taginfo.openstreetmap.org/keys/shop#values)
  3. Which kind of shops are or arent mapped should be determined by a stylesheet (list of booleans). For every zoom level, there can be another stylesheet. i.e. on zoom level x only the 5 most often mapped shop types are rendered.
  4. Introduce another highest zoom level with the same zoom of the highest level. If you enlarge it to the largest (and most detailed size), it renders simplified. If you zoom in once again, it doesnt enlarge anymore, but shows the shop icons. This is just an idea.

In addition, I have several icon contributions:
On my wiki user page

  • There should be definitely a ruins icon. I can add a ruins icon for things like houses and churches, if requested.
  • tyre shops and funeral directors are one of the more frequent shops
  • the perfumery icon is an alternative since the current one contains particles which affect the readability.
@dieterdreist
Copy link

dieterdreist commented Apr 24, 2017 via email

@ghost
Copy link
Author

ghost commented Apr 24, 2017

I agree on that. building=ruins shouldn't be rendered, because there are too many meaningless ruins. But imho building=castle;ruins=yes should be rendered that way. Most (german) maps differentiate between several types of sights (church, castles and abbeys) and have a corresponding ruins icon for every type.

@HolgerJeromin
Copy link
Contributor

Please open only one issue per request. Ruins/castles are handled here: #744 #331

@imagico
Copy link
Collaborator

imagico commented Apr 24, 2017

Hello MaestroGlanz, thank you for the suggestions but please separate different subjects into different issues - ruins have nothing to do with shops and should not be discussed in the same issue. What shops to show at which zoom level is also fairly separate from what types of shops to show at all.

Otherwise your suggestion four is outside the scope of of this project, this would involve larger changes in the rendering framework and in map display on the website.

Design wise we quite definitely do not want to decide on priorities purely based on how frequently things are mapped. While normally mappers tend to map things important for them with priority there are many cases where important types of features (like types of shops) are fairly rare in reality while less important ones are more frequent so with that approach you would often get a map that is not very useful. There are also other influences that distort mapping frequency like imports and visibility differences and there is an immense cultural bias in this approach as well (most mapping is done in Europe so shop types rare in Europe but frequent and important elsewhere would not have a chance in global statistics).

@kocio-pl
Copy link
Collaborator

Most of your icons look nice for me, but are not readable in 14px, which unfortunately is how they appear on the map. I have some hopes only for shop=funeral_directors and I believe shop=tyres is good enough for osm-carto.

@kocio-pl
Copy link
Collaborator

I will close this issue, since it contains many problems, which makes this ticket hard to manage and discuss. Please fill individual tickets for each of them.

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

4 participants