Update imagery providers to use UrlTemplateImageryProvider

[pjcozzi]

No description provided.

[pjcozzi]

@kring could you make a list of imagery providers that could be implemented using UrlTemplateImageryProvider in order of difficulty? We may have some help for this.

[kring]

It should be possible to implement all of them in terms of UrlTemplateImageryProvider.

These are already done:

• WebMapServiceImageryProvider
• MapboxImageryProvider

These should be really easy:

• TileMapServiceImageryProvider
• OpenStreetMapImageryProvider

These may be more complicated:

• GoogleEarthImageryProvider
• ArcGisMapServerImageryProvider
• WebMapTileServiceImageryProvider

These don't make a lot of sense to change:

• GridImageryProvider
• SingleTileImageryProvider
• TileCoordinatesImageryProvider

We'll need to add a {quadKey} or something similar to UrlTemplateImageryProvider for BingMapsImageryProvider, #1378.

[pjcozzi]

Thanks @kring.

@TiffanyLu @adamdavidcole this could be a nice project after the KML examples depending on your interests. It would only be a few weeks, not the rest of the semester.

[sen-lu]

@pjcozzi when you say KML examples, did you mean CZML or did you want us to do additional work with KML support?

[pjcozzi]

Just CZML. That is a typo.

[pjcozzi]

@kring do you think this is still worth someone pursuing for any of the remaining types?

[kring]

@kring do you think this is still worth someone pursuing for any of the remaining types?

Nah, not much to be gained IMO. I'll close this.

[mramato]

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

[hpinkos]

Seconded. Consistency is key for API usability. Maybe we could rework createOpenStreetMapImageryProvider and createTileMapServiceImageryProvider into classes that inherit from UrlTemplateImageryProvider instead.

[kring]

Sure, I can see that the inconsistency makes the API harder to use.

So, @mramato and @hpinkos, are you suggesting that we move to an all-function API? So users never do new WebMapServiceImageryProvider(...), they instead do createWebMapServiceImageryProvider(...)? I'm not sure that's an improvement. In fact it's inconsistent with how most everything else works in Cesium. But if we do want that, it's just a matter of making function wrappers for the imagery types and marking the classes private. It's completely unrelated to this issue, which is talking about how the imagery providers are implemented. For example, WebMapServiceImageryProvider is already implemented in terms of UrlTemplateImageryProvider, yet it is constructed with new rather than by calling a function.

So maybe we should be all classes? It's worth revisiting why we have functions - rather than classes - for OSM and TMS in the first place. There were basically two arguments for it:

1. Those classes were never very useful in the first place. Leaflet doesn't have them, for example. Interfacing with TMS and OSM with just a URL template is pretty straightforward. If we thought about it more carefully from the beginning, we might not have even provided specific OSM and TMS support.
2. Writing those providers as classes requires a bunch of trivial boilerplate. We implement a bunch of functions that do nothing other than call the same function on UrlTemplateImageryProvider. By making them functions instead, we make Cesium smaller.

So if we accept point 1, we might also say that the usability point is pretty much moot because most people will use UrlTemplateImageryProvider directly anyway.

Point 2 could be addressed with @hpinkos's suggestion: inherit from UrlTemplateImageryProvider rather than aggregating it. AFAIK this would be the first use of inheritance anywhere in Cesium, though.

TL;DR: this issue should be closed. If there's something specific you want to see happen with the TMS and OSM functions (or all the other imagery providers maybe?) then write an issue to say that. This one is only talking about changing the way the imagery providers are implemented, which is totally orthogonal to the public API.