Matthew Hanson

The language may have been updated, I've generally used the advice given in https://macwright.com/2015/03/23/geojson-second-bite.html#multi-geometries but granted that's a bit old now. GeometryCollections historically have not been well supported by tooling,...

I think in the markdown we can still reference the RFC, but state that GeometryCollection is not supported, which is enforced by the schema.

This sounds like it might be the beginning of a sensor extension that includes some other fields around radiometric accuracy perhaps (and some other fields we see in CARD4L).

Sentinel has a JSON equivalent that is in the tileInfo.json file, e.g. https://sentinel-s2-l1c.s3.amazonaws.com/tiles/1/C/DQ/2018/1/19/0/tileInfo.json The sat-api example in that repo @cholmes is landsat and contains all the regular Landsat fields, but...

@mojodna a few things - We discussed having object fields but decided to keep things simple originally and currently we don't have any fields that are objects under properties, which...

Same thing with DG, you can't directly download initially, but after you order it you can download it. I've implemented this for DG as STAC item that gets updated locally...

My own thinking on this has changed after working with GBDX. There are likely to be even more platforms in the future where assets aren't directly downloadable but require API...

+1

@mojodna as you and I talked about, start_datetime and end_datetime (no mixing camelcase in!) applies to a lot of data, even the EO profile and maybe deserves being made either...

@mojodna Most of these fields look to me like they could apply to any EO data - for example NODATA and gain/offset values. This is actually a problem right now...