Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Imagery provider API consistency
See original GitHub issueIt is kind of weird and inconsistent that we use functions for some types classes for others. I know perfect is the enemy of the good and all that, but it makes our API harder to use.
I think we should change createOpenStreetMapImageryProvider and createTileMapServiceImageryProvider back into classes so they match the other imagery provider types. They could inherit from UrlTemplateImageryProvider so we don’t have to worry about introducing more duplicate code.
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@thw0rted I opened a PR a while ago but it hasn’t been a priority for us to review and merge it #6203
If
createOpenStreetMapImageryProviderdoesn’t take aResource, that’s a quick fix we should be able to do in the meantime. @ProjectBarks would you have a minute to look into that? All other imagery providers should take aResourceDid this ever go anywhere? Also, createOpenStreetMapImageryProvider is maybe the only place that takes a URL as a string, not a Resource, and is thus completely impossible to load through a proxy.