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

Support "image" source type #1350

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

Comments

Projects
None yet
@tmcw
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

This comment has been minimized.

Show comment
Hide comment
@friedbunny

friedbunny Dec 19, 2015

Member

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.
Member

friedbunny commented Dec 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@damianw

damianw Jul 18, 2016

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

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 from Port ImageSource to Support "image" source type Sep 27, 2016

@jfirebaugh jfirebaugh added the Core label Sep 27, 2016

@incanus

This comment has been minimized.

Show comment
Hide comment
@incanus

incanus Nov 17, 2016

Contributor

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

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

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

This comment has been minimized.

Show comment
Hide comment
@alayers2

alayers2 Feb 9, 2017

Is support for this feature planned for the iOS SDK?

alayers2 commented Feb 9, 2017

Is support for this feature planned for the iOS SDK?

@aottenwess

This comment has been minimized.

Show comment
Hide comment
@aottenwess

aottenwess Mar 1, 2017

Also curious if there is a plan for the iOS SDK

Also curious if there is a plan for the iOS SDK

@boundsj

This comment has been minimized.

Show comment
Hide comment
@boundsj

boundsj Mar 2, 2017

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@damianw

damianw 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.

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

This comment has been minimized.

Show comment
Hide comment
@incanus

incanus Mar 2, 2017

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@incanus

incanus Mar 2, 2017

Contributor

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

Contributor

incanus commented Mar 2, 2017

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

@damianw

This comment has been minimized.

Show comment
Hide comment
@damianw

damianw 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?

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

This comment has been minimized.

Show comment
Hide comment
@incanus

incanus Mar 3, 2017

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@alayers2

alayers2 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?

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

This comment has been minimized.

Show comment
Hide comment
@jamala

jamala 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?

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

This comment has been minimized.

Show comment
Hide comment
@tikimcfee

tikimcfee Mar 22, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@jfalkner

jfalkner May 11, 2017

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

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

incanus added a commit that referenced this issue May 25, 2017

@1ec5 1ec5 referenced this issue Jun 1, 2017

Merged

[core][node] Support ImageSource #8968

5 of 5 tasks complete
@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Jun 1, 2017

Member

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

Member

1ec5 commented Jun 1, 2017

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

@friedbunny

This comment has been minimized.

Show comment
Hide comment
@friedbunny

friedbunny Nov 20, 2017

Member

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

Member

friedbunny commented Nov 20, 2017

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

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