boundary=administrative, admin_level=4 labels obscures place=city labels

[kocio-pl]

(This is more general problem already described in #1386 ):

Sometimes admin_centre name is obscured by admin_level name, which I consider a serious bug for a general map. For example Warsaw is not visible up to z=7 (I think there are some other bugs at low zoom levels, but 6 and 7 seem like obvious cases of above).

IMO admin_level should always try hard to allow admin_centre name to appear where it really is, because the area is probably huge and we have more flexibility in choosing the place to render its name. I would use the rule of thumb that admin_level name should always stay entirely in its boundaries - and only obscure the admin_centre name if it's not really possible.

[pnorman]

What do you mean by admin_centre name? I do not find that text anywhere in the style.

[kocio-pl]

I may be wrong what really causes problem, because we have relations, places, labels - so here is the visible province relation:

http://www.openstreetmap.org/relation/130935

and here is the obscured city relation:

http://www.openstreetmap.org/relation/336074

[matthijsmelissen]

The problem is that boundary=administrative, admin_level=4 labels obscures place=city labels.

I'm not sure if it's always a bad thing. What is more important to label, Northern Ireland or Belfast? Baden-Wurtenberg or Stuttgart? Massachussets or Boston?

[kocio-pl]

1. We don't always have to decide what's more important - that's why I want moving state's name away from the city's name, not just getting rid of them.
2. See how it works in practice - for Poland it's much stranger than only Warsaw case:

z3 - blank area, not even country name (?)

z4 - only WP and MA voivodeships (quasi-states) are visible (clear USA-based influence, since nobody in Poland uses such abbreviations for voivodeships!), and no country name

z5 - only "województwo wielkopolskie" (that was WP at z4) and country name in the middle

z6 - now it's getting funny =} :

• we have all 16 voivodeships visible, but font style is weak
• no single (voivodeship's or country's) capital is visible at all
• country's name is visible on the Baltic Sea
• the most visible thing (solid black font) are the second-grade "in-between" cities

z7 - almost the same level of fun, now just the minority of capitals are visible, but country's capital is still not (!)

---

For now I want to focus on z6-7 (at least in this ticket probably), because it's clear space for improvement here and it's local. z4-5 would be interesting for sure too, because we have many countries to check:

• big countries like Canada and USA have states/provinces visible, but Canada have just dropped its name (only Vancouver and Toronto is visible at z4, but at z5 there's only Ottawa), and in USA we see Washington, NY, but also Miami, Houston, LA, all on the edge - and Atlanta and Denver in the mainland, as if they were more important or something. =}
• in Europe London is healthy as hell =} even from z3 (just because it's not in the center of UK or even England) - but the other capitals are only Stockholm, Amsterdam, Paris, Geneva, Rome, Vienna and Kiev, on the other hand we have "Deutschland" here (but no Berlin, which was visible at z3) or Romania (and no Bucharest)

And I haven't even look at the rest of the world! There are probably much more things to consider, but I think admin_level area names shifting away from cities could also help here to some extent.

[emmexx]

Probably it is an already known issue but it is weird to view mapnik without finding immediately some obvious info.
One case in northeastern USA:
http://www.openstreetmap.org/#map=8/39.988/-75.333

I expected to see New York City, Philadelphia and Washington DC. Instead I see Yonkers, Camden and Arlington. At zoom 8!
New York appears at zoom 7, Washington and Philadelphia at 12.

In Italy at zoom 5 there are the labels for many of the larger cities but not for Rome (almost 3 million inhabitants) and Turin. But there are Compobasso (50000) and Catanzaro (91000).
At zoom 6 Milan disappears substituted by many small cities around it. Rome is still missing. Campobasso is still there.
At zoom 7 Milan comes back, Rome is missing, Campobasso gone.
At zoom 8 Romes makes its debut, Campobasso is back. Bologna is hidden by the region name.

[dieterdreist]

Am 21.05.2015 um 15:15 schrieb emmexx [email protected]:

At zoom 7 Milan comes back, Rome is missing, Campobasso gone.
At zoom 8 Romes makes its debut, Campobasso is back. Bologna is hidden by the region name.

the Rome case is rather particular because there is a country label competing with it (vatican, not any more at the moment) as well as the region label (lazio, z6+7)
Rome's debut is in z3 btw (from natural earth), it's also there in z4 and then disappears for a long time until z8.

[daganzdaanda]

debut is in z3 btw (from natural earth)

I did not know that, how does it work? do those names come pre-selected in the dataset?

Also: Berlin is weird, too.
Most importantly it is a city, even a capital. But it is also a "state" of Germany, and in our style, that seems to win sometimes. But then, it's a tiny state, and an enclave of Brandenburg.
So in z3 it's "Berlin", the city (probably from natural earth).
z4: "BB" for Brandenburg renders first, so neither Berlin the state nor the city is seen (also, these abbreviations are rarely used in Germany, too).
z5: Brandenburg wins again, same at z6.
z7: Finally, "Berlin" the city (label could be larger or stronger imho, for capital and relative size).
z8: the label turns pink and italic, because it's Berlin the state this time... (same happens at Hamburg, but not with Bremen).
z9: Berlin still tiny and pink (same with Hamburg and Bremen this time)
z10: same as 9 (Bremen now gets a city label in addition to the state label)
z11: Berlin takes nearly the whole browser window, and now has a city label and a state label (Hamburg stil has only the state)
z12,13,14: all three city-states have doubled labels.
z15-19: no city label anymore, but the state label still remains.

What I take from this exercise:

• City labels for big cities and capitals should come before some minor admin labels. Maybe they should be priorized even before country labels: countries are bigger, so a country label could fit in another place, while a city label can't move much. In practice, I guess Mapnik's label placement is not very smart yet.
• City labels should come before road labels at z11. (I'm guessing that's what keeps Hamburg from showing up at z11)
• It may make sense to drop admin labels starting from z11 or 12.

[matkoniecz]

so a country label could fit in another place

see #1069

It may make sense to drop admin labels starting from z11 or 12.

Not all of them (lower divisions, but anyway currently such labels are displayed only for borders)

[pnorman]

as there is no thing such as an admin_center name and people are pointing out various separate issues, I'm looking closing this ticket. If people want to make more focused tickets about clearer issues, that's fine, but this ticket isn't clear.

[daganzdaanda]

but this ticket isn't clear.

I think @math1985 phrased it better:
The problem is that boundary=administrative, admin_level=4 labels obscures place=city labels.
(actually, I think it's also admin_level=2)
Should we open a new issue with that title, or can an admin rephrase this one?

[dieterdreist]

Am 22.05.2015 um 17:53 schrieb daganzdaanda [email protected]:

City labels for big cities and capitals should come before some minor admin labels. Maybe they should be priorized even before country labels: countries are bigger, so a country label could fit in another place, while a city label can't move much. In practice, I guess Mapnik's label placement is not very smart yet.

Berlin is admin level 4, this is not "minor", it has the same significance as Bavaria or a state of the US, to make these new rules work we'd have to render (some?) cities before all admin names below the country level. Not bad IMHO, but will likely have quite some impact on certain levels, so this is a decision we should be well aware of and take it consciously.

[matkoniecz]

The ideal solution would be to let label for country/region move a bit to allow displaying of city icon but I see no example of anybody doing this in CartoCSS.

I also have no obvious idea (beyond something inefficient and complicated like playing with ST_Buffer to find area close to country center but not next to cities..,)

[kocio-pl]

but I see no example of anybody doing this in CartoCSS.

Isn't French style a fork of osm-carto? IIRC @cquest managed to do it somehow.

[matkoniecz]

They use text-label-position-tolerance: for placenames but as documented in https://github.com/mapbox/carto/blob/master/docs/latest.md it works only for lines. I also tested it and it gives no difference in rendering.

[kocio-pl]

I did the testing too with the same results. Yet it looks something works in FR, so I will try to look at it closer.

[kocio-pl]

Please reopen this issue, it was incidentally closed by #2314 ("Tries to partly fix" contains "fix" keyword).

[cquest]

My last work on this uses text-placement to allow the state labels to move around if needed.

Current dev style is visible on: http://u.osmfr.org/m/99740/

[kocio-pl]

I've been already trying to debug your fork, because it works better than this style for many months, but it has diverged too much and I was not focused enough. I still plan to test it and find out the difference - thanks for the hint!

[cquest]

I forked the style at its early days... and learned carto-css at the same time.
I know that it is not clean at all but some pieces may be interesting ;)

I've also use some ugly tricks using the _rels / _ways tables to get some details not available in the geometry tables produces by osm2pgsql (for example to get the operator on bus stops when this tag in only available in the relation).
I did something a bit similar for the boundaries...

[kocio-pl]

This should be probably resolved by using grid placement once it's available in the Mapnik - see mapnik/mapnik#3780 (comment) and #2962.

[kocio-pl]

The code is in the Mapnik repo, now I wait for v3.0.19 release to test it.

[kocio-pl]

Mapnik 3.0.19 has been released and is even available as a Debian package, so I was able to not wait for official Ubuntu package, npm Mapnik bindings and Kosmtik update, and forged it myself:

• rebuild it for Ubuntu:

git clone https://anonscm.debian.org/git/pkg-grass/mapnik.git && \
cd mapnik && \
git co experimental && \
dpkg-buildpackage -B

• install the resulting packages:
  sudo dpkg -i *.deb
• build a node-mapnik bindings for it:

git clone https://github.com/mapnik/node-mapnik.git && \
cd node-mapnik && \
git checkout v3.0.x && \
export CXX="clang++" && \
export CC="clang" && \ 
make release_base

• make a hack to run it in a testing instance of Kosmtik (I want to be still able to have stable Kosmtik version with proper npm installed node-mapnik, which still uses old Mapnik like v3.0.15) - it means linking this node-mapnik directory into kosmtik-devel/node_modules:

rm -r mapnik && \
ln -s /path/to/node-mapnik mapnik`

Mapnik 3.0.19 has new interior algorithm, so you could see some changes in all area label placements, including admin areas, but it is just different, not better in general (some labels start being visible, some are hidden now):

Poland, z6
Mapnik 3.0.15

Mapnik 3.0.19

Poland, z7 (click to see the full size images)
Mapnik 3.0.15

Mapnik 3.0.19

The real change will be when we make a v5.0.0 code branch (since it means "upgrading software dependecies") and test the grid algorithm, which is finally also available in Mapnik 3.0.19.

[kocio-pl]

Looks like 3.0.20 (for Ubuntu Bionic 18.04 LTS) is finally deployed on OSMF servers, since Lake Victoria has label in the center now:

also all the other label placing problems I was aware of are gone.

Now that we have proper Mapnik version on OSMF servers, we can try using grid algorithm for some area labels, especially admin level 4, and fix this issue.

[emmexx]

In Italy I see still problems in admin level priority labels.
z=5 is ok, I see the main cities (by population o some other criteria, I don't know).
z=6 is not ok, some of the bigger cities disappear behind minor cities or region labels (Milan, Torino, Naples). Similar problem in Spain, Madrid is hidden by the España Label.
z=7 is not ok, Milan and Naples are ok but Torino and Bologna are still missing.
z=8 Bologna still missing

[kocio-pl]

Change of internal algorithm does not solve such problems, but it may accidentally (just like any change, at the same time it can make some other things worse). It was introduced only to fix the problems like #1465.

New algorithm is now ready to be tested instead and this should really help by moving labels to a free space.

[kocio-pl]

@nebulon42 said that grid does not need changes in CartoCSS - #2962 (comment) - but it looks like CartoCSS 0.18.2 (and 1.0.1 too) does not like it and produces 0-length project.xml:

Error: placenames.mss:56:4 Invalid value for text-placement, the type keyword (options: point, line, vertex, interior) is expected. grid (of type keyword) was given.
    at Object.env.error (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/parser.js:249:55)
    at Rule.tree.Rule.toXML (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/tree/rule.js:86:28)
    at Definition.tree.Definition.symbolizersToXML (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/tree/definition.js:145:39)
    at Definition.tree.Definition.toXML (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/tree/definition.js:218:33)
    at /media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/tree/style.js:40:27
    at Array.map (<anonymous>)
    at Object.tree.StyleXML (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/tree/style.js:39:29)
    at Renderer.render (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/renderer.js:180:43)
    at compile (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/bin/carto:100:31)
    at MML.load (/media/hdd/home/kocio/devel/kosmtik/node_modules/carto/lib/carto/mml.js:68:20)

[kocio-pl]

OK, it works now, an early test of this concept and new toolchain is here: #2962 (comment).

[jeisenbe]

So this currently needs wait for v5.0 since it requires Mapnik/CartoCSS update, right?

[imagico]

Closing in favor of #3034.