The mapbox-streets-v7 source has just gone live in all Mapbox machine styles and now all styles have complete sprite sets.
These sprite changes have exposed a bug: after loading a new sprite sheet, we don't seem to update the coordinates of the individual icons correctly. Reloading the style fixes the misdrawn icons.
/cc @ansis @kkaefer
This still happens and can be amusing:

Speculation is this happens if you get a stale sprite.png and fresh sprite.json, or vice versa. https://github.com/mapbox/mapbox-gl-style-spec/issues/220 is the solution.
We're seeing the sprite.png getting out of sync against the sprite.json as well. We've only noticed this in our iOS app which is using mapbox sdk version 3.7.3.
We expected to see this border around the 5:

But we instead saw this border around the 1 (ignore the numerical & bike-pin-image differences):

Compare the following two sprites (before on top, after on bottom), you'll see that where the
was, now there's
. So that tells me that the image was updated but the SDK was still using the old sprite mapping json.
Before change:

After change:

You can see that the sprite slice is being loaded at the same x,y coordinates, but the sprite.png was changed. This means the sprite.json is stale while the sprite.png is fresh.
This happens after adding a SVG to the sprite via mapbox studio and publishing the style. The only fix we've found is to uninstall and reinstall the app. This bug has earned us at least one 1-star review, so its one we'd like to address immediately.
@ryanbaumann Thank you for taking my email after chatting at the Bikeshare hack night in DC.
https://github.com/mapbox/mapbox-gl-js/issues/4086 is a long term solution that'll make it less likely for bugs like this in the future but it isn't necessary or sufficient to fix this particular bug. Given that this is affecting customers, should we look into a short term fix?
Clarification by @jfirebaugh via Slack:
My thinking was more that our caching strategy inherently permits this to happen without any intermediate caches necessarily being "stale" as defined by the headers we use. But a bug that produces incorrectly stale results out of the cache is also a possibility.
As an example of the latter possibility: https://github.com/mapbox/mapbox-gl-native/issues/10015
Maybe it's even possible that this is another manifestation of the same issue.
Ah, probably not, that was fixed and backported to Android SDK v4.2.0 and iOS SDK v3.7.0.
One potential workaround is to use the fresh=true parameter on the style URL. I'm not exactly sure how GL native handles this setting but there's a chance it cuts out the caching behaviour that's causing the bug.
Little update. We are running Android 5.5.0 and iOS 3.7.3 and we are still experiencing this issue.
On iOS, everytime the app comes to foreground, we set the style URL with a query param that contains the current timestamp, so it should be "forcing" a new style URL.
Something like:
if let url = URL.init(string: "www.styleurl.com?cacheBreak=\(Date().timeIntervalSince1970)") {
self?.styleURL = url
}
It didn't fix it. The style seems to be refreshed. But the sprites.json and sprites.png can still be out of sync it seems. We will try the fresh=true.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is still an issue and will be prioritized
I think mapbox/mapbox-gl-js#4086 would be the best way to fix this but
Another approach would be to store every version of a sprite and have the api be able to serve specific versions. Every time you modify the sprite it would increment the version (or take a hash).
"sprite": "mapbox://sprites/mapbox/bright-v8?version=123"
馃憢 We deployed a server-side change in early April that we believe should resolve or significantly reduce instances of this issue. If you're still seeing instances of sprite json/pngs going out of sync in production, could you post back to this thread to let us know?
@dgohlke @christinedumont
I just ran into this issue in production today. I'm using the iOS SDK v4.3.0, if that matters. This is really disruptive to our users.
I see that there is now an ability to clear the "ambient cache" #4376. I think this might give me the ability to clear out the cached sprite sheet, but is there a less heavy-handed approach? I really don't want to have to clear the entire offline tile cache. I'd like to just get the latest sprite .json and .png whenever I launch the map.
For the moment, I feel like I can't update my map's sprite sheet without risking interfering with my current users' operation of the app.
@tsemerad Thank you for reporting your issue here. Could you confirm whether you updated your spritesheet in Mapbox Studio? If your style is public, could you share a link to it as well?
@asheemmamoowala Yes I updated the spritesheet in Mapbox Studio. The style is private unfortunately. The issue is sporadic (only happened on 1 of our test devices) but restarting the app doesn't fix it - only reinstalling the app.
@tsemerad could you please reach out to Mapbox suppport with your style URL and mention this issue?
@kkaefer I sent a support request at the end of last week. Thanks for the suggestion. I'll post here again when or if anything comes of it.
Most helpful comment
https://github.com/mapbox/mapbox-gl-js/issues/4086 is a long term solution that'll make it less likely for bugs like this in the future but it isn't necessary or sufficient to fix this particular bug. Given that this is affecting customers, should we look into a short term fix?