stac-spec
stac-spec copied to clipboard
radiantearth
Acquire samples of product metadata and show its mappings to the spec
One of challenges of creating a common metadata schema is that we lack the whole picture.
It would be beneficial to reach out to DG, Planet, and other providers for samples of their metadata with a license that allows it to be stored in this repository.
Once acquired, we could keep the a mapping of the "EO" profile to actual metadata. And when a Pull Request changes the EO profile, reviewers can the see consequences in the mapping.
Essentially, showing in addition to describing.
I took a crack at this in https://github.com/radiantearth/catalog-implementor-survey/tree/master/json-metadata
Could probably use an update. And should get landsat / sentinel in there in some form (landsat has a json equivalent, not sure if sentinel does but probably?)
I most just grabbed those from the public facing API's I had access to.
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 in JSON (and with extra fields). The actual original Landsat metadata is in the MTL file, and is not JSON but is a Planetary Data System (PDS) file written in ODL: http://landsat-pds.s3.amazonaws.com/L8/011/029/LC80110292016012LGN00/LC80110292016012LGN00_MTL.txt
I think it would be good to roll up these examples into this repo with examples of the original provider metadata along with a mapping. I'll include it in a PR for the EO extension, I think it makes sense to keep examples for EO along with the EO extension.
My one worry with rolling it up to this repo is the burden of maintaining all the examples and mappings on the same pace as the core spec. I actually removed some on the update in progress, since we changed a lot.
I think if we get to more stability and perhaps some automated way to create the samples from a smaller number of mappings it could make good sense.
I agree that ideally the samples are converted automatically. If there's still too much flux to make automation worthwhile then we could revisit this later when it makes more sense.
I can try tackling the automation part once you've a source document / destination output and the eo PR goes through.
The implementation of #135 could help, but I'm not quite sure how this should work automatically. There are so many extensions and examples nowadays that an automated conversion seems useful, but hard to implement.
