Skip to content
This repository has been archived by the owner on Apr 10, 2018. It is now read-only.

Remove support for SDF icons #444

Closed
jfirebaugh opened this issue Apr 21, 2016 · 12 comments
Closed

Remove support for SDF icons #444

jfirebaugh opened this issue Apr 21, 2016 · 12 comments

Comments

@jfirebaugh
Copy link
Contributor

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.

@ajashton
Copy link
Member

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)

@tmcw
Copy link
Contributor

tmcw commented Apr 22, 2016

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.

@samanpwbb
Copy link
Contributor

samanpwbb commented May 23, 2016

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.

@aidanlister
Copy link

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!

@wagerfield
Copy link

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!

@indus
Copy link
Contributor

indus commented Jun 15, 2016

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.

@derrickoswald
Copy link

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.

@1ec5
Copy link
Contributor

1ec5 commented Dec 6, 2016

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.

@1ec5
Copy link
Contributor

1ec5 commented Dec 21, 2016

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 lucaswoj changed the title remove support for SDF icons Remove support for SDF icons Dec 22, 2016
@KleggerKoder
Copy link

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!

@1ec5
Copy link
Contributor

1ec5 commented Dec 22, 2016

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

@lucaswoj
Copy link

lucaswoj commented Feb 1, 2017

This issue was moved to mapbox/mapbox-gl-js#4118

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests