Integration of Radiant Earth's STAC-Browser with eoAPI

[zacharyDez]

Description

The Radiant Earth's STAC-Browser is a widely adopted front-end tool to search and visualize STAC queries. It's well maintained and already uses some of the underlying technologies of eoAPI, specifically TiTiler.

Integrating STAC-Browser with eoAPI could offer a more intuitive, visual, and interactive way for users to search and visualize data available through eoAPI.

Considerations

While STAC-Browser and eoAPI share standard technologies, integrating them might have complexities. To ensure seamless functionality, it may require modifications in either the eoAPI code or in the STAC-Browser itself.

@vincentsarago , your insights on the specifics of integration would be much appreciated. Would you provide more details on what we might need to consider or change to integrate STAC-Browser successfully with eoAPI? Feel free to modify this initial ticket.

Next Steps

Once we better understand the potential hurdles and requirements, we can create a detailed plan for implementation. This plan should also include necessary testing to ensure the integration does not introduce bugs or adversely affect performance.

[zacharyDez]

@heidimok , here is the related issue on the demonstration application. We may want to revisit whether to use STAC Browser or design our front-end application tool, given our experience.

Here are some examples we could lean on:

• @vincentsarago started a demonstration application directly within eoAPI
• @oliverroick has worked on planet-stac
• @sharkinsspatial has worked on sat-api-browser

Starting from a UX perspective might provide a different outlet for future development.

[heidimok]

@zacharyDez as a way to move away from Slack threads, I created a document for design planning purposes. I hope we can build on this to clarity goals and expectations around the eoAPI demo app.

https://docs.google.com/presentation/d/1n6ePLpgAFVEzH6t_svHCCHO-_qvXqjq1wrMR98vfp2Y/edit#slide=id.g226d712019f_2_206

[sharkinsspatial]

@oliverroick I 👂 your concerns about building and maintaining components. One of my original thoughts for this effort was the idea of an interface that would be self-configuring based on the results of an initial "capabilities" query to the queryables endpoint of the STAC API.

STAC is extremely flexible (and items essentially schema-less) which makes it difficult for users to determine how they can create queries to filter a large collection.

My idea was a set of filter components (range slider, time selector, dropdown selector, etc) that would make filter generation easy for users. Conceptually it would work like this

1. A user could select an endpoint or collection which would advertise the properties and their datatype which can be used in a filter expression.
2. Let's say that the selected collection advertises eo:cloud_cover as one of its queryables.

   "properties": {
       "eo:cloud_cover": {
         "title": "Cloud Cover",
         "type": "number",
         "minimum": 0,
         "maximum": 100
       }

3. The filter component would then "self-configure" a slider component with the range 0-100.

Because the advertised queryables completely change depending on the collection or endpoint. It would be great if users could have this dynamically changing interface that is configured dynamically in relation to the endpoint being used.

MS Planetary Computer is doing this to a somewhat less flexible degree.

Does that make sense? The demonstration components in stac-react are filtering using only the required properties that are common to all STAC items. The hard problem is configuring the interface for all the non-standard properties.

[oliverroick]

@sharkinsspatial I totally agree. It's worthwhile to simplify filter generation based on queryables. I think there can be a middle ground by providing the configuration for components but not the components itself.

Image something along the lines of:

function CloudcoverSlider() {
  const sliderParams = useQueryableFilter("eo:cloud_cover");

  return <input {...sliderParams}>
}

where sliderParams is an object that looks like this:

{
  min: 0,
  max: 100,
  type: "range",
  onChange: () => {}
}

That way we abstract away the complexity of parsing queryables, generating component props, and handle value changes and query construction. And developers have full control of the rest of their component.

[zacharyDez]

Closing in favour of a more general approach discussed here: https://github.com/developmentseed/eoAPI/issues/117

[emileten]

Although we're developing a custom approach, we agreed that it would be great to also offer support for the Radiant Earth STAC browser, so I am reopening this ticket and marked it as 'in progress' on the board. I have a PR ready that integrates it to eoapi-cdk. cc @zacharyDez

[emileten]

https://github.com/developmentseed/eoapi-cdk/releases/tag/v5.3.0

[zacharyDez]

Nice!!! Will try early next week, and build a short demo!

[vincentsarago]

@zacharyDez we still need https://github.com/developmentseed/eoapi-cdk/pull/66 before we can bring eoapi-cdk here

[zacharyDez]

@vincentsarago; it seems like it was effectively merged to main. What else remains?

[emileten]

We need to integrate eoAPI-cdk here, I believe that's the next step. I can submit a PR for that next Monday :)

[emileten]

With a (little bit 😄) of delay, here is the deployed URL of the browser that allows one to explore the demo catalog : http://eoapi-dev-stac-browser.s3-website-us-east-1.amazonaws.com/?.language=en !

[vincentsarago]

🤯

[vincentsarago]

@emileten I'm seeing that the raster request are still going through radiant earth tiler, maybe we could use eoapi.raster if deployed in the stack !

[emileten]

🤯 nice flag thanks !