Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acquire samples of product metadata and show its mappings to the spec #68

Closed
osialr opened this issue Mar 15, 2018 · 6 comments
Closed

Comments

@osialr
Copy link
Collaborator

osialr commented Mar 15, 2018

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.

@cholmes
Copy link
Contributor

cholmes commented Mar 15, 2018

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.

@matthewhanson
Copy link
Collaborator

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.

@cholmes
Copy link
Contributor

cholmes commented Mar 30, 2018

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.

@osialr
Copy link
Collaborator Author

osialr commented Mar 30, 2018

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.

@m-mohr
Copy link
Collaborator

m-mohr commented Jul 18, 2019

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.

@PowerChell
Copy link

Closing out old issues -- many examples available now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants