Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add map.setSprite(spriteUrl)method #2058

Open
scothis opened this issue Feb 4, 2016 · 8 comments
Open

Add map.setSprite(spriteUrl)method #2058

scothis opened this issue Feb 4, 2016 · 8 comments

Comments

@scothis
Copy link
Contributor

scothis commented Feb 4, 2016

The style diff utility defines an operation to change the sprite sheet for a style. Mapbox GL JS does not support this method currently causing a fall back to the more invasive setStyle when this operation is encountered.

When this method is invoked, the current sprite sheet should be removed and recreated.

Minimally setSprite(spriteUrl) should be added to the style batch, it would also be helpful to expose this method on the map instance.

@jfirebaugh
Copy link
Contributor

A bit tricky to implement, but this should be supported. (As should changing the glyphs URL.)

The implementation will need to assume that the new sprite could have added icons, removed icons, and changed the contents, sizes, and pixel ratios of existing icons. All tiles will need to be re-layouted, and in order to avoid flickering and misrendering, the existing sprite texture will need to be preserved until all tiles have completed relayout. Basically, multiple sprite atlases will need to exist in parallel, and a tile will need to indicate which atlas it was layouted against.

@yuvadm
Copy link

yuvadm commented Feb 6, 2016

This would also help #2081 since currently it seems the sprite attribute has no effect

@lucaswoj
Copy link
Contributor

Closing in favor of #2059 & mapbox/mapbox-gl-style-spec#220

@anandthakker
Copy link
Contributor

Reopening this as a shorter-term fix that is required before #3643 can merge.

@anandthakker anandthakker reopened this Nov 18, 2016
anandthakker pushed a commit that referenced this issue Nov 18, 2016
jfirebaugh pushed a commit that referenced this issue Nov 22, 2016
@anandthakker
Copy link
Contributor

Now that we've decided this doesn't block #3643, I'm going to re-close this issue in favor of #2059

@mourner
Copy link
Member

mourner commented May 14, 2019

Reopening because we're still interested in the original use case — speeding up setStyle in the case the spritesheet is changed.

@ggerber
Copy link

ggerber commented May 24, 2020

I have two custom geojson sources and layers that I add to my map.
I would like the user to change the 'baselayer' e.g from streets to satellite.
The first attempt was:

map.setStyle(`mapbox://styles/mapbox/${_id}`);

This changes the the 'baselayer' but does not render the custom layers. On the console I get this warning:

Unable to perform style diff: Unimplemented: setSprite..  Rebuilding the style from scratch.

The second attempt was to remove the custom layers and sources, then do map.setStyle, then add the custom layers back:

    map.removeLayer('customlayer');
    map.removeSource('customsource');
    map.setStyle(`mapbox://styles/mapbox/${_id}`);
    map.addSource(...);
    map.addLayer(....);

This gives the same result as the first attempt: changes the baselayer, but does not render the custom layers with the following console message:

Unable to perform style diff: Unimplemented: setSprite..  Rebuilding the style from scratch.

I am able to achieve my goal through the following brute force approach:

  1. Get and save the current camera parameters (map.getBearing(), etc)
  2. Calling map.remove()
  3. Rebuilding a brand new map instance with the save camera parameters
  4. Adding the custom sources and layers to the new map instance.

It appears to me to be quite drastic to tear down the whole map instance, simply to change the baselayer.

Are there better ways of achieving this goal or should we wait till setStyle()/setSprite() is improved in the future?

@andrewharvey
Copy link
Collaborator

@ggerber #4006 is probably closer to what you're after since you want to retain your application layers when changing the style. Those warnings you mentioned shouldn't affect functionality as far as I know, only how efficiently it can change the style and doing it with smooth transitions.

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

No branches or pull requests

8 participants