Support additional parameters in Item Search?

[drwelby]

Any harm in allowing additional search parameters in the ItemSearch init that could get tacked onto the request URL as params? For example, let's say a STAC endpoint accepts an optional units=m|ft to send back metadata fields in a given measurement system.

These parameters could be captured as **kwargs or be more explicitly passed as something like params={}. I'm happy to PR the change but wanted to get some opinions first.

[gadomski]

Any harm in allowing additional search parameters in the ItemSearch init that could get tacked onto the request URL as params?

I don't have a specific reason to not allow this, though I do have hesitancy around **kwargs usage generally because it often leads to a messy user experience. If the additional parameters had an defined extension that we could reference and add as proper arguments, that might be a better interface (see this discussion for some discussion around a similar topic).

[drwelby]

I hear you on **kwargs.

I might be overthinking this, though. Since these sort of params are more "server options" could I just tack that param onto the URL when I open the catalog? client.open("https://my.stac.api/search?units=ft") would probably be good enough to enable "I want all my STAC metadata results to be in feet".

[drwelby]

Playing around these "server options", they seem to be falling into stacIO's domain so I'm going to close this for now.