You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like there are some required fields/attributes which we could definitely ensure are present in our database. Using Sentinel-1 (a SAR satellite) as an example, frequency_band is required, and there's a list of Common Frequency Band Names to select from. See their example sentinel-1.json vs our current Sentinel-1.json
The text was updated successfully, but these errors were encountered:
Their sentinel-1.json looks super nice! I also not the use of general data set info (such as version number) as fields in all json files. We could/should also include this, can do it automatically when we have a new release! Again, in a goal of traceability, especially if users make local and static copies of the data base!
Also worth noting that our json files have been automatically created from a spreadsheet in a dummy way, only for testing purposes at the moment and without any other modification/improvement (just to explain why they look so ugly!)
Just got some great ideas after attending this Cloud-Native Geospatial Event (https://schedule.cloudnativegeo.org) and learned a lot about Spatial Temporal Asset Catalogs (STAC) and OGC API standards! So the people working on those standards have literarlly spent years thinking about metadata, and these are some relevant ones that popped up from scanning through https://github.com/stac-extensions/stac-extensions.github.io:
It seems like there are some required fields/attributes which we could definitely ensure are present in our database. Using Sentinel-1 (a SAR satellite) as an example,
frequency_band
is required, and there's a list of Common Frequency Band Names to select from. See their example sentinel-1.json vs our current Sentinel-1.jsonThe text was updated successfully, but these errors were encountered: