Multi platforms

[rhysrevans3]

Related Issue(s): #1348

Proposed Changes:

1. Update common metadata Platform type to allow string or array of strings.

PR Checklist:

• This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
• This PR has no breaking changes.
• I have added my changes to the CHANGELOG
  or a CHANGELOG entry is not required.
• This PR affects the STAC API spec,
  and I have opened issue/PR #XXX to track the change.

[m-mohr]

This is intenional. The intention is that in this case, you'd not provide a platform (as it's a derived product) and point back to the source STAC files so that you can get the information from there.

With the same reason you could allow arrays for pretty much any field, which makes the whole metadata model very weak.

So -1 on this one.

[alexgleith]

Sounds sensible to me.

[gadomski]

Yeah, I'm 👎🏼 on union types for core attributes like this because it makes more work for implementers to handle both cases.

That being said, I always felt as through it was relatively arbitrary that instruments was a list but platform wasn't. This feels like a very satellite-specific detail leaking into the core specification. To me all of those values (platform, instruments, constellation, and mission) feel better suited to an extension.

[jsignell]

It would be helpful to know more about the proposed use for this change. Is the idea that this would be useful for STAC items that are higher level composites from multiple platforms? Update: I read the linked issue.

I tend to agree with @gadomski that these fields are all very satellite specific and should maybe be added to https://github.com/stac-extensions/sat.

[rhysrevans3]

Thanks all for the comments. I agree with @gadomski I was a bit surprised to find these fields in the core and agree they would be better suited to an extension. Also agree with the distinction between Instruments and Platforms being a bit arbitrary. The reason I chose union of list and str for platform was to try to allow for backwards compatibility. Would updating it to just a list of string like instrument be more acceptable?

[m-mohr]

Actually, the fields were initially in the sat extension, but at some point it was decided that they seem pretty stable and core so they were moved over to common metadata just before 1.0, I think. I'm not 100% anymore what the reasons were to move them, but I don't think it's a good idea to move them to sat again because it bereaks a lot of implementations (it would get the sat: prefix). So I think we should keep them here until we go for a 2.0 or so.

Whether they are in sat or here doesn't really solve the issue though. @rhysrevans3 What do you think about omitting the platform property and insted pointing back to the source metadata where the platform is listed? Alternatively, there would also be a way to use platform in assets if it's an asset specific field. Platform can also be used in collections if that helps. Just thinking out loud about some ideas that could help you without breaking the specification. Even if we'd merge this, this would likely only be available in STAC 2.0 which is a long way ahead so would not be a quick solution for you anyway.

[rhysrevans3]

From the changelog it looks like it was added to common because it was in multiple extensions eo & sar.

Agree moving to an extension doesn't solve this problem. I've created a separate issue for that as I think it's worth discussion even if it is for v2.0 #1350

The reason for my reluctance in just excluding the platform property is how it effects search. Those records wouldn't be returned when a user searches for a specific platform. Including it in the assets might work but I don't think any asset fields are include in search at least not currently for the Elasticsearch backed API.

Our current work around is just to use a platforms property but this still effects the search.

[m-mohr]

What kind of product would this be for?

If I search for Sentinel-2 and there's a product that's a fusion of Sentinel-2 and Sentinel-1, I think I wouldn't want that fused product in the search results... Thus omitting that platform makes sense to me. It's a new product, not an acqusition of the platform. But that's probably just one of many examples.

[rhysrevans3]

I believe this is for level 4 above ground biomass data. I'm just a developer though so an not an expert on the data but can forward any questions to one of our data scientists if you have any.

For my education is just convention that a product is per platform or is there a deeper reason? To someone who doesn't work with this data it seems the same logic could be used to say if I search for a specific instrument I don't want products with more than multiple instruments in them?

[m-mohr]

The reasoning back in the days was (as far as I remember) that a platform could have multiple instruments so that's why instruments is an array.

If you have data that originates from mutliple platforms, you usually have some source data (i.e.lower levels than L4) which you could point to. Otherwise, you try to keep items and collections as homogeneous as possible, I think.

[strobpr]

The reasoning back in the days was (as far as I remember) that a platform could have multiple instruments so that's why instruments is an array.

If you have data that originates from mutliple platforms, you usually have some source data (i.e.lower levels than L4) which you could point to. Otherwise, you try to keep items and collections as homogeneous as possible, I think.

I believe what you discuss here is extremely relevant for findability and traceability in EO (or more generically 'geospatial') data catalogues. Whenever these catalogues contain data which are or go back to observations, the sensor involved is of interest. While at lower (more sensor-centric) processing levels the knowledge of the exact device used for acquisition is crucial, at higher (target- or application-centric) levels the importance fades, and maybe only the type of instrument should be kept. For this reason different details of sensor related metadata should be stored with the data.

What regards the scalar vs array of each of them in an asset or item, I don't think it is wise to privilege multi-sensor platforms over multi-platform sensors or to limit the way assets can be configured. That is a strange idea of 'homogeneity'. Complex datasets which are pretty homogeneous in their content are not only imaginable at higher levels! Already now Level-2 composites of S2A and S2B are quite common. At higher levels (3&4) multi-platform or -mission datasets will be the rule. To identify which technology they are based on no one will want to back-trace to Level-2 or even lower level data (although this should remain possible). Not being able to represent the technology used in the best possible way is quite a limitation for a metadata specification.

BTW instrument, platform, constellation, and mission are only satellite specific if you define them to be so. Any observation, regardless whether remote or in-situ, space- air- seaborne, or ground based, must have an observer or sensor (a specific version of what you call 'instrument'), most of them will have a platform (can't think of one who doesn't), and probably also mission or campaign (which to me are different things btw). You would be very well advised to keep these attributes generic so that they can be used across the whole domain, that is what boosts interoperability!