-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Support "image" source type #1350
Comments
For those attempting to use styles with image sources, this is the error they'll see:
|
Is any progress being made on this + #4311 (what is the priority for a future release)? |
Here's a workaround using the annotation view API that's pretty close for most use cases: https://gist.github.com/incanus/7e19ca99f76c0b3d32ae147872325722 |
Is support for this feature planned for the iOS SDK? |
Also curious if there is a plan for the iOS SDK |
This issue is tracking implementation in |
Honestly, that's ridiculous. It's been over a year since your team has dropped support for the legacy SDK. Not only that, but you've deleted the repo for it -- which is unheard of. And yet, all this time later, you're saying that achieving feature parity with the old SDK is still low priority? I suspect we are not your only customer that is getting increasingly agitated that your team has provided neither a suitable replacement for the features which have been yanked from under their feet nor support for the old tools that you provided. |
Give this a try, possible today with the 3.5.0-series data-driven styling betas, and see if it meets your use cases. tl;dr You can do this yourself with the capabilities that we are focusing on in the SDK... i.e. more general-use functionality allowing you to accomplish many kinds of different things and better building a long-term foundation for our tools. https://gist.github.com/incanus/8c277a0700c917ac58600d93cd849bb8 |
BTW the above is more performant than the other workaround detailed in #1350 (comment). |
Thanks for the workaround; unfortunately I can't make use of it since I am waiting for the feature on Android, but I will send it to our iOS team to see if it works well enough for them to update to the new SDK. Sorry if that wasn't clear. Are you aware of similar workarounds for Android? |
Yes, this will work just the same on Android, as data-driven styling is supported there as well. See the |
This workaround is really good. I was able to test it today and it looks way better than using the UIView based annotations and shoving images into them. The only problem with this approach is that the spritemap fills up very quickly when working with images of any size, and I can't add all of the images that I want to the map. (At least I assume that's what is happening) Is there any way to work around that limitation besides increasing the size of where the map stores images for a style? |
I am using this workaround to show multiple images, using a symbol layer for each image. However, only 12 images are visible on the map. Is this the same issue as described in the above comment? Also, are there plans to support images as a first-class feature instead of using the symbol layer as a workaround? |
Hey! Giving a big +1 to this, as the symbol-layer solution (though functional) isn't really ideal. You've got the same marker-drag-lagginess issue which looks wonky, and there's a lot more overheard to handle actually adding these things to client maps. |
Echoing the above. Need support for this on Android, and the work-around isn't a great fix. |
Image sources are now available in iOS v3.7.0 (e.g., |
Much like #601 this is a parity issue. V8 can ship without this mapbox/mapbox-gl-style-spec#264 but we want to implement Video & Image source support in gl-native.
Description: like video source, except it doesn't move and it's an image.
The text was updated successfully, but these errors were encountered: