Proposal: Modify ssys:targets to be a single string

[jlaura]

Right now, we have this strange situation where time is a single string and ssys:targets is an array. What does the time refer to? The first entry in the array? All of the entries in the array? ssys:target_class has the same issue.

Additionally, having multiple entries in the targets does not make sense. For example, the STAC item defines a geometry (footprint in lat/lon). What target is that footprint referencing? Is it the first in the array? Is it all of them (because both bodies are full disk; this is not the reality of the data acquisition.)? Same with any of the eo or view extension parameters. A STAC item is referencing one spatiotemporal entity and multiple bodies in the same item breaks that assumption.

Then, thinking about how a user might want to discover data, a few scenarios come to mind (using Mars and Phobos as an example here):

• The user wants to find data for Mars or Phobos. If the collection is a mix of Mars and Phobos data, because the sensor platform is the same, they are going to query for ssys:targets contains their target of choice. It is more efficient to generate two metadata files, one where the target is Mars and another, pointing at the same data, where the target is Phobos.
• If a user wants to see Phobos images that also contain views of Mars, they can and should query across two collections (a HiRISE Mars collection and a HiRISE Phobos collection, for example). The burden is then on the data provider to partition into different collections.

So, data discovery is absolutely feasible for users that wish to see these unique, two plus target images.

I would move to update the ssys extension to contain a single target and then write some documentation to describe what a data provider should do for data with multiple targets.

[J-Christophe]

I agree with you about collections (1 STAC collection = 1 SSYS target). On the other hand, if we're talking about STAC CATALOG (no geographical/temporal keys are required), I think it's interesting to have a SSYS array.

If I take the example about Mars/Phobos, I image I will create :

STAC catalog (ssys:targets : ['Mars','Phobos'])
|__ STAC collection (ssys:target: 'Mars')
| |__ items ...
|__ STAC collection (ssys:target: 'Phobos')

In this way, when the user is connected to the catalog, he knows the childrens of the STAC catalog are about Mars and Phobos

To resume, I would imagine this :

• ssys:targets is an array for catalogs
• ssys:target is a value for a collection/item

[jlaura]

Thanks for the input! I do not believe there is any provision for having different data types on keys for different hierarchal levels of STAC. Can you find any other examples?

Having said that, I don't think that they are explicitly needed! The summaries fields can provide an array of all unique values at the collection level. So, one could have a single target per item and then the collection summary would be an array of unique values. The ssys:targets field would go to a single string representing the target, an observations with more than one target would necessitate more than one STAC item, and then, if that observation were included multiple times in a collection (with different targets, geometries, bboxes, etc.), the summaries on the collection would include "ssys:targets":[target_a, target_b, ..., target_z].

Summaries do not exist at the Catalog level. So the above example could be reformed as something like:

STAC catalog (Descriptive title)
|__ STAC collection (ssys:target:['Mars', 'Phobos'])
| |__ item 1 (ssys:target: Mars ) # Observation id 1234
| |__ Item 2 (ssys:target: Phobos) # Observation id 1234
| |___ Item 3 (ssys:target: Mars) # Observation id 2345
| |___ Item 4 (ssys:target: Mars) # Observation id 3456

Thoughts?

[J-Christophe]

As you said, the basic problem is that we can't define other keywords in the extension as long as targets is an array without defining something inconsistent. So we have to define a class with our keywords and make target mandatory and the others optional.

class ssys:
target : str
otherkeyword: Optional[Any]

At each STAC item, we need to link the item with one ssys object

For my application, I need to have the body name at the different STAC elements (catalog, collection, item) even if the body name is an array. In the array case, I select for the user the first element of the array as default and I show the background map.

A collection is a particular catalog. So if we have a ssys defined at the catalog level, it is strange to have not defined as the collection level. Summaries is not always implemented (only recommended in the spec) for a dynamic STAC API due to computation constraints.

We could do that :

For STAC item :
I think we agree : target (without s) as a string, and other keywords

For STAC collection:
targets as an array

For STAC catalog
targets as an array

NB :
In your example, you talk about Observation Id. Your example is right only if stac ID is different of an observation ID because the ID must be unique within the collection. So maybe, we can add an observation id in the ssys extension

[jlaura]

Good catch on the observation IDs! Those most definitely need to be made unique.

Looking at other extensions, I do see where they are using the schema to define different properties depending upon the stac item, catalog, or collection. One example.

And yes, I agree on the item, collection, catalog that you listed above. The good news, is that I do not think that that will be a 2.0 breaking change because the ssys:targets (plural) will be maintained at the collection level. It will be added then to the catalog. I'll have to check stac-browser to see if that code is parsing the ssys:targets array at the item level or not. If it is, then this is a breaking (2.0, or maybe we are still beta, I dunno!) change.