Skip to content

Date filter #60

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

Open
wants to merge 32 commits into
base: main
Choose a base branch
from
Open

Date filter #60

wants to merge 32 commits into from

Conversation

indraneel
Copy link
Collaborator

Available PR templates

indraneel added 9 commits July 9, 2025 19:02
- Add DateRange interface for start/end dates and times
- Add DateFilterPreset interface for quick filter options
- Update StacSearch interface to include datetime field
- Add date filter properties to StacMapContextType interface
- Add date filter utility functions for item filtering and STAC search formatting
- Add date range validation and preset configurations
- Add URL persistence utilities for date range serialization/deserialization
- Support for date/time parsing and ISO 8601 formatting
- Add dateRange state and setDateRange function
- Add clearDateRange and isDateFilterActive computed property
- Integrate date filter state with existing context
- Add URL persistence for date range state
- Add useFilteredSearchItems hook for client-side item filtering
- Add useFilteredCollections hook for collection temporal filtering
- Implement memoized filtering logic for performance
- Support filtering based on item datetime and collection temporal extent
- Update stac-search hook to include datetime in STAC API requests
- Add date range to query keys for proper cache invalidation
- Update stac-geoparquet hook to filter DuckDB queries by datetime
- Support server-side filtering for improved performance
- Add DateFilter component with preset options and custom date inputs
- Integrate DateFilter into panel search tab
- Add visual indicators for active date filters in search results
- Support for quick presets and custom date range selection
- Update map to use filtered search items and collections
- Add visual indicators for active date filters
- Support for filtered GeoJSON layer generation
- Maintain map performance with filtered datasets
@indraneel indraneel mentioned this pull request Jul 9, 2025
Copy link
Collaborator

@gadomski gadomski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for this! #4 isn't well written (apologies), but there's actually two different types of "date time filtering" we support and that you implement in this PR:

  • Filtering of already-loaded items, whether those items are loaded into searchItems or value (via an item collection)
  • Setting the datetime interval on a search

I think we should separate the two, putting the "filter items already loaded" stuff in a new tab with the standard <LuFilter /> icon. That lets us access the filtering even if the value doesn't support search, e.g. with item collections.

Comment on lines 46 to 50
export interface DateFilterPreset {
id: string;
label: string;
getDateRange: () => DateRange;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this file has been (so far) just for "stac-y" values ... this feels like it should live in the date-filter component?

Please push back if that's not standard practice for react apps.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed, was being lazy. changed

Comment on lines 30 to 32
item.properties?.datetime ||
item.properties?.start_datetime ||
item.properties?.end_datetime;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't quite right because we're loosing the "range" part of an item's datetime. I think we'll need something like (pseudocode): ((item.datetime || item.start_datetime) >= effectiveStartDate) || ((item.datetime || item.end_datetime) <= effectiveEndDate)

Comment on lines 135 to 139
// Date filtering properties
dateRange,
setDateRange,
clearDateRange,
isDateFilterActive,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious (not sure one way or the other) if we want to pull this all the way up to the app's state, or keep it in panel. My instinct is to keep it in panel, because we'll want to re-set the date range whenever we change value, because the date range will be bound by (e.g.) a collection's temporal extents or the temporal extents of an item collection's items

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless i'm misunderstanding, this makes me think that dateRange should be in the app state since it's tied with value

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be derived from value, but might be different for searching (find me all items in 2025) and filtering (now that I have a search result from the server API, narrow the items in that search result down to June 2025).

@indraneel indraneel requested a review from gadomski July 10, 2025 20:43
@indraneel
Copy link
Collaborator Author

indraneel commented Jul 11, 2025

i split out client side temporal filtering and added a separate ui for it. not tested across all the various types of inputs fwiw but seems to function decently well. will respect the server-side search temporal boundaries and the collection-level boundaries if those exist

scrubber.mov

@gadomski
Copy link
Collaborator

Yoooo this is it. I'll take a look at the code tomorrow but the functionality is dank

Copy link
Collaborator

@gadomski gadomski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This is looking good. Some notes as I monkey'd around.

Functionality change requests

When there's no temporal data available, let's disable the tab (since that's what we've been doing w/ the other tabs):
image

The default state when there's no filter looks a little funny -- not sure the right way to show the sliders, maybe just for the full collection temporal extent?
image

I think it'd be nice to have the slider on the search page too?
image

Bugs

@indraneel
Copy link
Collaborator Author

indraneel commented Jul 14, 2025

Bugs should be fixed.

added most of the features suggested:
image

image

I disagree about the search slider. I think the UX value of the slider is to immediately see results as you interact with it, so I don't think it makes sense to have a slider that triggers a network request each time. I am open to the idea that this is clunky UX and worth refining (we can remove server side date filtering entirely? especially since we're allowing for client-side filtering too)

@gadomski gadomski self-requested a review July 14, 2025 16:07
Copy link
Collaborator

@gadomski gadomski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking sharp, just a couple more things 🙇🏼

@indraneel
Copy link
Collaborator Author

  • I can move the accordion
  • I'll look at the Yellowstone data to try to reproduce this but would appreciate reprod steps
  • I'll remove the scrubber zoom buttons if i can't get them to work properly
  • As discussed, making the scrubber this will require state changes so I'll attempt those

@gadomski
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants