Geometries and labels

[yohanboniface]

Hi again :)

This is more a reflection/remark than an issue.

When using vectortiles with Mapnik to create map, geometries and labels are paint with a subtle difference:

• geometries are paint using the "painter algorithm", which means that every layer is paint over the layer above, so in a way the last layer to be paint has more priority than the ones that came before
• on the other hand, labels are paint following the rule "first paint blocks following labels", i.e. the first label paint will prevent other labels to be paint on the same place (there is some configuration that can change this on the edge), so we can say that the first layer to be paint has more priority than the ones that came after

For this reason, when doing "old school" mapping with direct connection to the data (say a PostGIS database), for a given type (say the roads) we usually have one layer for the geometries and one for the labels; just to take an example, that could be "roads" and "roads_labels" layers.

When using vector tiles as sources, as it is now, we have only one layer for both geometries and layers, so this means, for example, that one can only put roads before or after places, while in reality we would like to put the places labels before the roads labels (so a place label has priority over a road label) but we want the place label to be after the roads geometries, so that roads are not paint over the places labels.

I understand this repository is meant for generic purpose only, and may not go in great details, but I feel like this one hurts even when doing very basic cartography.

So it may that the answer would be to have separate layers again for geometries and labels. Not sure how this would impact performance, though.

Now, I may just have missed something, or I may not be considering the issue from the right point of view.

Yohan

[bcamper]

@yohanboniface thanks for raising this. The way I've imagined handling this is to have the client do two different symbolization/render passes on the layer, once for the actual geometries, and once for the labels. It seems that the underlying data is only needed once, but that different rendering rules should be applied to them at different times. (Of course, I'm unsure how compatible that is with current renderers, but this repo is also mean to focus more on forward-looking use cases for vector tiles and is itself a bit experimental.) Does this make sense?

[yohanboniface]

Yep, it makes sense, sure. :)

But in practice this prevent from using this repo as source for mapnik based rendering. AFAIK, it's not possible, at this stage at least, to have twice a given layer in the mapnik stylesheet (I may be wrong). For sure it's not possible within a CartoCSS toolchain.

So clearly, for performance, both server side and bandwidth side, not duplicating info would be much better. But in the meantime, my opinion is that Mapnik is the minimum target for a vector source, so unless there is a smarter option, I would go on splitting geometries and labels layers when it makes sense.

cc-ing @springmeyer that may have good lights on this.

[bcamper]

I admit it's been years since I mucked with Mapnik XML files, I'm all WebGL these days :) We should look further into the options, perhaps it's possible to duplicate the data source in Mapnik and just point it to the same source twice (the datasource element is replicated for each layer if I recall). Not sure about Carto...

[springmeyer]

Separate layers for labeling are not a hard restriction in mapnik/cartocss/mapbox-studio, but rather a performance optimization common to a lot of sample projects and vtile sources.

For example, for fastest rendering and most reliable label placement it is ideal to use pre-calculated centroids for labeling polygons. Or for labeling lines you'll commonly want to filter out a reduced selection of lines that make sense to label in order to avoid clutter. Finally once you've decided that a custom layer for labels makes sense it then also makes sense to drop all attributes on the (non-label) layer containing all the geometries to save space. Doing all this at vtile production can produce better and faster rendering results with very little extra payload. Or in some cases your vtiles might even be smaller because attributes take up a lot of space. So, this is the reason you see a variety of custom label layers available in the vtile sources for Mapbox.

But again this is not a hard restriction at all. And generic vtile sources that try to be "one size fits all" are valid, quicker to produce, and can still be used with renderers like Mapnik. For example @yohanboniface if you want to use one linear layer to render both lines and labels you can simply render them in two passes using CartoCSS attachments (https://github.com/mapbox/mapbox-studio/blob/mb-pages/docs/0000-01-01-symbol-drawing-order.md#attachment-ordering). And if you want to render many different layers, many with labels, and maintain all the labels on top you can also do that. It's just more complicated that a single CartoCSS attachment. If using Studio you can use the {id}.{class} syntax to refer to the same layer twice in whatever order you need: https://github.com/mapbox/mapbox-studio/blob/mb-pages/docs/0000-01-01-advanced-features.md#custom-layer-order. If not using Studio then it may be even easier - you just need to form up a Mapnik XML that refers to the same vtile layer twice by name.

[bcamper]

Thanks @springmeyer! All makes sense, I imagine we might add label layers at some point for all the reasons you mention, but I had always been assuming they could be rendered from one generic source like this in the meantime.

[yohanboniface]

Thanks @springmeyer :)

About attachment, my experience was that they allow to draw twice a same geometry, but the order they are drawn is still the order of the data layers, not the order they are defined in the stylesheets. What I mean is that an attachment is still drawn with the layer it belongs to. Am I wrong?

I was not aware about the syntax trick to have a given layer listed more than once in the project.yml file, and that really nice! As you may guess, I'm using Kosmtik, which doesn't know about that trick, but I know the guy who maintains it, so I may convince him to support this nice feature :)

Thanks again!

[yohanboniface]

It works, thanks a lot, Dane :)

So you and @bcamper deserve a Thank You Map :)

[bcamper]

Amazing :)

Closing this and will open an issue to consider label layers in the future.