feat: Tweak geospatial type implementation #172
Conversation
l0b0
force-pushed
the
feat/tweak-geospatial-type-implementation
branch
from
8cda80b to
8301f9a
Compare
l0b0
force-pushed
the
feat/tweak-geospatial-type-implementation
branch
from
0b88154 to
54e6cb9
Compare
| | processing:software | Map<string, string> | Recommended. The software and versions which were used to generate the dataset. See [reference](https://github.com/stac-extensions/processing). | | ||
| | Field Name | Type | Description | | ||
| | ------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | processing:software | Map<string, string> | Recommended. The software and versions which were used to generate the dataset. See [reference](https://github.com/stac-extensions/processing). | |
There was a problem hiding this comment.
This is an Item Properties thing too. https://github.com/stac-extensions/processing#item-properties-and-collection-provider-fields
extensions/linz/README.md
Outdated
| | Field Name | Type | Description | | ||
| | ---------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ||
| | title | string | **REQUIRED**. Collection title. | | ||
| | linz:geospatial_type | \[string] | **REQUIRED**. A general description of the type of content that can be found in the dataset. See the [list of accepted geospatial types](#geospatial-types). | |
There was a problem hiding this comment.
I can't think of a dataset / collection that we hold that would need to be categorised by multiple geospatial types, I guess because we tend to divide datasets / collections based on their "geospatial type". If a summary of all of the geospatial types of the items within the collection is required, then that would seem better implemented as item properties + summaries, but I see this more as a general categorisation which just has one geospatial type.
There was a problem hiding this comment.
That's a good point, and it sounds like the documentation cleanup is working if it highlights deficiencies 😁. Do you want to create a separate issue for that though? It seems like it's out of scope of this PR.
There was a problem hiding this comment.
I raised the issue that linz:geospatial_type should be a Collection Field not an Item Field / Item Property for my understanding of its purpose and use. @billgeo suggested leaving it optionally as an Item Property which is fine but not the way I would be implementing it (we could again take the approach of waiting until we find a dataset where it doesn't work as a Collection Field - again - I can't think of an example).
There was a problem hiding this comment.
After discussion, to keep it simple, let's just leave it as only a collection field for now (remove from items). And change it to be a single string, rather than an array.
There was a problem hiding this comment.
If we ever need this for items/assets, we can get into that later when we need it.
There was a problem hiding this comment.
Had a chat with @billgeo and we went with this plan:
- Remove
linz:geospatial_typefrom item fields, because we don't really need it yet and we don't know what the semantics of having values here which are different from the catalogue value would be. - Make
linz:geospatial_typea mandatorystring(rather than non-empty array ofstring) type in the collection.
l0b0
force-pushed
the
feat/tweak-geospatial-type-implementation
branch
from
62cedc7 to
437a8f5
Compare
l0b0
force-pushed
the
feat/tweak-geospatial-type-implementation
branch
from
437a8f5 to
6e60436
Compare
No worries, I'd rather get it right than leave it broken :D |
Closes #170