Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Support "image" source type #1350

Closed
tmcw opened this issue Apr 27, 2015 · 17 comments
Closed

Support "image" source type #1350

tmcw opened this issue Apr 27, 2015 · 17 comments
Assignees
Labels
Core The cross-platform C++ core, aka mbgl GL JS parity For feature parity with Mapbox GL JS

Comments

@tmcw
Copy link
Contributor

tmcw commented Apr 27, 2015

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.

@friedbunny
Copy link
Contributor

For those attempting to use styles with image sources, this is the error they'll see:

{Map}[Style]: Failed to parse [image.png]: 0 - Invalid value.

@damianw
Copy link

damianw commented Jul 18, 2016

Is any progress being made on this + #4311 (what is the priority for a future release)?

@jfirebaugh jfirebaugh changed the title Port ImageSource Support "image" source type Sep 27, 2016
@jfirebaugh jfirebaugh added the Core The cross-platform C++ core, aka mbgl label Sep 27, 2016
@incanus
Copy link
Contributor

incanus commented Nov 17, 2016

Here's a workaround using the annotation view API that's pretty close for most use cases:

https://gist.github.com/incanus/7e19ca99f76c0b3d32ae147872325722

@alayers2
Copy link

alayers2 commented Feb 9, 2017

Is support for this feature planned for the iOS SDK?

@aottenwess
Copy link

Also curious if there is a plan for the iOS SDK

@boundsj
Copy link
Contributor

boundsj commented Mar 2, 2017

This issue is tracking implementation in Core GL which means the underlying C++ implementation of this library. The platform specific (i.e. iOS, Android, Qt) wrappers can be completed after the core work is done. At this time, this feature is not on any platform release milestones and our focus is on completing the implementation of data-driven styling in core and all platforms.

@damianw
Copy link

damianw commented Mar 2, 2017

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.

@incanus
Copy link
Contributor

incanus commented Mar 2, 2017

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

overlay

@incanus
Copy link
Contributor

incanus commented Mar 2, 2017

BTW the above is more performant than the other workaround detailed in #1350 (comment).

@damianw
Copy link

damianw commented Mar 3, 2017

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?

@incanus
Copy link
Contributor

incanus commented Mar 3, 2017

Yes, this will work just the same on Android, as data-driven styling is supported there as well. See the GeoJsonSource, SymbolLayer, and CameraFunction classes to replicate the source, layer, and dynamic sizing functionality as in the iOS example. You'll need the beta there, too, which is 5.0.0-beta.1 or -beta.2.

@alayers2
Copy link

alayers2 commented Mar 4, 2017

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?

@jamala
Copy link

jamala commented Mar 15, 2017

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?

@tikimcfee
Copy link

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.

@asheemmamoowala asheemmamoowala self-assigned this Apr 17, 2017
@jfalkner
Copy link

Echoing the above. Need support for this on Android, and the work-around isn't a great fix.

@1ec5
Copy link
Contributor

1ec5 commented Jun 1, 2017

This feature is being implemented in #8968 and #9110.

@friedbunny
Copy link
Contributor

Image sources are now available in iOS v3.7.0 (e.g., MGLImageSource) and Android v5.2.0.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Core The cross-platform C++ core, aka mbgl GL JS parity For feature parity with Mapbox GL JS
Projects
None yet
Development

No branches or pull requests