Replies: 3 comments 8 replies
-
|
Does a server need to advertise this? I had been thinking in the case of a server that already does it, there's no action (i.e. pgstac) but in the case of a server that doesn't do it, a client library should be able to take a Or are you saying the user when making an API request should be able to control wether or not item records are hyrdated from collection record data. PS: the use case we've been discussing internally is the Classification extension which can be very verbose for a lot of categories. https://planetarycomputer.microsoft.com/api/stac/v1/collections/usgs-lcmap-conus-v13/items/LCMAP_CU_032003_2021_V13_CCDC |
Beta Was this translation helpful? Give feedback.
-
|
Is the only advantage that the response payload is potentially smaller? It feels like a lot of added complexity for a debatable benefit IMHO. This also reminds me of the Commons Extension in STAC back in STAC 0.x, which we abandoned at some point for probably good reasons (which I can't fully remember, but I guess it felt too complex for the added benefit). |
Beta Was this translation helpful? Give feedback.
-
|
Does the STAC 1.1 inheritance model not do away with the need for hydration at least conceptually? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Items can contain a lot of duplicate information. pgstac has the concept of hydration where repeated information is removed from Items and stored in the item assets on a Collection. Now that item assets are "first class" as of STAC v1.1, I think it's time to explore "client side hydration", where items are returned from a STAC API "deydrated" and then hydrated by the client. We've pulled out the (Rust backed) https://github.com/developmentseed/hydraters/ from pgstac with this in mind.
As I see it, there's a couple of things we'd need to do to proof this out:
Beta Was this translation helpful? Give feedback.
All reactions