Implementing feature interactivity

[ansis]

At a high level I think feature interactivity can be split into two main pieces:

• RFC: Tracking feature state for interactivity RFC: Tracking feature state for interactivity #6021
• RFC: Updating the appearance of individual features RFC: Updating the appearance of individual features #6020

Both of these proposals have plenty of other open questions that could be split into separate issues.

One open question is how to merge features across tile boundaries:

• RFC: Feature identity for interactivity RFC: Feature identity for interactivity #6019

Next steps

@kkaefer @asheemmamoowala @mollymerp @anandthakker @mourner @lucaswoj

It would be good to get feedback on these proposals. What seems like a good idea and what doesn't? What alternative options did I miss?

After we figure out the high level direction we can start splitting up the design and implementation work into pieces.

---

@asheemmamoowala compiled list of all relevant issues:

Suggestions/Requests

• style-spec hover and active style properties: Support "hover" and "active" styles for features #200
• feature-enter and feature-leave events: Request: mouseenter/mouseleave for individual features #5539
• ray picking for selecting extrusions: Use ray picking to query extrusions in "queryRenderedFeatures" #3122
• optimize for hover and select: Optimize "Map#setFilter" performance for "hover effect" use case #2874
• optimise setFilter: Improve "setFilter" performance on big GeoJSON datasets #2443
• hover issues: Test fixture update #550
• callouts for POIs: [iOS] Support callout for POI (public transport stops, etc) mapbox-gl-native#5432
• re-constitute query geometry for geojson:
  For GeoJSON sources, can query*Features return the original geometry? #5639
  Feature querying should return existing annotations mapbox-gl-native#6178
  mbgl::style::GeoJSONSource should have GeoJSON getter mapbox-gl-native#7376

Related tickets:

• js color expressions for highlighting: Add color modifying expressions #5676
• selection at tile boundaries breaks: queryRenderedFeatures failing for circle layers on a tile boundary mapbox-gl-native#10615
• iOS tap gesture for feature querying: Tap gesture recognizer for style layers mapbox-gl-native#6515
• query methods to work with raster layers: Make query methods return raster features/sources #1404
• ignore holes in polygon query: Ignore "holes" in query*Features collision detection #2293
• string feature IDs: query*Features should preserve non-integer feature IDs #2716, -
• [2.1] Feature ID datatype vector-tile-spec#94
• frequent geojson data updates: https://github.com/mapbox/gl-internal/issues/818
• improved event handling New events related functionalities #5818

[mb12]

@ansis Can you please clarify what kind of new use cases this will address? At the moment, for interactivity something like the following works for almost all uses cases.

1. Listen to event (tap, click, hover, touch etc).
2. Call Map.queryRenderedFeatures (usually for specific style layers)
3. Update style depending on results of query. (Change filter, or any other property).

[ansis]

hi @mb12, I probably should have called this issue improving feature interactivity. You're right, a lot of this is kind of possible but we're trying to make it easier and make it more performant. Currently it can take a lot of extra code to do something that should be simple, like setting a hover style. And when you get it working it turns out that the current approach is really slow. We're hoping to get to the point where interactive behavior, like a hover style, is easy to add and has no noticeable latency.

[andrewharvey]

style-spec hover and active style properties: #200

I like the idea of building this into the style spec somehow since it allows the map designer to control the visual elements of the hover or active states of a feature directly in Studio rather than in code.

At the moment you have to agree on some kind of convention with the layer names like "layer-hover", "layer-active" and it's a bit messy fiddling with the filter on those layers in Studio so the designer can see what it will look like when those states are active (potentially together).

On the other hand leaving thin convention up to the user to keep the style spec as universal as possible is also a valid argument.

[ansis]

I like the idea of building this into the style spec somehow since it allows the map designer to control the visual elements of the hover or active states of a feature directly in Studio rather than in code.

@andrewharvey yep, that would definitely be an advantage of Option 1 here. Do you have any thoughts on the open questions there?

[andrewharvey]

@andrewharvey yep, that would definitely be an advantage of Option 1 here. Do you have any thoughts on the open questions there?

@ansis You've done a great job covering everything in your 3 tickets, thank you for that. 👍 Agree with all the points in the motivation, as these are all things that people implementing GL JS apps do run into.

[kkaefer]

/cc @mapbox/studio