Change POIs displayed at z15 and z16

[matkoniecz]

Currently in cities parkings and hospitals are typical POI icons displayed at z15, supermarkets, pubs and biergatens join at z16. Multiple more important POIs appear on z17 (it includes embassies, museums, cinemas etc).

I propose to significantly change this.

push to higher zoom levels:

• parkings - icons start appearing at z16 instead of z15 (at z15 area markings should be enough, it would also solve Too much parking! #70)
• pubs and biergarten - move minimal zoom from z16 to z17 (like other icons from this class)
• tourism=information - move from z16 to z18 (most of it is information boards, and without information key in database it is impossible to provide special rendering for [tourism=information; information=office] - it would solve Information Boards (tourism=information) on levels <=18 #324, with new ticket to render information=office more prominently in 3.0)

show also on lower zoom levels - render from z16 (or maybe z15), instead from z17 (this POIs are currently treated as less important than pubs and parkings!)

• museum
• library
• embassy
• cinema
• courthouse
• theater
• police

I plan on making pull request - so comments whatever some proposed changes are really bad ideas are welcomed, suggestions for testing places are also a good idea (maybe in some places museums are common and unimportant and pubs are rather rare). Currently I am planning to generate examples for Cambridge, Moscow, Paris, Berlin and Kraków (in all cases - central parts of cities, zoom levels 15 and 16).

[matthijsmelissen]

Thanks, I think cleaning this up is really useful.

I think recycling and picnic_site can also go to z17.

I would leave embassies at z17, capitals have typically a lot of them, and many of them are not that large.

Without testing, the rest of your proposals sound fine.

Would you mind also generating an example for central Luxembourg-city? It's one of the most densely maps cities, I believe.

[matkoniecz]

picnic_site - I prefer to not touch this one as I never encountered it in my mapping. Also, it sound like POI appearing in more remote and less cluttered areas.

recycling, embassies - sounds like a good idea.

OK, I will generate also for central Luxembourg-city.

[Rovastar]

Sound good tweaks but I would compromise
"tourism=information - move from z16 to z18"
to z16 to z17 for now. As some are offices and some are information boards as you. For finding the offices it is useful to have them not just at z18 which is really zoomed. In 3.0 (that could be months/years away) as you say we could change this. So why not have them all z17 now and later we can have boards at z18 and offices at z16 or something.

[matkoniecz]

The main problem is that for 232k tourism=information there is only 8k tourism=office. Looking for office by checking everything marked by brown i is going to be one of the least effective ways.

http://taginfo.openstreetmap.org/keys/tourism#values
http://taginfo.openstreetmap.org/keys/information#values

[Rovastar]

recycling I would leave for now as we have large recycling centres (used to be massive landfill now recycling centres)
e.g.
http://www.openstreetmap.org/#map=17/52.90340/-1.42769&layers=N
That need should be displayed at the current zoom.
I know you can have bottle bank recycling too for the tiny ones.
What about node vs way? If it is a node goto z18 for ways leave as is.

[Rovastar]

Tourism

Yes I understand that but often tourism offices are just tagged as tourism without the offices. You could argue that it is tagged wrong but that is common practice. I would not take those taginfo values as accurate for that reason. Anyway like I say I think z16 to z17 is better and another pull request later when 3.00 is in full swing. Otherwise you will never find a toiurism office which is one of the most useful things for a tourist using a map of an area you do not know.

We also need to balance sparsely mapped areas as well as well mapped areas.
We need the map to be functional for both.

I know we try and reduce clutter and I am all for that. But consider the areas where there isn't so much we do not want nothing displaying in these areas (which is most of the world). Don't be too focused on really heavily mapped areas.

[matkoniecz]

Node vs way may also work for tourism=information.

But is it possible to make check like this? AKA - is it already done somewhere in this style? Or is there a CartoCSS documentation better than https://www.mapbox.com/carto/api/2.3.0/ ?

often tourism offices are just tagged as tourism without the offices

Just tourism=information? Checking for way vs node should catch cases like this (and encourage more detailed mapping), checking information key would also encourage better tagging.

[matkoniecz]

I know we try and reduce clutter and I am all for that.

In this case it is intended as exchanging one kind of clutter for another - because rendering parkings earlier than museums is absurd.

[Rovastar]

Ways and Nodes.
I must say I don't know. :) But thought it would be a good idea.
I think you can set this in the SQL "geometry_field": "way" and instead something like "geometry_field": "node" shrug
but it could be messy.
But it might be useful for many things if we do it like this.
Anyone any insight on this? Andy, Paul?

[Rovastar]

I know we try and reduce clutter and I am all for that.

In this case it is intended as exchanging one kind of clutter for another - because rendering parkings earlier than museums is absurd.

True but some things should be rendered like that I was referring to reducing stuff. just make it z17 for now. AFAIK editors just default tourism without the office hence how most people enter it.

[matthijsmelissen]

But is it possible to make check like this?

I think you should be able to use the selectors #amenity-points versus #amenity-points-poly for icons, and #text versus #text-poly for the label. In general, you can use .classname for classes defined in project.mml, and #idname for id's defined in project.mml.

[matthijsmelissen]

because rendering parkings earlier than museums is absurd.

Some countries have many tiny museums. For example, Amsterdam has nearly 90 museums: http://en.wikipedia.org/wiki/List_of_museums_in_Amsterdam I'm not sure if it makes sense to render all of them early.

[Rovastar]

Again the best solution for this (and many other things) is using the way_area. I am a great fan of this as I have said before as it makes the larger things render it at different levels to tiny things.
But that would take more radical changes to the carto design and with questionable computational times (I am still not sure how much slower it would be) but just doing zoom=* and trying have an 1 size fits all seems like something from the dark ages.

[matthijsmelissen]

Again the best solution for this (and many other things) is using the way_area.

+1.

I am still not sure how much slower it would be

I see no reason why it would be a heavy computation (way_area is precomputed afaik), but I didn't test it.

[Theodin]

+1 to have the ways come earlier. And +1 to having some POIs earlier.

[HolgerJeromin]

about way and node: There could be an tourism information inside the town hall. Therefor it is a node inside the building. Nevertheless it could be important.
But +1 for early rendering for huge museum areas.

[dieterdreist]

Il giorno 03/lug/2014, alle ore 09:28, Holger Jeromin [email protected] ha scritto:

about way and node: There could be an tourism information inside the town hall. Therefor it is a node inside the building.

You could still make it an area inside the townhall area, or even a multipolygon if there is already a building way and the building outline could be reused.

[matkoniecz]

For now I did changes that were not opposed, without using way_area, way vs node. I also applied change to fire_station, like to police. Now I will start testing whatever it improved things.

[matkoniecz]

I generated some examples how my proposed changes would influence rendering: https://github.com/mkoniecz/poi

Note that POIs like museums are displayed from z16, not z15 as I originally suggested. According to testing z15 is too early.

Diff: https://github.com/mkoniecz/openstreetmap-carto/compare/poi

I will not make pull request for now, to avoid duplication of discussion.

[matkoniecz]

Pull request was merged, further tweaking will take place in a new ticket.