Rethinking shops rendering

[kocio-pl]

I think we should rethink shops rendering, because it seems we're not done with this topic. It's a tough matter, but let's look for a solid, long time solution instead of "fixing" it.

Different people might have different problems with it, like:

• too many shops at all (?)
• too many shops at some zoom level (too early)
• too many shops at some places
• too many icons
• too few icons
• catch-alls
• no tools for filtering shops
• maintainability of the list
• error checking (typos)
• amount of code needed
• shop definition (how is it different from amenity)

...and so on.

To avoid repeating the issues we already know and going off topic, I'd like to concentrate only on what is the most important annoyance for you personally and how far can we go with a solution to be still acceptable. Please, be precise. I see it as the only way to find a common ground instead of trying to get "as-much-as-it's-possible".

For me shops are one of the most important things on micromapping level in a big city (my main activity in OSM) - the buildings and streets being just a background there and only some amenities are that popular. If we could filter them somehow and show some of them later or make them less visible before z-max, that would be acceptable for me. The only thing I don't accept is the unmaintainable, hardcoded list not related to the rest of the project.

[mboeringa]

To avoid repeating the issues we already know and going off topic, I'd like to concentrate only on what is the most important annoyance for you personally and how far can we go with a solution to be still acceptable. Please, be precise. I see it as the only way to find a common ground instead of trying to get "as-much-as-it's-possible".

@kocio-pl , I still think this topic has a high risk of de-railing at the first turn in the track with this particular request...

While I agree the current shop rendering is unsatisfactory, I also think it is unsolvable through any of the current approaches to pre-rendering as part of the style.

Personally, and I said this before in other issue threads, I only see a real solution in a dynamic, Overpass based, rendering of shops. This will allow fancy stuff like personalized filtering of desired shop values, something completely impossible and unthinkable now on the main website.

Technically, this is implementable in a website, as witness-able through e.g. Marc Zoutendijk's "OpenPOIMap" map (http://openpoimap.org/).

However, a "simple" website like OpenPOIMap is not the same as the Rails port that runs the main OpenStreetMap website, API and all the editing infrastructure. That is a different beast AFAIU.

However, as far as I understood it, the Rails port that runs the map OpenStreetMap website, and all the underlying infrastructure, needs real work to allow better customization. If I am right, this is one of those things that in fact Andy @gravitystorm and some of the other maintainers are working on right now: to update the main website infrastructure to allow better customization and thus make it more future proof.

E.g. see Andy's blog:
https://blog.gravitystorm.co.uk/
and this issue Andy opened:
gravitystorm/openstreetmap-website#2

[pnorman]

Too many shop icons - both in the number we have in the style and the number that end up on the map.

[Klaus-Tockloth]

Start rendering the shops with small coloured dots and than continue, if there is enough space, with icons.

[matthijsmelissen]

I'm not convinced rendering for a place like this (stripmall in the middle) really improved.

Places like this have really become unreadable.

On the other hand, I like the rendering in small villages like this. Although even here one could wonder if the flower kiosks don't distract from the more important features like supermarkets.

The main problem I think is that the current rendering causes a visual overload that makes it hard to see the most important amenities/shops as a glance. Try for example finding a supermarket in the Birmingham example.

Start rendering the shops with small coloured dots and than continue, if there is enough space, with icons.

I like this idea as well. Sort of like how we render fountains or trees. Should we do this for all shops, or exclude shops people actually might search for, such as shops?

An even more radical idea is to render shops only with a name, without an icon.

I would be interested in seeing example renderings of both (and possibly other) ideas.

[gravitystorm]

what is the most important annoyance for you personally

Catch-alls.

the unmaintainable, hardcoded list

I'm interested to hear why this was unmaintainable, since we had a script to generate the list.

[d1g]

I'm interested to hear why this was unmaintainable

@gravitystorm, it was maintainable, but issue wasn't only technical. It was just slow from the mappers perspective.

With manually updated white-list you have to wait up to weeks or months until your newly created shop=* will be displayed.

With "catch all and display as dot" approach mappers would get a dot within 5 minutes without contacting anyone - especially if they don't know this Github list or English.

---

If we count all requests to add new shops (say, 2347 2350 2386) it means that script should be run frequently without human interference or issues (trust any new shop=* value except for no/disused and previously blacklisted and display them as dot)

UPD: interference word

[d1g]

shop definition (how is it different from amenity)

shop=* is a POI where you can buy goods. Good (tangible good or product) is a thing you can place in your pocket/car.
amenity=* is a terribly ambiguous English-only word. It is still not defined at OSM wiki.

infrastructure=* or public_infrastructure=* should be used 10 years ago. You don't need to translate "infrastructure" in other languages: https://www.wikidata.org/wiki/Q121359

https://en.wikipedia.org/wiki/Amenity is not translated in other languages.

[mboeringa]

amenity=* is a terribly ambiguous English-only word. It is still not defined at OSM wiki.
...
https://en.wikipedia.org/wiki/Amenity is not translated in other languages.

That is not entirely true. Probably a lot of languages have a word that describes something similar. The closest equivalent that I can come up with for Dutch, my native language, is "Voorziening", which is equally vague and ambiguous in Dutch as in English, but equally points to stuff that:

"In real estate and lodging, an amenity is something considered to benefit a property and thereby increase its value."

and can mean anything from having a nearby railway station to something as mondain as a pub around the corner, or a social facility or clinic in your neighbourhood, to something as small as a postbox to drop off your mail.

In Dutch, the word "Voorziening" even has a number of different meanings besides "amenity" in English. And yes, the word "Voorziening" has an equally poor Dutch Wikipedia page, only listing the different meanings, where "voorziening (geografie)" is the one closest to "amenity" in English:

https://nl.wikipedia.org/wiki/Voorziening

Probably, amenities are not much loved..., unless they raise the value of your property ;-)

[d1g]

"In real estate and lodging, an amenity is something considered to benefit a property and thereby increase its value."

There may be word in some languages. Point is that all of them are vague, if we pick vague definitions we will have (potentially endless) discussions A=bench, A=basket, A=pub, A=station, A=stadium, A=airport "this object is A" or "this object is not A".

I think there no specific word for given definition in Russian. The closest equivalent is "объекты(ов) недвижимого имущества" literal: "objects of the real estate"

See "Территориальные организации по государственной регистрации обладают правом осуществления регистрационных действий в отношении нижеперечисленных объектов недвижимого имущества: • земельных участков; • капитальных строений (зданий, сооружений); • незавершенных законсервированных капитальных строений; • изолированных помещений, в том числе жилых; • машино-мест."

amenity=bench and amenity=basket weren't mentioned in the quote; amenity=parking and amenity=parking_space were.

and can mean anything from having a nearby railway station to something as mondain as a pub around the corner, or a social facility or clinic in your neighbourhood, to something as small as a postbox to drop off your mail.

https://en.wikipedia.org/wiki/Good_(economics) - please note that this page translated right now in 59 languages

[pnorman]

the unmaintainable, hardcoded list

I'm interested to hear why this was unmaintainable, since we had a script to generate the list.

The biggest data point is how we were failing to maintain it. The script was a good idea, but this script wasn't working out in practice.

• The script contained a list of values with more than MIN_COUNT uses, but we wanted shop values that were not otherwise rendered
  ** If we added the shop values rendered to the script excluded list, then when adding a shop you'd need to add it to the MSS, SQL, script, and then rerun the script to update the second part of the SQL
• We didn't have a clear workflow for using the output of the script. It gives us a list, then we do what with it?

Even if we had a script and documentation which resolved those, I'd still have maintainability concerns.

[nebulon42]

So there would have been clearly the need on our side to improve the workflow before removing it. Or now re-introducing a better workflow for this. Maybe also more general. I have a similar opinion as @gravitystorm on catch-alls. One goal for openstreetmap-carto is (should be) to help preventing tag value inflation. Without whitelisting we are failing on this like with buildings and now with shops.

@d1g If there is a newly created shop value, why should it show up immediately on the map? If there are requests to render a new shop value, who says that they should be rendered in any case? This would lead to a un-curated map, which would be unusable.

Apart from that I also like the idea of @Klaus-Tockloth.

[kocio-pl]

What the Paul just wrote, plus the script had some exceptions - that means we were trying to do another level of data validation on our own, without clear rules. 100 uses limit was arbitrary but clear, but how do we know what is a typo - "bag" or "bags"? And what about wiki status - should we use it to decide? That should be done on data definition level, it doesn't belong to rendering.

[d1g]

a newly created shop value, why should it show up immediately on the map?

@nebulon42, because it exists IRL and won't be contested by other shops (in very same place).

shop=fireworks (only 99 items is osm!) still not rendered, there no single reason not to display single coloured dot for them (please check global overpass).

Threshold should be 10 or 30 or 50 but not 100.

Don't get me wrong, 100 shops is a huge shop chain. Not every city have that many shops of the same type.

data definition level

@kocio-pl, any shop=* value (except shop=no and shop=disused) is a shop (can be rendered using unspecific shop style). It was defined at wiki already. Custom and additional rendering are possible.

[nebulon42]

Yes, you are right. But that only works if the data definition level would be mandatory. But it isn't. Generally, everybody is free to add own tags. This is both a strength and weakness of OSM. So there have to be checks and balances and osm-carto is part of these checks and balances. This does not mean there shouldn't be guidelines and discussions.

@d1g I disagree here. What about typos? And about any shop value. Is shop=brweoirjf a shop? How do you know? It could be. But if it only exists once or few times there might be the chance that it isn't.

[d1g]

@nebulon42, I see, but please don't overstate. At least 3 shop=fireworks were mine; they sell only fireworks IRL, they weren't typos. I don't mind to merge them with shop=pyrotechnics.

How do you know?

I would ask an individual mapper what he meant in each object.

Is shop=brweoirjf a shop?

Could you provide more realistic example from database that would break at least 10 threshold?

http://taginfo.openstreetmap.org/compare/shop=beds/shop=bed
http://taginfo.openstreetmap.org/compare/shop=clothes/shop=одежды/shop=одежда

[kocio-pl]

@kocio-pl, any shop=* value (except shop=no and shop=disused) is a shop (can be rendered using unspecific shop style). It was defined at wiki already. Custom and additional rendering are possible.

I agree with you, that's why I made all shops being at least marked as a shop dot.

What about typos? And about any shop value. Is shop=brweoirjf a shop? How do you know?

shop=brweoirjf is still a shop for sure and we don't claim we know what type is it, which is fair and accurate rendering of the data. No Oxford English Dictionary would be enough to validate - we need to know not only if it's a British English word, but rather what is valid inside the project. But that means it's better to have such dictionary closer to the data as a shared OSM resource (hence the question about Wiki status).

Apart from that I also like the idea of @Klaus-Tockloth.

Sounds acceptable for me in general.

Personally, and I said this before in other issue threads, I only see a real solution in a dynamic, Overpass based, rendering of shops.

Restaurants/fast foods are sometimes also crowded, so POIs in general. With vector tiles that would be great and I hope one day we will have it.

[SomeoneElseOSM]

"the most important annoyance for you personally"

1. The first thing is that there are a large number of different shop icons. Personally I'd find it easier to understand if related shops had the same or perhaps similar icons (maybe "sports" and "outdoor"? Or hairdressers and beauty salons?).
2. The second is that a lot of the shop icons make use of a lot of filled colour, so at z17 (se @math1985's Birmingham example) a significant amount of the map is purple.
3. Finally shops are currently overrepresented compared to some other features, such as offices, though obviously there's a separate tagging discussion around those, and once they appear on the map that problem will go away.

Here's a quick and dirty example of (2) and (3) above - z19, scaled down to fit side by side - don't worry about the legibility, just the proportions of colour.

The icon for "electronics" deliberately makes use of relatively little colour. Offices are shown, but with a minimal black dot. I haven't changed the "clothes" icon, and probably should, to an outline instead of filled colour (edit: now done, see note below). See https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT/tree/master/symbols for those symbols - most definitely aren't as nice looking as the standard osm-carto ones so I don't think they'll be replacing any of those any time soon, but some of the ideas (e.g. line drawn rather than filled colour) might work.

Finally it must be said that I don't really see any of these as "annoyances" with the standard style - it's just what it does. I definitely think @Klaus-Tockloth's idea is worth pursuing though.

Edit: I've now created a "line style" clothes icon - https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT/blob/master/symbols/shop_clothes.p.16.png . It's likely not transferable to this style, but may be useful as an example.

[d1g]

I'm not convinced rendering for a place like this (stripmall in the middle) really improved.

@math1985, I wasn't able to tell that "AVA" was a shop without purple icon. Only JBC with clothing icon gave me hint about possible group of shops, actually you can guess this too (based on parking)

... but "bétons feidt" is a much harder question for a non-local.

To me, better to have tiny styled dot ("a shop"), than unstyled text (no information about POI class).

[kocio-pl]

Thanks all for balanced and precise comments. I think we can start to take this issue bit further.

It seems that a common thread is to render icons later and start with just the dots. How should it be done in practice then? Which shops should stay as they are (supermarket? convenience?) and which level should we push the icons to (z18+?)?

[matthijsmelissen]

It seems that a common thread is to render icons later and start with just the dots. How should it be done in practice then? Which shops should stay as they are (supermarket? convenience?) and which level should we push the icons to (z18+?)?

I don't have clear answers to these questions either, perhaps somebody (maybe @kocio-pl) could make a start with an example rendering (which does not need to be perfect) and we could go from there?

[matthijsmelissen]

It seems that a common thread is to render icons later and start with just the dots. How should it be done in practice then? Which shops should stay as they are (supermarket? convenience?) and which level should we push the icons to (z18+?)?

I don't have clear answers to these questions either, perhaps somebody (maybe @kocio-pl) could make a start with an example rendering (which does not need to be perfect) and we could go from there?

I think at this stage, dropping the shops icons altogether (rendering them only by name or dot) should still be an option to consider too. Perhaps with some limited exceptions such as for supermarkets.

[kocio-pl]

Related to #2276, #2011 and #2417.

[EDIT:] Also related somehow to #1560.

[kocio-pl]

I guess at this point shops issue is resolved to some extent and there was no other proposition that was agreed by most of the people here, so I'm closing it now. If there are some other ideas that we could use, it can be reopen.