Proposed static spec

[jeffnaus]

I don't expect this to be accepted as is, I'm opening this PR to generate discussion

Two general things I did:
I named the spec the "spatiotemporial_feature" to differentiate our elaborated feature from the generic geojson feature.
I also named my timestamp fields "startDateTime" and "endDateTime". There are a lot of minor differences between "start_time", "start_date" and various other forms. So I figured I'd just try to throw down a standard we can all start using.

I also included examples of features for some of our DG datasets which shows how I am thinking currently. I'll updates as the discussion evolves.

[cholmes]

Hey Jeff, apologies it took some time to review this. There's a lot I like there. I'll put some questions in on individual files.

I like the concept of the 'acquisition', as the parent of the other two. Am I right in understanding that DG wouldn't ever make the files of the acquisition accessible to users, but that it's the root set of information that all the products are made from?

The one bigger concept I'm curious about your take on is whether we should try to streamline repeating information. Like having the band information in every record seems like a lot - could we just link to the WORLDVIEW02 platform name and have it contain the band information. And then hopefully clients could start to recognize the link and know they don't need to resolve it each time.

Or maybe we even just start to have the notion of a non-repeating end point, where we link to the 'sensor' resource. I like how http://jsonapi.org/ does it in an active API, where the sub-resources always have a link to their independent representation.

I like the notion of defining a spatiotemporal feature, and validating the schema against it. The thing it brings up for me is how we make it clear which fields are the spatiotemporal feature fields, and which ones are added on by a vendor. I think ideally we define the core pretty narrowly but have lots of flexibility for providers to put a lot more data in. Though I think we may want to get to some best practice recommendations, like do we tell people to just reference all their side metadata, or to put it all into JSON. And if they put it all into JSON do they try to flatten it, or just use nested structures like in the NAIP 'source metadata' - https://github.com/radiantearth/stac-spec/blob/feature/add-flat-file-spec/spec/json/examples/naip-item.json

[cholmes]

Various comments on different lines of the PR

[cholmes]

Is the idea in the feature_type that the above feature_type's would all have schemas that fields in this record would validate against? Or is it just meant to be informative in some way?

[jeffnaus]

That list is more because that is how our current catalog "tags" the records, so that you can search for and find all WV02 related records (not just acquisitions) for instance. There is a singular type, DigitialGlobeAcquisition that this record would validate against.

[cholmes]

Is this supposed to be feature_type ? The other two use that term. Or I'm missing some subtlety as to why this is different.

[jeffnaus]

Yes, I wasn't sure what we finally decided on for the name of the field. Schema, type, product.....

[cholmes]

Would these link to a real location? Or are they just supposed to unique references? Like in a production version would this be a real url that a user (with appropriate rights) would follow?

[jeffnaus]

Yeah, they would link to actual URLs. I just truncated this example.

[cholmes]

I like this, I feel like it'd be good to have some 'best practice' relation links that map out the structures of imagery.

[jeffnaus]

And that relationship would link back to the acquisition catalog record.