Further annotation refactoring

[jfirebaugh]

• Use an rtree for points instead of pre-creating tiles for all zoom levels (replaces Convert point annotations to RTree instead of pre-creating tiles for all zoom levels #1694)
• Lazily create AnnotationTile objects and transfer ownership to worker (fixes thread safety issues)
• Reduce number of datastructures used
• Remove shape layers from style

👀 @kkaefer

[1ec5]

If MGLDefaultStyleMarkerSymbolName is no longer needed, it doesn’t need to be declared up top anymore.

/cc @incanus

[incanus]

Cursory review looks solid. Questions:

• In moving to getPointAnnotationsInBounds(), we give up the possibility of querying for shapes in future. In Support selection of shape and polyline annotations #2082 we want to eventually do this.
• Should we be using a combined R-tree for both annotations and server tile features, to lay groundwork for Feature eventing (native equivalent of queryRenderedFeatures and querySourceFeatures) #352?
• I think per past discussion we agreed to discuss any introductions of new Boost utilities (boost::geometry::index::rtree being the addition here). Just a point of order. So let's discuss 😄

[jfirebaugh]

• In moving to getPointAnnotationsInBounds(), we give up the possibility of querying for shapes in future. In Support selection of shape and polyline annotations #2082 we want to eventually do this.

I view getPointAnnotationsInBounds() as a stopgap, assuming that #2082 will be implemented via #352.

• Should we be using a combined R-tree for both annotations and server tile features, to lay groundwork for Feature eventing (native equivalent of queryRenderedFeatures and querySourceFeatures) #352?

If it follows the gl-js implementation, #352 will indeed use an R-tree. But I think that's a separable change.

I wish the existing annotations code could use geojson-vt-cpp for both points and lines, and not use an R-tree at all. But because the API encourages adding points one by one, rather than as a single group/layer, it's difficult/impossible to make that efficient. (Another example of how the public API is limiting the implementation options.)

• I think per past discussion we agreed to discuss any introductions of new Boost utilities (boost::geometry::index::rtree being the addition here). Just a point of order. So let's discuss 😄

We are already using boost::geometry::index::rtree in CollisionTile.

[incanus]

I wish the existing annotations code could use geojson-vt-cpp for both points and lines, and not use an R-tree at all. But because the API encourages adding points one by one, rather than as a single group/layer, it's difficult/impossible to make that efficient. (Another example of how the public API is limiting the implementation options.)

We'll always need the ability to add points one-by-one on mobile, but perhaps we could think about the styling / management on the backend in the style of what's proposed in #1708 as we start to consider ways to make our API do things other frameworks don't provide for due to our styling advantages.

👍 on everything else.