Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Maps] Support for timeslider and playback #27714

Closed
alexfrancoeur opened this issue Dec 21, 2018 · 6 comments
Closed

[Maps] Support for timeslider and playback #27714

alexfrancoeur opened this issue Dec 21, 2018 · 6 comments
Assignees
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation enhancement New value added to drive a business result v7.14.0

Comments

@alexfrancoeur
Copy link

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.

@alexfrancoeur alexfrancoeur added release_note:enhancement [Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation :GIS App labels Dec 21, 2018
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-gis

@nreese nreese added enhancement New value added to drive a business result and removed release_note:enhancement labels Feb 28, 2019
@alexfrancoeur
Copy link
Author

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
Copy link
Contributor

thomasneirynck commented Apr 19, 2019

@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.

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
Copy link
Contributor

  • 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 kmartastic assigned kmartastic and nreese and unassigned kmartastic Apr 8, 2021
@kmartastic
Copy link
Contributor

@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
Copy link
Contributor

nreese commented Jun 21, 2021

closed by #99661

@nreese nreese closed this as completed Jun 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation enhancement New value added to drive a business result v7.14.0
Projects
None yet
Development

No branches or pull requests

5 participants