Remove support for SDF icons

[lucaswoj]

From @jfirebaugh on April 21, 2016 18:34

We should remove support for SDF icons in the next style revision. None of the default styles use them, Mapbox Studio doesn't support them, and we haven't documented how to generate or use them.

Copied from original issue: mapbox/mapbox-gl-style-spec#444

[lucaswoj]

From @ajashton on April 21, 2016 20:30

The lack of documentation & support in Studio is the reason these aren't used anywhere. I think they'd be greatly useful if Studio gave us an uploader (eg automatic generation from SVG) & styling UI.

• would be great for shields where you need the same design in a variety of colors
• also good for tilted perspective maps where the icons scaled for depth
• color limitation is fine if we can have different-colored halo/stroke and maybe even some basic colored backdrops (circles, rectangles)

[lucaswoj]

From @tmcw on April 22, 2016 3:1

My/our reasoning for not including SDFs in studio was that we were optimistic about multi-color SDF. Studio already limits icons to SVG files and SVGs without a lot of common syntax - limiting the icons to black-and-white only was (imho) a step too far that would make it seem like almost nothing was supported as an icon.

I understand the cartographic advantages of SDFs, but from a UX level, adding another restriction to an already-restrictive icon system or alternatively adding "two kinds" of icons both would make it a more complex or more difficult tool. Multi-color SDFs would fix that.

[lucaswoj]

From @samanpwbb on May 23, 2016 19:9

I share Tom's UX concerns here. It would be difficult to add SDF support to Mapbox products in a way that made sense to users, even if we generated SDFs automatically server side.

Two more points:

• Single color SDFs have limited utility. Even if a map only needs single-color icons, often designers expect to be able to place icons on a circular, rectangular, or some other more complex background shape.
• If a user really wants scalable icons, it's easier to create and use icon fonts than it is to create and use SDFs, and icon fonts are well supported by Mapbox products. Icon fonts lead to tricky collision detection problems when used in combination with text, but that problem would be easier to fix than proper SDF support.

[lucaswoj]

From @aidanlister on May 24, 2016 1:17

As a user, I am finding the SDF thing really confusing. maki-chef doesn't seem to do anything useful, it won't let me upload an SVG that I have downloaded from maki-icons ... all I want is a circle in 21 different colors with a white stroke.

Mapbox GL is literally the best thing since google maps came out, we have been searching for a way to deal with large data sets for ever ... tried all sorts of workarounds like google fusion tables ... mapbox gl handles our dataset without breaking a sweat. That's amazing... I just need colored icons!

[lucaswoj]

From @wagerfield on May 24, 2016 19:21

I have been using Mapbox extensively for my projects and I would be very sad to see SDF support dropped.

The single colour limitations of SDFs can surely be circumvented with layering by compositing SDF symbols upon other SDF symbols or shapes like your circles? Layering a single coloured SDF graphic (like a shopping cart or a taxi) on top of another single coloured SDF graphic (like a circle, square, shield etc.) would be so awesome. I currently have this implemented with 2 layers referencing the same data source, where the 'base' layer is of type circle and the 'top' layer is of type symbol. I have worked around the default behaviour of the symbols disappearing when they collide by setting allow-overlap to true on the top-most symbols layer. However I think this could be improved by providing an API property on the layer's layout object (something like 'composite') that would allow you to specify a string ID that layers could share. This would allow you to effectively group layers and apply your layer collision logic factoring in all the bounds of each layer in that group referencing a particular data node... Hopefully that makes sense?

Being able to dynamically color these layers, add halos etc would add so much power to symbols that I've been yearning for.

Given your type faces are still using SDFs (I think) I would love to be able to use the same technology for custom symbols too. If possible, it would be great if spritezero exposed functionality for generating SDF images from SVG icons. I have written a gulp plugin that wraps spritezero (gulp-spritezero) and would love to be able to generate SDF sprites using it.

Right now I'm having to generate loads of repeated icons in different colours for my use cases and it seems suboptimal and clunky.

Regarding documentation, I think a clear section in the GL Style Reference docs explaining what SDFs are, what their limitations are and how you can go about generating them with an updated version of spritezero, gulp-spritezero and I imagine some future utility built into Mapbox Studio would be amazing in my opinion and is something I really, really want!

PS. I love Mapbox, absolutely incredible work everyone!

[lucaswoj]

From @indus on June 15, 2016 7:9

I really look forward to use SDF icons together with data-driven coloring (#2730). There are some impressiv examples using the property functions of circle layers already. But it would be nice to have the ability to be more expressiv with an icon, or to seperate classes in a dataset with different basic shapes. Please keep it in.

[lucaswoj]

From @derrickoswald on July 13, 2016 18:32

Just to add another use-case... highlight traced features.
We have an electric network on the map, single color: black. The user would like to see what is connected to what. A trace yields features which are connected. We highlight features by using an "in" filter on an id attribute and a long list. It works for lines. However setting icon-color doesn't work for icon-image features... because they aren't SDF icons.
It's not multi-color in an icon, it's just changing the color to identify them.
If I knew the format for SDF icons I would write the program to generate them from B&W SVG or PNG.

[lucaswoj]

From @1ec5 on December 6, 2016 7:27

Single color SDFs have limited utility. Even if a map only needs single-color icons, often designers expect to be able to place icons on a circular, rectangular, or some other more complex background shape.

By itself, this limitation doesn’t sound like a dealbreaker to me. Without commenting on the merits of this particular format, I just want to point out that Apple platforms make heavy use of template images (also known as “stencil images”) that, apparently like SDF, are rasterized, single-color, resizable icons. You can see these images in almost any native iOS or Mac application’s toolbar, for example. Granted, UI design isn’t equivalent to cartography. But if the iOS SDK’s runtime styling API is to be a serious solution for putting markers on a map (a form of UI, not so much cartography), it should have support for recolorable icons.

I’ve filed mapbox/mapbox-gl-native#7291 to track converting between template images and SDF icons in the iOS and macOS SDKs’ runtime styling API. Again, the particular format isn’t so important to me, but keeping a one-to-one correspondence between style image names and recolorable images would be desirable on those platforms.

[lucaswoj]

From @1ec5 on December 21, 2016 23:1

The iOS and macOS SDKs now support template images in style layers via SDF icons: mapbox/mapbox-gl-native#7300. Going forward, dropping support for them will be a backwards-incompatible change contrary to developer expectations.

[lucaswoj]

From @KleggerKoder on December 22, 2016 14:52

Just curious if mapbox is really in the process of discontinuing support for SDF icons or if there is still the possibility the support will be retained? My team is currently working with them right now and if support is being dropped for them it would be critical to know that now.

Thanks!

[lucaswoj]

From @1ec5 on December 22, 2016 19:13

Given mapbox/mapbox-gl-style-spec#444 (comment), I don’t think dropping SDF without a replacement would be feasible in the near-term.

[nextstopsun]

Please, please don't drop SDF support! Actively using it here. Single-color limitation isn't critical really, because multicolor icons/patterns are very rarely used these days. Also would very much like to see fill-patterns support SDF.

[ajmcmiddlin]

Another active user of SDF icons here. Colouring of icons based on data is critical to our application and single colour is not a limitation for us.

[jvanderberg]

There seems to be a mixed message here. The title is 'Remove support for SDF icons', but there seems to be no clear push to actually remove them (I think this case an it's progenitor have been around for over a year), and there appears to be a good base of user of this feature. The last comment from Lucas is that they should not be removed without a replacement.

I have a problem that I believe SDF icons will fix, but don't want to use it if SDF icons are eventually going to be removed without a replacement. Would it be possible to get a clearer message on the planned life cycle of this feature?

[lbud]

I'd like to maintain SDF icon support and close this ticket. They're clearly useful/widely used, they're already supported, and we don't have a replacement plan in the works in the near term. (Either way we should come to a decision and wrap up this ticket to be fair to users.)

We do need to do a better job of documentation and tooling for SDF icons, but that's a separate issue.

[jfirebaugh]

@lbud Agreed -- closing.

[mryellow]

It's very confusing that the default icons in MapBox Studio do not support icon-color. Documentation should make it clear that none of the expression examples will work with anything other than an SDF uploaded via loadImage.