Skip to content
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

Dynamic queryables #209

Open
emmanuelmathot opened this issue Sep 5, 2023 · 3 comments
Open

Dynamic queryables #209

emmanuelmathot opened this issue Sep 5, 2023 · 3 comments

Comments

@emmanuelmathot
Copy link

Is there already any stored function that would update the queryables table with the actual possible values from items or from collection summaries? We already use pgstac.missing_queryables() as described in https://stac-utils.github.io/pgstac/pgstac/#queryable-metadata but it seems to extract the definition from the extension json.
Thx.

@bitner
Copy link
Collaborator

bitner commented Sep 6, 2023

@emmanuelmathot the missing_queryables function will load a sample of data rows (controlled by the table sample argument which is an approximate percent of rows to look at). For any property names that exist in the loaded extensions, it will get the definition from there. If the property does not exist in any extension json, it will just make a very basic definition based on the json type of the property.

@emmanuelmathot
Copy link
Author

Yes indeed, that is what I understood by using and reviewing the function code.
My question was about a potential function or stored procedure in either pgstac or pypgstac that would generate the definitions based on the actual possible values from the items. Especially for the enums.
For instance, the sat:orbit_state field from the sat extension defines the following possible values : ascending, descending, geostationary. If the collection only has items with ascending and descending, this function would generate an enum with only those values.

@bitner
Copy link
Collaborator

bitner commented Sep 7, 2023

It is definitely possible to do this from a sample of rows, but, in this case, where the choices are defined by an extension, it would be better (I think) to add the sat extension json into the stac_extensions table. If it is there, the missing_queryables function should pick up the enum along with any other specific definitions directly from the extension definition.

Anything we would do to auto-create enums would either take a full table scan which could be very very slow or when only using a sample of rows, there is always the possibility that the enum would be missing some values.

I'm certainly open to a PR that adds this in, but it is probably not going to be something high on my priority list to work on.

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

No branches or pull requests

2 participants