Add stacrs as an optional dependency to search stac-geoparquet

[gadomski]

stacrs is a no-dependency Python package that added the ability to search stac-geoparquet in v0.1.3. We could add stacrs as an optional dependency of pystac-client to enable searching stac-geoparquet files.

This was discussed here: stac-utils/rustac#462

Note

I am the author of stacrs so I have some bias.

[jsignell]

I like that idea a lot. This feels like the current best practice for querying a static catalog #563

[jsignell]

Do you have a sense of what the API should look like for this?

I think the options are either:

1. expose a top-level search function and establish a non-client based access pattern
   • con: now there are 2 ways to do search in pystac-client
   • pro: less setup to do for the simple scenario of an uncomplicated STAC endpoint
2. implement a client-like class for interacting with stacrs
   • I think this would work better if Use stacrs to read+write stac-geoparquet pystac#1455 happened first

[gadomski]

implement a client-like class for interacting with stacrs

I think my vision is things to be as transparent as possible for users — same code could be used to hit an API or hit a stac-geoparquet. So I think option (2), and agreed that the pystac ticket should probably go first.