-
Notifications
You must be signed in to change notification settings - Fork 38
Remove support for SDF icons #444
Comments
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.
|
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. |
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:
|
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! |
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! |
I really look forward to use SDF icons together with data-driven coloring (mapbox/mapbox-gl-js#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. |
Just to add another use-case... highlight traced features. |
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. |
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. |
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! |
Given #444 (comment), I don’t think dropping SDF without a replacement would be feasible in the near-term. |
This issue was moved to mapbox/mapbox-gl-js#4118 |
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.
The text was updated successfully, but these errors were encountered: