Dynamic rendering of icons

[Que3216]

We’ve been using MapBox GL for a number of months now, and it’s been amazing!

We’ve now hit a problem we don’t know the solution to. We want to display various icons with a coloured circle background of an arbitrary colour. The user can change the colour for each point.

We’ve tried a couple of solutions:
1) Solution: Create two layers, one for the circle backgrounds, and one for the glyph icons on top. Problem: This doesn't work when the icons overlap. All the backgrounds are rendered behind all the icons, so they intersect in a funky way.
2) Solution: render PNGs on the fly, and update the sprite map whenever an icon changes colour. Problem: the only way to update the sprite map is by calling setStyle, which reloads all map tiles, and re-renders the whole map (we often have 10s of 1000s of features on the map, so this can be slow).
3) Solution: predict in advance all possible icon/colour combinations you’ll ever have to render, and create a massive sprite map. Problem: predicting in advance is hard, and often exponential. MGL currently has a 512x512 pixel limit on sprite-map sizes.

Currently we using solution #3, but it’s not ideal.

One solution could be to add a composite layer type, so that MapBox knows to render the background circles and icons together. A second solution could be to allow fast updating of sprites for individual layers (but without requiring a re-render of all layers). A third solution could be some sort of plugin system for custom renderers, or custom layer types -- maybe giving direct access to WebGL. There are probably plenty of other solutions too.

[Que3216]

There's overlap here with #358 (multiple sprites and individual images in style)

[emakarov]

for dynamic color you may use this - https://www.mapbox.com/blog/data-driven-styling/
overlapping is better to solve with clustering

[lucaswoj]

Thank you for the thoughtful post @Que3216. You are correct that there are a number of potential solutions to this problem, many of which already have tickets (#656 #358).

There's going to be some movement on #656 in the near future that I hope will hit your use case.

I am going to close this issue because it is a broad set of requirements for which many potential solutions are already ticketed out.

[lucaswoj]

Feel free to ticket out any specific proposals you have for a more concrete discussion.