Move collection level properties to a collectionProperties field.

[sharkinsspatial]

In order to enforce separation of collection and item level properties, we can place all of the collection level properties in a collectionProperties key for each item rather than directly in the item's properties. This will require a modification to the query logic where both values are checked but this should be fairly trivial. In addition I can implement a field exclusion where the collectionProperties are not returned for the item making them invisible to the end user.

[matthewhanson]

I looked into alternate ways of doing this more native to Elasticsearch (indexing fields but making them hidden on retrieval), but there doesn't seem to be any way of doing this. The closest is: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html#request-body-search-source-filtering

but _source is defined for an index, and we use a single index for all the collections..and the fields which are returned vary by collection.

So @sharkinsspatial's approach seems to be the best approach. There are a couple changes that would be needed:

• on ingest check which fields are in a collection and move them to a collectionProperties field
• on search, search for all provided query parameters against the collectionProperties as well as properties.

This is a more than a simple change. However without it, there is little impact to functionality. The Collection metadata will still indicate which fields are constant in member Items, it's just that clients receive redundant data.

I'm moving this to a future feature, it's not really necessary.

[matthewhanson]

Discussed in last STAC sprint and decided that dynamic APIs should return complete Items with all the properties from Item and Collection. So I think the way sat-api does this is fine, closing.