Imagery fallbacks

Hi, some of you noticed our Bing maps imagery layers aren’t working this morning, we’re working to get that resolved quickly.

I have a question for the community about what our default behaviors should look like. Obviously if an imagery layer throws errors, the widget should catch that and swap in another layer as a backup. But I have a question about what to do before layer 0 (the base layer) has loaded:

Imagine the case of a user, with a local CZML file, but only the poorest-quality dial-up access to his imagery provider. Layer 0 is coming down, just not soon, and his CZML has already finished loading, so his loading screen has disappeared. This could happen to a remote mobile user perhaps. The imagery layer isn’t going to throw an error, it will work… eventually. Our current behavior is not to render any tiles, so the Earth is transparent to the star background behind it. Should we change this to render a default solid color, like dark blue or black, instead of skipping the render?

Sure, users on fast connections will see a blink of dark blue or black while they wait for level 0 to load, but today they’re seeing a blink of star background during that same interval. If they’re stuck looking at that sorry state for any length of time, I’d offer that a solid color would be preferable to the star background by a wide margin. I think this is more in line with how web behavior in general works, where the browser tries to render as best it can while pieces are still loading.

Should we make this change?

–Ed.

+1 for a solid (configurable) color.

  • As you say, this is how web generally works,

  • When no atmosphere is rendered a transparent layer can really make the user think something is wrong and leave (can even be true with the atmosphere rendered).

Cheers,

Victor

Hi. Are all the imagery layers still down? I develop on wamp enviroment (localhost) (b12 + Chrome 24.0.1312.52) and all I get is the athmosphere + skybox. All the Sandcastle demos of different imagery providers etc. worked nicely couple of days ago. Or is this just me?

+1 solid dark blue/configurable color. :slight_smile:

Ed - the solid color is OK with me too. As long as Kevin is for it, it’s a go.

Karpo - Our Bing Maps key expired unexpectedly so your version of b12 is not able to connect to Bing Maps. However, if you pull from master on github, you’ll get a version that works. We’re updating b12 on the downloads page. Will let you know when it is ready.

Regards,

Patrick

Short version: This should be fairly easy to do, so if a few folks think it will be an improvement I’m all for trying it.

Long version: I don’t think this is the right solution, because:

  • When things are working normally (hopefully the common case), the globe will flash the wrong color just before the imagery appears. It will be distracting.

  • A solid-color globe still looks broken. If the imagery doesn’t appear, or takes a long time to do so, the user will still be left wondering what they’re looking at. Is this the world’s crappiest virtual globe? Or is it just not done loading yet? Did something break? Or do I need to wait longer?

The right solution, IMO, is to show a loading indicator until imagery (and terrain) level zero is ready to render. The same is true of other resources like stars, CZML, etc. This is a very general problem.

It’s ok to render the scene (such as it is) under the loading indicator, and maybe then it makes sense to show the globe blue before the imagery is loaded. Or maybe black because it would cause less of a distracting flash, but making the solid color configurable will cover that.

Kevin

Is it hard to try it on a branch to see what it looks like? I don't think
the visual will be nearly as bad as you describe.

                  --Ed.

We can also consider quickly fading from the solid color to the imagery.

Patrick