When a time filter is applied, we must trim the track data (times, course, speeds, coordinates) to that time period.
We do that in at least these two places:
<Track> map component<GraphsPanel> for when user wants to just view current time period
If this becomes a performance issue, we have these options:
- introduce docContext object that is
filteredFeatures. When the features or timePeriod are updated, this object is calculated afresh, and memoised
- Introduce
filteredFeatures in Document. Filter features on new time periods. Pass the object via params to <GraphsPanel> and <Map>
- introduce
cachedFeatureStore. It's a method that receives a feature and a time period. If it doesn't have data for that period and feature it creates and stores it. Then it returns it. It could response to TimeInterval and Features changes. Changes to TimeInterval clear the store, and changes to a feature clear cached values for that feature. It could lazily pre-generate filtered tracks at the calculated time intervals.
When a time filter is applied, we must trim the track data (times, course, speeds, coordinates) to that time period.
We do that in at least these two places:
<Track>map component<GraphsPanel> for when user wants to just view current time periodIf this becomes a performance issue, we have these options:
filteredFeatures. When thefeaturesortimePeriodare updated, this object is calculated afresh, and memoisedfilteredFeaturesinDocument. Filter features on new time periods. Pass the object via params to<GraphsPanel>and<Map>cachedFeatureStore. It's a method that receives a feature and a time period. If it doesn't have data for that period and feature it creates and stores it. Then it returns it. It could response toTimeIntervalandFeatureschanges. Changes to TimeInterval clear the store, and changes to a feature clear cached values for that feature. It could lazily pre-generate filtered tracks at the calculated time intervals.