Hi all. I am creating a tool to upload some historic aerial imageries with the STAC format. There are a lot of fields that are specific to historic imagery like film, film_sequence_number, whether the imagery is black & white or RGB, physical_film_condition, etc. There are also some specific to aerial imageries like altitude, nominal_focal_length, photocentre_latitude, photocentre_longitude, etc. What is the best way to put these data in the Properties Object?
@Ben-Cheng - that's awesome! So the simplest thing you can do is just add those as custom fields, and ideally put them in a schema, with your own prefix. But given your description it'd be great if you wanted to put them into 2 extensions (aerial & historic imagery), that you could contribute as a STAC extension - https://github.com/radiantearth/stac-spec/tree/master/extensions
This would enable others to align on the same field names. We have talked a few times about aerial, and that would be a great one to have, but no one has gotten to write it up (and none of the core STAC team knows aerial well enough to do it ourselves). And historic images would be great too.
If you want to try to make pull requests and contribute directly to the spec that'd be awesome. But I'd love to see both of those, so if you just made a couple issues that wrote up all the fields and what they are used for I'd be happy to help draft the actual extensions.
@cholmes Thanks for the feedback!
Quick piece of background, we are in the process of creating a backup archive of about 110TB of historical aerial imagery and we are looking to store STAC metadata with it.
So I think for now we are looking to start using STAC internally until we can use it in anger for a bit to make sure it meets our needs then we could look at contributing it back as a STAC extension, Even if we have to go and remap all our fields we only have about 1M files so shouldn't take too long!
We will clean up some of our internal docs on what fields we have and where we are planning on storing them.
Another question: namespaces, Land Information New Zealand (LINZ) does a lot more than just historical imagery, we are thinking that our linz: namespace might get quite polluted do you have any thoughts about subname spaces
Some possibilities we are thinking of linz_aerial: linz:aerial or even sub sub namespaces linz:imagery:aerial
I had not thought about sub names. But I think linz_aerial: or linz_imagery_aerial: would make the most sense to me - keep the ':' to separate the prefix from the main thing. Though prefixes are just a convention.
You also could just use aerial: directly for the ones you think will have wider applicability. Then you wouldn't have to change them if it evolved to a STAC extension. You just have some risk if someone else contributes an extension with same prefix but different semantics (but can mitigate that risk by just paying attention to the community and reaching out to align when someone does).
Just put a few PR's up on stac-api-spec - trying to make a push for 1.0.0-beta.1 on it. Reviews appreciated https://github.com/radiantearth/stac-api-spec/pulls
Also would appreciate feedback on radiantearth/stac-api-spec#27 as it seems like we should get something in place to get api verisons
Ah... collection. "This fields - together with created and updated - also seem relevant for STAC Collections and may be adopted there, too" so item only right now
Yeah, so you can add them, but don't add "timestamps" to "stac_extensions" and the validator won't complain and it won't check them
I’m on v0.9.0 and don’t use the time stamp extension
so:
"summaries": {
"created": ["2020-01-01T00:00:00Z"]
}
@p1d1d1_twitter - is the updated / created at a collection level a reflection of the created/updated of the items below? If yes then summaries is definitely where it'd make sense. But if you want to communicate about when the collection itself was created / updated independent of the items in it then it could be a top level custom extension like @m-mohr says.
Actually, it looks like https://github.com/radiantearth/stac-spec/tree/master/extensions/timestamps would be a logical place. So you could just make a PR there that explains applyin created/updated to the collection level.
@cholmes Hmm, looking at https://github.com/radiantearth/stac-spec/tree/master/extensions/timestamps I just realized none of our fields is suitable. We only have datetime files for the data, not the metadata. So if @p1d1d1_twitter wants to say something about the data, it's summaries with the fields available. If it's about metadata creation etc we don't even have fields for metadata and I'd propose to add fields about the metadata in the timestamps extension, aligned with what we have for the data, e.g. stac_created, stac_updated, stac_expires and so on..
@p1d1d1_twitter: For me it's not clear what you mean with " the when of the collection itself". A collection is something virtual for me... You either have data or the metadata. What is it that you want to describe? creation of the collection metadata, item metadata or item/assets? With my proposal above it would be
@p1d1d1_twitter: For me it's not clear what you mean with " the when of the collection itself". A collection is something virtual for me... You either have data or the metadata. What is it that you want to describe? creation of the collection metadata, item metadata or item/assets? With my proposal above it would be
- creation of the collection metadata: stac_created top-level at the collection
- creation of the item metadata: stac_created in summaries
- creaton of the item/assets: created in summaries
@m-mohr I'm currently working with v0.9.0, not with static files but with an API according to https://github.com/radiantearth/stac-spec/tree/v0.9.0/api-spec.
@m-mohr ... I've seen that in current master you "dramatically" changed the semantic of "created" and "updated", where you say that these are date and time of the corresponding data while in v0.9.0 you say "creation date and time of the metadata file". It is exactly in this sense that I want to use these attributes ad collection level: I think that "at top level of the collection" is the right location for them. IMHO "datetime" is the right property to say something about the "when" of the actual data.
@m-mohr - the fields are for the metadata if they are in properties: "created and updated have different meaning depending on where they are used. If those fields are available in the Item properties, it's referencing to the creation and update times of the metadata. Having those fields in the Item assets refers to the creation and update times of the actual data linked to in the Asset Object."
I think having stac_ for everything is a bit much. But I'm for something at the collection level. Ok with me if that's stac_created, or created, or collection_created.
My hope is that records API will publish a set of 'core fields' that are what you search on to find collections, and that serve as additional metadata fields to add at the collection level.
@cholmes The current but not yet final list of core queryables is here: https://htmlpreview.github.io/?https://github.com/opengeospatial/ogcapi-records/blob/master/20-004.html#_response_6. Should all be settled by the end of the month, though, when we plan to release the first reviewable draft of the specification.