Exception when root tiles of an imagery layer fail to load

[kring]

When tiles fail to load, Cesium tries to use their parent tiles. However, it doesn't account for the possibility that the parent tiles failed to load, too. It should.

This was reported here:
https://groups.google.com/forum/#!topic/cesium-dev/qiQdtnJRW18

[emackey]

I'd like to see better error reporting for end-users here. If the root tiles fail to load, it could mean that the proxy is mis-configured, or the imagery source itself has gone offline, among other things. We should nudge the user to check on their proxy and their network connectivity, and we might want to fall back on a single-tile default so they at least have a globe to look at.

[emackey]

Also, re-reporting the same failure every time the camera moves and the tiles attempt to reload is kind of brain-dead. Can we make this smarter too?

[kring]

I'd like to see better error reporting for end-users here.

Before a tile is considered "FAILED", an event is raised notifying anyone who cares that the problem occurred. Handlers of the event can tell the layer whether to retry the tile, or just consider it failed. An application could hook to this event to display the error to the user, fall back on another imagery provider, or whatever else it deems appropriate. It would be inappropriate to do any of that at the ImageryProvider/Layer level.

[kring]

Also, re-reporting the same failure every time the camera moves and the tiles attempt to reload is kind of brain-dead. Can we make this smarter too?

A failure of a single tile is only reported once. But when you move, different tiles are loaded and those may fail, too. An application (hooking to the event above) could handle the error event and kill the provider after so many failures, if it wanted to do so. But again, it would be wildly inappropriate to do that at this level.

[emackey]

Fair enough. Perhaps this is something that could be handled by the widget.

[mramato]

@kring and @emackey Is this still an issue? If there's a separate issue related to this bug, but the original issue is indeed fixed, can we close this and open a new issue with a clearer purpose.