initial featuresAt implementation #3172
Conversation
- return layer name as string + feature properties dictionary - abstract r-tree & boost stuff into common header - more typedefs for clarity - more logging of parse box & interaction point - move interactivity parsing ahead of any bucket type branching
doesn't matter if we respond to bucket->hasData() here; features still exist in tile
| /** Query the visible map for features at a given point. | ||
| * | ||
| * @param point A point on screen, for example at a user gesture. | ||
| * @param radius A distance in which to query features around the point. |
There was a problem hiding this comment.
Should clarify that the distance is measured in screen points, not a physical unit or coordinate delta.
|
Cleaned up the demo a bit so that it works on all POI layers, regardless of zoom level, to be a little more self-evident.
|
| @@ -5,6 +5,8 @@ | |||
| #include <mbgl/map/source_info.hpp> | |||
|
|
|||
| #include <mbgl/util/mat4.hpp> | |||
| #include <mbgl/util/interactive_features_impl.hpp> | |||
There was a problem hiding this comment.
This can be #include <mbgl/util/interactive_features.hpp> right?
|
Tests? |
| @@ -26,6 +26,15 @@ typedef NS_ENUM(NSUInteger, MGLUserTrackingMode) { | |||
| MGLUserTrackingModeFollowWithCourse, | |||
| }; | |||
|
|
|||
| /** The style layer name for a queried map feature. */ | |||
| extern NSString * const MGLFeatureLayerNameKey; | |||
There was a problem hiding this comment.
Unlike MGLUserTrackingMode, these keys are only used by MGLMapView, so they can go in MGLMapView.h.
|
Would it be straightforward to include coordinates (either screen or geographic coordinates) in each feature description? The use case would be MapKit-style clickable POIs: you’d want the callout to be anchored on the POI, not the tap point, which may be a small distance away. |
|
We are dealing with more than just points here. Now that we support GeoJSON sources, the possibility exists to pass actual features, but the early intent here is the use case of tying to external identifier such as OSM ID. We can always make a more robust API in future, particularly when the style API lands. I'm going for basic functionality that I and others can iterate on going forward, but also meeting the use cases we are hearing about as blockers right now. |
|
👍 |
|
GL JS has revamped (and renamed) the featuresAt feature in mapbox/mapbox-gl-js#2224. |
|
Closing here; we'll want an implementation that more closely follows the new paradigm established in Mapbox GL JS. |
This is ready for implementation review, then it can be squashed. The goal here is a minimal
featuresAtfunctionality with configurable radius (owing to use in touch gesture scenarios) that returns basic information about queries on style layers markedinteractive.Right now the values returned for each feature are:
Couple things that can be added later:
One note @jfirebaugh: I wanted to adjust your
PointAnnotationImpluse of theBOOST_GEOMETRY_REGISTER_POINT_2DandBOOST_GEOMETRY_REGISTER_BOXmacros to be more in line with my setup ininteractive_features_impl.hppand my adjustment ofcollision_tile.hpp. It should be straightforward but I just couldn't figure it out for named field types in the Boost R-tree indexing scheme.Quick demo on iOS:
Once this looks good and lands, I will add the Android bindings as well.
Fixes #352.