Jazzing around STAC

[betolink]

Stac stac stac! (maybe we say it 3 times earthaccess will understand it) For the upcoming hack-day I've been thinking of what points would be interesting to explore.

• Stac query interoperability: earthaccess uses python-cmr to query CMR, should we enhance python-cmr to understand STAC? Use case: we can use earthaccess with STAC parameters and will get translated into CMR, then the reverse, with perhaps pystac_client executing the query.

• Data serialization interoperability: CMR provides STAC serialization but this is not the preferred or performant way of getting results back from CMR, we may need to implement a results class that can do this serialization on the fly!

  results  = ea.search_data(**params) 
  stac_items = results.to_stac()

  This will allow us to use STAC compatible tooling with CMR results!

• Cloud native STAC: usually we query STAC API servers, it would be interesting to explore the possibility to have rustic-py as another engine to fire the STAC queries and the advantage of this is that the catalog can be a simple geoparquet file! No backend needed!

• STAC catalog library: this is not necessarily for the hackday but it would be nice if we had a tool as simple to use like earthaccess but that it will to the opposite, it will help scientist create catalogs, I’ve been “vibe coding” something that we used for a project called ITS_LIVE and could be interesting to explore. Some info here:

  • https://developmentseed.org/blog/2025-05-07-stac-geoparquet/
  • https://www.gadom.ski/presentations/2025-11-04-stac-geoparquet.html

I think having the first 2 points clear and creating issues, perhaps using AI to do some prototyping would be great! The goal is to get us familiarized with the STAC ecosystem and how we can enable earthaccess to be as interoperable as possible without overengineering the library.

I'll post related issues or we can thinker around in this discussion.