Support getLeaves and other new clustering methods in the iOS SDK

[lilykaiser]

We need an iOS equivalent of mapbox/mapbox-gl-js#6829 to support features created in the most recent release of supercluster.hpp including getChildren, getLeaves, and getClusterExpansionZoom.

[1ec5]

The Android equivalent to this issue is #12441.

The platform-specific SDK code doesn’t have direct access to Supercluster; changes will need to be made to mbgl::style::GeoJSONSource, and mbgl’s dependency on Supercluster will need to be upgraded to v0.3.0.

mapbox-gl-native/cmake/mason-dependencies.cmake

Line 9 in 5623fa1

mason_use(supercluster VERSION 0.2.2 HEADER_ONLY)

The most literal port would add three new methods to MGLShapeSource. The method signatures that mapbox/mapbox-gl-js#6829 exposes seem somewhat ill-suited for the iOS/macOS map SDK’s public API. Normally things like this are synchronous in iOS/macOS frameworks; is there an overriding reason why it would have to be asynchronous?

Instead of separate methods on MGLShapeSource, would it be possible to automatically add this information to any feature querying result that happens to be a cluster? It seems like the developer would have to use feature querying before these methods anyways, because there’s no other way to obtain the cluster identifier. If we do add this information to feature querying results, one source of awkwardness is that the result type is an MGLFeature-conforming class. To avoid polluting the namespace for features obtained by other means, it might be necessary to further subclass each of the MGLFeature classes (which would be an argument in favor of eventually implementing #7454).

/cc @mourner

[mourner]

is there an overriding reason why it would have to be asynchronous?

In GL JS, it's asynchronous because the Supercluster index lives on the worker thread, and when we query the clusters from from the thread, there's no way to communicate between threads synchronously. I'm not sure what's the current threading setup in native with regards to Supercluster/GeoJSON-VT indices.

Instead of separate methods on MGLShapeSource, would it be possible to automatically add this information to any feature querying result that happens to be a cluster? It seems like the developer would have to use feature querying before these methods anyways, because there’s no other way to obtain the cluster identifier.

We can't combine queryRenderedFeatures and any cluster APIs in GL JS because the former is synchronous with render index living on the main thread, and the latter is async.

The getLeaves API also has certain arguments (e.g. for pagination — how many items to skip, and how many to return), and it would be awkward to require those without a person having an explicit intent to query leaves of a cluster.

[julianrex]

@lilykaiser As I understand it, this requires a change on the core side.

/cc @kkaefer

[lilykaiser]

The change on the core side should be in progress / done soon according to @tobrun