Friday, November 6th, 2015 at 9:34 am by ba3 — Category: Uncategorized

Altus 2.0 provides more granular control over internal resource management so you can give your users the best possible experience for your unique data and scenario. When Altus is asked to display multiple simultaneous map layers or layers that overlap, like radar weather over a base map, it tries to sequence the order of operations so the user has a fluid experience that minimizes waiting.

In some scenarios the default loading priorities are not optimized for the load latency, especially if one of the layers you’ve added has assets that need to be downloaded, or are being produced by CPU-intensive computations. In these scenarios, Altus 2.0 allows you to reprioritize the internal loading scheme to suit your data and your scenario.

Altus 1.0 exposed some control in this area by letting you configure the number of simultaneous ‘tile requests’ the engine could have open in parallel and you could also implement your own multi-threaded asynchronous tile providers. In the Altus 1.7 release, we took this concept further by offering an API to set layer priorities so a layer with a lower priority number would be scheduled for loading ahead of other layers.

In Altus 2.0, we go even further by allowing you to implement your own resource management system to control threading and OS thread scheduling. It is not necessary to use this system at all, because Altus 2.0 provides sensible default implementations, but, if you need the flexibility and the low level control to fine tune in this area, you can achieve optimal results.

The example illustrated here is a ‘stress’ test that mixes a variety of map resource types. Some are rate-limited by network operations (the radar weather data), some are CPU-bound computations (like the fractal pattern).

In the original Altus 1.0 scheme, it takes about 126 cumulative seconds to load this view, about 18 seconds from the user’s point of view. The base vector layer, which is arguably the most important, finishes last, and gets blocked waiting for slow resources from the network.

In Altus 2.0 with tuned priorities for this specific case, all layers take a cumulative total of 71 seconds to load. This is about 10 seconds from the user’s point of view, and the base layer loads first, giving the user a full layer to look at while the others load.

Altus 2.0 with tuned layer priorities can be significantly faster overall and well tuned resource management approach can make a large impact in the user experience of your application. Since only you know the unique requirements and bottlenecks of your data, with Altus 2.0 the control for how those are managed is now fully in your hands.