[Maps] Support for timeslider and playback

[alexfrancoeur]

In speaking with numerous users of the GIS community, a timeslider to quickly scan or playback your geospatial data over time is a common request. Some examples that come to mind are Google Earth, kepler and this popular OSS plugin.

Let's use this issue as place holder to discuss the best implementation and we can update accordingly.

[elasticmachine]

Pinging @elastic/kibana-gis

[alexfrancoeur]

After our discussion this week, let's try and put together a POC within the next couple of minors (after 7.1 FF?). Notes from our most recent discussion:

• Do we want a layer based time slider?
  • Probably not, would prefer to play back globally
• The timepicker defines the ends of the slider overall
• We likely will want to tackle in the Maps app first but ideally, a timeslider like this will live in the super data picker and can be utilized where the date time picker is. Alternatively, it could also be a dashboard input control.
• For the POC, we'd only focus on the Maps app
• If we take the start / end time from the global time picker, we can add a new agg on top of existing aggregations for a date histogram. A composite agg might help here.
• This could take some time, so it'd be nice to get some results back first for the first few steps / intervals played back and load the rest in parallel

cc: @nreese @thomasneirynck

[thomasneirynck]

@alexfrancoeur agreed with overall approach.

Hopefully, we can do this incrementally, as there's a lot of undefined scope (more on that below).

Much of the below is from in-person discussions:

There's a number of advantages to keeping the frame-size with a fixed width with this approach. To that end, we should investigate if we can retain responsiveness by grouping all the ES-agg requests under a top-level date-histogram aggregation. In practice, the terms-aggs for choropleth layers and geotile-aggs for heatmap layers would all be grouped under a date-histogram agg with a fixed frame size.

• aggregated layers in the map app can function in a straightforward manner(e.g. choropleth layers, heatmap layers). Each "frame" is a basically a fixed time-interval, so the maps app can now exactly what data to request up front, each time the global time-picker changes.
• the bulk work is performed server-side. It relieves the Maps-app of having to evaluate time-component on the client

There's known hurdles with this approach as well.

• it does not work for document layers. A more conventional approach may be required there, where the apps shows/hides features based on timestamp for each individual feature (caveats not withstanding, see below).
• the response size may be too large. This may require the maps-app to use ES's composite aggregations https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-composite-aggregation.html

We should not entirely discard a hybrid approach either.

• do client-side filtering for document layers
• make new round-trip for the choropleth or heatmap or top hit layers, as the users step to the frames

The undefined scope starts to creep in as I think we could hit a lot of edge-case behavior. This is especially the case when using the time-slider to animate tracks.

• There's a risk of a lot of jitter for features as users cycle through the slider (ie. [Maps] tracks source #33320):
  • with a top hits layer (ie. last known location, the POC here), there's a big risk of the top-hit falling outside the bounds of a frame.
  • track layers might blip in length, as segments of the track fall in and out of the frame
  • should the frame-size of the slider indicate last known position within the time-frame, or within the time elapsed from start of the global time-picker to end of the time-frame (?). The latter seems more intuitive to me for tracks
• time-based layers that satisfy the global time-range may need to be independent from the time-slider. The use-case here is animating the movement of a vehicle along its path.

[kmartastic]

• Do we want a layer based time slider?
• Probably not, would prefer to play back globally

I certainly want the ability to do global playback. However -- what was the guidance for layers that don't have a time field? I don't want my layers to disappear just because they don't have one.

• We likely will want to tackle in the Maps app first but ideally, a timeslider like this will live in the super data picker and can be utilized where the date time picker is. Alternatively, it could also be a dashboard input control.

Is there a reason why we can't build this to support more than the maps app at first?

@thomasneirynck @nreese

[kmartastic]

@nreese @miukimiu @thomasneirynck

Based on your prototype -- MVP scope looks like:

Timeslider can be enabled or disabled in the Maps app. It is off by default.
Time extent is based on the Time Picker.
Time window is always a smaller duration than the time extent.
Time window is not modifiable.
The user can manually step through increments of the time window. Back and forward.
Time window duration can be customized (dragging the start/end).
The user can drag the time window to move between steps.
Maps only.

[nreese]

closed by #99661