Closed mhungen closed 2 years ago
Thanks for the report. Here's the output I see
In particular, note the subsequence [89.252603, 9.008443, 94.83971]
. It almost looks like we're sorting a stringified version of the value. @mmcfarland, do you think this is more likely a bug in pgstac's sorting, or a bug in how we're loading the data?
Yes, thanks for the report. I've been able to track this down to a bug in pgstac which is incorrectly casting the provided sort field to text within the generated sql order by
clause. Looking into a fix now and will provide a link to the issue when I file it on the upstream repo.
FYI, upstream issue is at https://github.com/stac-utils/pgstac/issues/134. It's not specifically a sort issue, but some inconsistencies in schema definition can result in this type of behavior for search or sort. Note that this area of pgstac is under active development: https://github.com/stac-utils/pgstac/pull/133.
As you can see in the issue, omitting the properties.
in the sort field definition should return the correct result if you're looking for an immediate workaround, but the syntax you have is valid and we'll get that fixed.
This is fixed upstream. Closing.
When trying to sort an item search by "eo:cloud_cover", I receive a list that is only partly ordered.
For example, the following query contains an element that does not match the expected result: search via GET
result:
result as textfile