raster layer "loading" pattern and "errored" pattern

[soupman99]

Is there a way to set a grid pattern as the bg while tile requests are waiting to be loaded?

[lucaswoj]

@soupman99 There isn't a good way to do this yet. There should be! Would you like to get the ball rolling on this feature by opening a ticket at https://github.com/mapbox/mapbox-gl/issues and proposing a syntax? 🙇

[1ec5]

We previously attempted to implement this in the iOS SDK (mapbox/mapbox-gl-native#119) as a built-in, non-customizable feature (though we had to back it out for performance reasons).

[jfirebaugh]

Can't you already do this with a background layer and background-pattern?

[incanus]

A grid pattern should have the following properties:

• It should be instantly or near-instantly available to serve as a reference point for motion and zooming as resources are loading (including style sprites, which can come in asynchronously).
• It should move with the map pan and zoom, serving as a "surface" upon which the map is always drawn and giving reference to the user.

I don't think background layer or background-pattern hit the first point. To do this, the drawing would have to be done "statically" inside of GL itself, such as with a code-embedded bitmap or an already-referenceable image URL that is independent of sprite sheet fetching, parsing, and using.

[jfirebaugh]

I agree on the second point, but I don't see the first point as essential. I think rendering nothing if there is literally nothing to render is an acceptable behavior, and the benefit of an (unconfigurable) default is slight compared to the flexibility provided by making it style-driven.

[jfirebaugh]

Can't you already do this with a background layer and background-pattern?

The reason this doesn't work for this use case is it doesn't allow a different background for an unloaded versus loaded tile.

My proposal for style syntax is mapbox/mapbox-gl-style-spec#219 (comment).

[incanus]

I don't see the first point as essential.

This is less important on web, sure, than mobile, where a much faster time-to-interaction is expected since it's supposed to feel local (and indeed, the framework is local). But the idea is your pans and zooms are seen as having effect even if the map isn't there yet.

[1ec5]

Consider that it’s very easy and natural for the user to swipe (fling) the map on a mobile device. So it’s very easy for the user to end up outside the loaded area. Once that happens, the user has totally lost their bearings, having no idea how far the map has traveled. Making matters worse, on mobile devices, standard scrolling views implement a much more aggressive “drifting” or “deceleration” animation than the one in GL JS. The standard iOS behavior, which the Mapbox iOS SDK implemented in mapbox/mapbox-gl-native#1292, lasts for one second regardless of the gesture’s intensity. GL JS doesn’t implement such an aggressive drift, so a mobile user’s intuition is even further from the map’s actual behavior.

Since the user can’t expect the map to travel the same distance that their finger did, the scroll view needs some sort of visible landmark that scrolls along with the blank map. A grid or checkerboard would be the most robust way to provide such landmarks, because it can’t be mistaken for actual map content. Otherwise, in the absence of landmarks, the user perceives a hang and makes matters worse by swiping even more. (It’s like when you double-click an icon on a Windows desktop but nothing happens, so you keep double-clicking and wind up with a dozen instances of Edge open. 😬)

Once the user understands that the map is merely loading and not hung, they may attempt to swipe in the other direction – blindly, because the previously visible map has been booted out of the cache. This may sound like an edge case, but it’s easy to encounter casually on a mobile device.

[jfirebaugh]

@1ec5 I agree with everything you said. The edge case @incanus and I arguing about is not unloaded tiles, it's the case where not even the style or sprite image are available -- i.e. they are not in memory, cached, available in an offline pack, prebundled with the app, or accessible with reasonably quick network requests. I'm arguing that in that case, showing a blank canvas rather than an empty grid is not a dealbreaker.

[incanus]

I'm arguing that in that case, showing a blank canvas rather than an empty grid is not a dealbreaker.

Could we not bundle a raster with the SDKs, as we used to with the raster iOS SDK? Even having this be style-independent, i.e. a single, non-configurable image could hit these cases.

As an analog: rotating the map shows the compass even when no style resources have been loaded.

I realize this is getting a bit off-topic for the JS repo...

[soupman99]

@incanus not off topic to me. I'm bundling the JS lib for a hybrid ionic app. Native SDK's or not, I think having some sort of indicator for non-loaded tiles would be beneficial even it's not configurable.

[pke]

So is this solved already? Can we specify a background for unloaded map parts?

[lucaswoj]

@pke The ticket is still open, this is not solved yet.

[lucaswoj]

Merging this into #4156