Improve low zoom levels

[matthijsmelissen]

The low zoom levels are currently not very pretty, and hard to read.

See also http://www.reddit.com/r/openstreetmap/comments/2e2ohr/openstreetmapcarto_default_openstreetmaporg_style/ for detailed comments.

We should probably first think which features we find important on low zoomlevels.
#1107 will probably improve this.

[matkoniecz]

Too many unimportant borders of lower administrative entities and absurdly early displaying labels for them are main problems (at least in Europe).

http://www.openstreetmap.org/#map=5/48.195/11.733

[matkoniecz]

Superset of #315

[imagico]

This is a complex issue based on a number of different problems. The most significant one is that for low zooms nearly none of the OSM data is suited for direct use in rendering, using the OSM data here requires significant processing which is why at some places external data is still used. If you understand German you can find some details in my FossGIS talk on this.

There are however also a number of things that could be done to improve appearance without requiring extensive processing ressources:

• decrease the number of boundaries and corresponding labels displayed as @mkoniecz suggested, i.e. no subnational entities at z=4/5.
• not/less prominently show maritime boundaries (Maritime borders too prominent #621)
• only display independent national entities at z=2/3 (i.e. no US/British oversea territories)
• prioritize labels of those by size/population
• scrap the arbitrary and outdated natural earth city labels (Replace Natural Earth labels with OSM-derived version #255)
• show island labels at zoom levels z<7
• don't show boundaries and show continent labels at z=1
• show ice sheets at z<6 (Making the Antarctic ice sheet show up in the map #960, Reenable basic glacier rendering in Antarctica #646)

[Circeus]

For what it's worth, it should be noted that a lot of issues can be attributed to the difficulty of the main rendering to treat countries differently. The US doesn't look THAT bad at z6, but the UK, where there is a LOT more roads tagged trunk and railways, looks messy. Google Maps displays the UK A-road a lot less prominently than US roads, which we both treat at trunk level.

A similar problem happens with subnational division. it's harder for OSM to display them only for some countries. Using pixel areas (assuming that's an option here...), as has been done for various other things recently, may help solve these problems, both by allowing US state names to be shown bigger and by removing, for example, the names of swiss cantons that really cannot be made to fit legibly before at least z8-9

[sommerluk]

Maybe also landforms like mountain chains chould be interesting. See http://geo.dianacht.de/topo/ for an example. (But maybe tagging is not that much discussed.)

[matthijsmelissen]

An idea would be to use the (multipolygon) areas instead of labels to render admin labels. We could then look at the size of the admin areas, and only render names for areas of a certain size (such as US states), while leaving out smaller ones (such as as Swiss cantons) on z5.

A disadvantage is that this is a fragile method, as broken admin multipolygons would lead to the label disappearing.

[HolgerJeromin]

Showing broken data seems a good thing for this style. many people are able to fix a mp but only if they are able to find them.

[matthijsmelissen]

Admin borders look a tiny bit better now the new admin borders have been rolled out, but are still far from perfect.

I think one reason of the weak rendering of sub-national borders is the Coastline paradox: the dashes are computed on the length of the border on high zoom, not on the length of the border as you could measure in pixels on low zoom. That means that dashes become invisible on curly borders. Compare the England-Wales border, which nearly looks undashed, with the straight Sahara borders, which look fine.

[dieterdreist]

2014-11-20 1:44 GMT+01:00 math1985 [email protected]:

I think one reason of the weak rendering of sub-national borders is the Coastline
paradox http://en.wikipedia.org/wiki/Coastline_paradox: the dashes are
computed on the length of the border on high zoom, not on the length of the
border as you could measure in pixels on low zoom. That means that dashes
become invisible on curly borders.

+1, another good example is here (problematic in almost all zoom levels):
http://www.openstreetmap.org/#map=11/41.4329/16.0126

actually I am not sure if this is really mapping the legal situation (i.e.
that the border follows the coastline on every little curve and if you put
a big stone on the beach you'd have enlarged the area of the municipality),
I could imagine that a small stretch of water (e.g. depths below x meters,
where x might be 1 or 2 or sth like that adjacent to the beach might maybe
be considered part of the "administrative land"?).

[pnorman]

+1, another good example is here (problematic in almost all zoom levels):
http://www.openstreetmap.org/#map=11/41.4329/16.0126

Mapping the border like this is in practice unusable for many purposes, and silly for the reasons you mentioned. I don't mind if it renders badly.

In Vancouver we map the city boundary as being in the water as no one would hold that you've left Vancouver if you go swimming on the beach.

[dieterdreist]

2014-11-20 18:12 GMT+01:00 Paul Norman [email protected]:

Mapping the border like this is in practice unusable for many purposes,
and silly for the reasons you mentioned. I don't mind if it renders badly.

In Vancouver we map the city boundary as being in the water
http://www.openstreetmap.org/#map=14/49.2853/-123.1523 as no one would
hold that you've left Vancouver if you go swimming on the beach.

as I wrote, I guess it is like this, but I am not completely sure. For
stuff that is happening on and close to the water, there are also dedicated
(national) agencies which are responsible (similar to coast guard). I think
the borders have to be mapped the way they are legally defined, and while
for country borders we are sure how to do it (baseline -> sea border) we
are unsure how to do it on lower levels like e.g. the municipal level.

[daganzdaanda]

dashes are computed on the length of the border on high zoom, not on the length of the border as you could measure in pixels on low zoom

Does this mean a long border has different dashes than a shorter one on the same zoom and with the same admin_level? That does not seem right.

[matthijsmelissen]

Does this mean a long border has different dashes than a shorter one on the same zoom and with the same admin_level? That does not seem right.

No. What I mean is that a border that zigzags on an area less than 1 pixel wide it has different dashes than a straight border.

[daganzdaanda]

OK, thanks.
Is there anything that can be done against that problem?
All the dashes seem pretty short. Maybe if dashes were 2 or 3 times longer, the problem would not be so obvious?

Mapping the border like this is in practice unusable for many purposes, and silly for the reasons you mentioned. I don't mind if it renders badly.

I kind of agree...

[dieterdreist]

2014-11-30 18:34 GMT+01:00 daganzdaanda [email protected]:

Is there anything that can be done against that problem?

the solution would be to generalize the borders, i.e. remove details that
are so fine grained that you wouldn't see them in particular zoom levels.
Ideally you'd do this for every zoom level, but practially I guess it will
be too expensive to do it anywhere (on the fly).

All the dashes seem pretty short. Maybe if dashes were 2 or 3 times
longer, the problem would not be so obvious?

no, you can't deal with this on that level, it completely depends on the
size of the details (e.g. length of segments, frequency of zigzag, angles,
etc.) and on the zoom level you're looking at this. You'd only be moving
the problem from one zoom level to another...

[matkoniecz]

It improved quite significantly after recent changes. #1157 is related (city's labels blocking country's labels).

[matkoniecz]

dashes are computed on the length of the border on high zoom, not on the length of the border as you could measure in pixels on low zoom. That means that dashes become invisible on curly borders. Compare the England-Wales border, which nearly looks undashed, with the straight Sahara borders, which look fine.

@imagico Can you publish program used to generate data described in http://blog.imagico.de/rendering-boundaries/ ? It seems that it may fix this problem.

[imagico]

Well i guess i could but i don't think i'd really do anyone a favour by doing that. It is very non-robust and scales badly to the point that is is not really usable for more than admin_level 2.

Realizing that i started looking into a more elegant and universal solution more in the line of what i did with the coastlines. I did not yet have the time to finish that though.

The broader question here that would need to be addressed first anyway is if and how this style is going to include preprocessing of OSM data - there are other areas, most notably where NaturalEarth data is used right now, where this is an open question as well.

[kocio-pl]

I started to collect notes about improving low zoom level on my Wiki page. I guess this is so complex problem, that even meta-issue like this one would be too static, so we may make more readable version somewhere else on OSM Wiki.

I see 3 main areas here:

1. Showing names (continents, countries, states and country capitals)
2. Showing borders (countries and states)
3. Showing physical landcovers

I think French fork makes most of it better, so we may just copy that things, because it would be easiest and most effective. First easy question is if we would like to show the continents names at all.

The most important thing for me, yet quite simple to implement, would be to start using text-label-position-tolerance option, which allows areas labels to be placed so they stop eclipsing cities (especially capitals!) labels.

I like to test it, but I need to resolve a technical problem first: how to extract from planet.osm file only the features visible on 1-6 (or 1-7) levels. @matkoniecz has already tried to do something like this, but hit the wall at the moment. If anyone else can help us with it, we would appreciate it a lot.

[matkoniecz]

@kocio-pl

According to mapnik documentation text-label-position-tolerance only works with placement:line in Mapnik 2.3 - so it can not be used to solve placement problems for areas (I hoped that it can solve #1069). In addition it is missing/renamed in Mapnik 3.0

[kocio-pl]

The documentation is so dry that I find it hard to really understand it...

I also have checked it and came to the same conclusion as you. But when I started to analyze French placenames.mss file and looking at French tiles, it became clear to me that it probably works anyway. My working theory is the "line" could be also closed, exactly like borders, and I need to test it.

[matkoniecz]

I think that this issue is not really useful. low zoom levels are worse than others, but I think that it would be better to open individual issues for each idea of improvement or noticed problem.

[kocio-pl]

For me it's just another meta-issue, which sooner or later have to result in more specific issues/PRs. I already have my own special Wiki subpage dedicated for dealing with this quest, so the question of leaving it open or closing it is not crucial for me. I just think it's better if we have as much tools, documentation and discussions in one place as possible, so we can cooperate easier, especially on some complex issues like this one.

Real meta-issues with access granted for all GitHub users (not just issue author and repo owner/collaborators) or GitHub Wiki for this repo would be good, but in the absence of them I prefer to have this meta-issue open.

[matkoniecz]

Significant part of issues was fixed in great #1989 by @nebulon42 (and maybe also earlier changes) - especially #1125 (comment) (see http://www.openstreetmap.org/#map=5/43.485/20.270).

[matthijsmelissen]

#1107 has been merged (long time ago), and the rendering is now much better than in the included screen shot. There's still a lot that can be improved, but I'd suggest making separate issues for that when needed.

[matkoniecz]

From what I see everything is now either solved or has its own ticket (in case of something not covered by other issues - please, open a new one).