Possible Mapnik enhancements

[kocio-pl]

I've learned about Mapnik fork by @talaj, which is used for mapy.cz and has some additional features:

https://github.com/talaj/mapnik#mapycz-mapnik

Is there anything you think might be useful in our style?

I would like to have placement type grid merged into the Mapnik (useful for country/states labels). This may take some time, because Mapnik release cycle is long and we need any new features to be covered also by Carto CSS (see the list placement for example). There's also additional complication related to the fact that OSMF needs Mapnik packages for Ubuntu. However that gives us some perspective for future development.

[SomeoneElseOSM]

There's also additional complication related to the fact that OSMF needs Mapnik packages for Ubuntu.

Not just OSMF - I've struggled to get Mapnik to build reliably even in "off the shelf" distributions. Trying to keep up with OSM Carto's "node" requirements was something of a pain for e.g. https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ ; now that the dust has settled there it'd be a shame to see something else crop up that caused similar issues :)

[kocio-pl]

Unfortunately there will always be some problems, because OSM (beside the main database) is highly distributed, so for example:

• Mapnik CZ feature -> port to Mapnik -> Mapnik release (!) -> Debian package -> Ubuntu package -> OSMF servers

but there are also other important branches of this inter-dependency chain:

• Mapnik release -> CartoCSS update -> CartoCSS release -> CartoCSS npm package -> servers (with proper npm/nodejs packages)
• Mapnik release -> Mapnik mason package -> Mapnik npm package -> Kosmtik update -> Kosmtik release -> Kosmtik npm package -> osm-carto Docker container

With Mapnik 3.0.16 released we have experimental Debian package, so I was able to take the shortcuts and compile Mapnik nodejs (but I also had a problem with too fresh nodejs package!), then test it in Kosmtik using hacked symlink. That was not too hard, because there were just bugfixes and it has no implication for our code, but still it took me some time and required asking Kosmtik and Mapnik developers. Moreover I was able to build from Debian package code on Ubuntu with no changes.

However new features in 3.1 will require more planning and effective communication between projects if we stick to the idea of using released and packaged code and care for updating standard layer on OSM.org.

[kocio-pl]

BTW: where can I propose and discuss some improvements in the switch2osm.org documentation? Once I have tried IRC channel, but had no luck to catch someone related to this project.

[SomeoneElseOSM]

BTW: where can I propose and discuss some improvements in the switch2osm.org documentation? Once I have tried IRC channel, but had no luck to catch someone related to this project.

If you mentioned it on IRC I probably wrote it down and might incorporate it at some stage, but it'd be in a list with quite a lot of other potential changes.

If it's a new page you're looking for then mention it to @systemed ; if it's sensible I suspect he'd just add it.

[kocio-pl]

I was afraid that it will get lost in the chat, some ticket system or even simple list on Wiki would be nice...

[SomeoneElseOSM]

There's a github site that @pnorman created, but that seems to be half-way between the switch2osm site as it stands now and something else (and relatively few "current" pages are there). Actually, seems like you found it already: https://github.com/switch2osm/switch2osm.github.io/issues .

[nebulon42]

Mapnik release -> CartoCSS update -> CartoCSS release -> CartoCSS npm package -> servers (with proper npm/nodejs packages)

On the CartoCSS side the only bottleneck are developer resources for CartoCSS and therefore the CartoCSS update part.

[kocio-pl]

Thanks, it's good to know what's the state of our important upstream project! I believe list placement is kind of special (it requires new syntax), but what about adding grid or polylabel placement types, how hard do you feel it would be to implement support for them?

[nebulon42]

what about adding grid or polylabel placement types, how hard do you feel it would be to implement support for them?

I just had a quick look, but would say that nothing would have to be implemented. With current master or with 1.0 you could just plug in that custom reference from @talaj and you would be done (if I'm not missing something). Of course your version of Mapnik would have to support that too and you would not being able to test that with Kosmtik unless the custom Mapnik would be available as npm package and it would be possible to wire that alternate version to Kosmtik.

@kocio-pl I have not found polylabel, where is it in the reference?

[kocio-pl]

Polylabel is a drop-in alternative algorithm for interior and is currently developed as part of the upstream Mapnik:

mapnik/mapnik#3550 (comment)
mapnik/mapnik#3780 (comment)

However grid can have some options we would surely need ("if you set repeat-distance to a large value, the grid placement will put single label on closest place near interior" - mapnik/mapnik#3780 (comment)) and some other too ("Grid density can be controlled by grid-cell-width and grid-cell-height properties of the symbolizer" - https://github.com/talaj/mapnik/blob/master/docs/features/placement-grid.md). Wouldn't it need some coding on the part of CartoCSS?

I don't think Carto is the problem now (especially with 1.0 expected in the coming months!), but long time between Mapnik releases can be: v3.0.0 is from 7.07.2015 and 3.1.0 is just 40% complete... It is not fully semver compatible (mapnik/mapnik#3372 (comment)), so maybe new placement types can be added as "minor new features" within v3.0.x line, but we can't be sure. That's why I ask if there are some other Mapnik CZ features we would like to use, so we could monitor their availability and help to resolve the problems along the way.

[kocio-pl]

There was a discussion about tying labels with icons (I just can't find this ticket now), and I guess this is the feature that would be needed for this: https://github.com/talaj/mapnik/blob/master/docs/features/anchors.md

[nebulon42]

However grid can have some options we would surely need [...] and some other too [...]. Wouldn't it need some coding on the part of CartoCSS?

No, I don't think it would.

[pnorman]

Requiring a fork would significantly make it harder for new contributors, particularly those relying on node-mapnik. I'd love to have more features and different release management, but I don't see it's worth the current costs. This could change if it became easier to use the fork, or the gains from it increased.

[kocio-pl]

That was not my intention to switch to the fork and I haven't even thought about that option.

I'm asking if we would like to have some particularly interesting features, so we could ask to port them upstream. The grid is already promised to be ported upstream, for example. The author of this fork is an active developer of the upstream Mapnik, which makes it much more probable.

[matthijsmelissen]

I would like to have placement type grid merged into the Mapnik (useful for country/states labels).

I don't understand this, how would country/state labels be rendered in a grid?

[kocio-pl]

It was also not clear for me until I read the actual documentation... 😄

This is a general method for n labels, but due to the underlying algorithm (going spirally from the centre) it's useful also for n=1 case:

Yes, if you set repeat-distance to a large value, the grid placement will put single label on closest place near interior. It also nicely cooperates with offset parameter of text symbolizer: you can shrink a space of possible placements (a polygon) by negative offset value.

(see mapnik/mapnik#3780 (comment) )

[kocio-pl]

I guess nobody found anything else which would be interesting for us, so I close this issue now.

[matthijsmelissen]

Would the ability to specify font-wrap in em something that fits this topic? That would save us a lot of code.

[kocio-pl]

Sure, everything that we'd like to have in the rendering engine. I wanted to make osm-carto team aware that it's sometimes better to cooperate with Mapnik directly and find general solutions instead of trying local workarounds. So far it was a nice surprise for me that Mapnik developers are responsive.

Did you found this feature in @talaj fork (I can't recognize it in https://github.com/talaj/mapnik#mapycz-mapnik), or it's just something that would be nice to have?

[matthijsmelissen]

Just something nice to have.

[matthijsmelissen]

Just something nice to have.

And I think it makes sense for many maps: many maps have increasing label size when zooming in. In that case, it makes sense to keep the word wrap at the same place in the word, and the way to accomplish that is to specify wrap-width in em (or, as we do, specify a different wrap-width for every label size calculated in such a way to keep the em constant).

[kocio-pl]

...speaking of which: mapnik/mapnik#3847 😄

[kocio-pl]

And a link to your ticket about em: mapnik/mapnik#3763

[matthijsmelissen]

Totally forgot I had already reported it :)

[StyXman]

line-dash-capping? so we can implement intermitent thick casings like the ones I tried to implement for unpaved roads.

[kocio-pl]

I guess this is another feature that is not available yet even in the Czech fork. Did you open the ticket in Mapnik? If you do, please drop a link here, so we could follow the progress and react if needed.

[StyXman]

mapnik/mapnik#3849

[kocio-pl]

Mapnik 3.0.19 has been released and Debian packages are available, so soon the Ubuntu package will be released too and OSMF sysadmins can deploy it (finally!...).

This version contains new area label placement implementation (fixing external bugs like #1465) and contains grid algorithm implementation, so we could start testing it - see #1391 (comment). If I remember correctly, no CartoCSS update will be needed for that, but since new code will depend on newer Mapnik version, it should be tested in v5.0.0 branch.

[talaj]

If I remember correctly, no CartoCSS update will be needed for that

There are new options of text and shield symbolizer grid-cell-width and grid-cell-height.

I now realized that there is no default value for these two options.

[SomeoneElseOSM]

Ubuntu 18.04 currently contains Mapnik 3.0.18 (not 3.0.19 - ot sure if that makes a difference to anyone). The current style seems to "just work" on a system installed on that. I haven't checked any new options.

[kocio-pl]

3.0.18 is affected with interior scaling bug - it's not severe, but it is easy to spot (I have discovered it after a short play with it) - read more about it here: #1465 (comment)

Since the Debian package is available, I hope the version will be updated in Ubuntu soon.

[kocio-pl]

The good news is that using Kosmtik from git grid is available. I started playing with this code:

openstreetmap-carto/placenames.mss

Lines 45 to 64 in cadf491

	.state {
	[zoom >= 5][way_pixels > 3000][way_pixels < 196000] {
	text-name: "[name]";
	text-size: 10;
	text-wrap-width: 30; // 3.0 em
	text-line-spacing: -1.5; // -0.15 em
	text-margin: 7.0; // 0.7 em
	text-fill: @state-labels;
	text-face-name: @oblique-fonts;
	text-halo-fill: @standard-halo-fill;
	text-halo-radius: @standard-halo-radius * 1.5;
	text-placement: interior;
	[zoom >= 7] {
	text-size: 11;
	text-wrap-width: 50; // 4.5 em
	text-line-spacing: -0.6; // -0.05 em
	text-margin: 7.7; // 0.7 em
	}
	}
	}

I have changed the line text-placement: interior; with this code:

    text-placement: grid;
    text-grid-cell-width: 10;
    text-grid-cell-height: 10;

and this is the result (Poland, z6):

Now I try to learn how to control repeat distance, so there's only one occurrence of each label.

[kocio-pl]

Using this code:

    text-placement: grid;
    text-grid-cell-width: 1;
    text-grid-cell-height: 1;
    text-repeat-distance: 100000;

z6

Before

After

[kocio-pl]

Another application for grid (apart from #1391) might be dynamic pattern generation, see some examples here: mapnik/mapnik#3847.

This would be helpful to remove SVG pattern files and avoid generation chain problems like #3051 (comment). It should be tested however.