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

initial text for Label changes #1001

Closed
wants to merge 3 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
initial text for Label changes
  • Loading branch information
Phil Varner committed Feb 22, 2021
commit 55b478dffedd617eedbeca5cb2b3b93146a007c8
12 changes: 8 additions & 4 deletions extensions/label/README.md
Original file line number Diff line number Diff line change
@@ -132,14 +132,18 @@ Some additional notes are given here for some of the core STAC Item fields and w

#### Assets

##### labels (required)
One or more assets will contain references to the label data. These assets have these requirements:

The Label Extension requires an asset with the key "labels". The asset will contain a link to the actual label data. This asset has these requirements:

- is a GeoJSON FeatureCollection
- if the `label:type` is "vector", the labels must be a GeoJSON FeatureCollection.
- if the `label:type` is "raster", it is recommended there is also an assets that references to a GeoJSON FeatureCollection defining the extent.
philvarner marked this conversation as resolved.
Show resolved Hide resolved
- Asset Roles should be used to indicate which assets are the labels. It is recommended that all Assets referencing labels have the role `labels`. Other labels such as `labels-vector` (for vector labels), `labels-raster` (for raster labels), `labels-extent` (for the vector extent of raster labels), `labels-training` (for ML training data), and `labels-testing` (for ML testing data) may also be added to further indicate what specific assets reference.
- if `label:tasks` is tile_classification, object_detection, or segmentation, each feature should have one or more properties containing the label(s) for the class (one of `label:classes`). the name of the property can be anything (use "label" if making from scratch), but needs to be specified in the `Item` with the `label:properties` field.
- if `label:tasks` is tile_regression, each feature should have one or more properties defining the value for regression. the name of the property can be anything (use "label" if making from scratch), but needs to be specified in the `Item` with the `label:properties` field.

##### Asset names

The Label Extension recommends assets be named with the keys "raster_labels" or "vector_labels". However, this is just a recommendation, and acutal name are entirely at the discretion of the implementer.

Comment on lines +143 to +146
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
##### Asset names
The Label Extension recommends assets be named with the keys "raster_labels" or "vector_labels". However, this is just a recommendation, and acutal name are entirely at the discretion of the implementer.

kind of the inverse of the previous comment -- I think tooling developers would be better off if there weren't recommended names for things, since the lines between recommended, required, and "required for this one tool to work" aren't always clearly drawn.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I only left this in the spec b/c it was the required way to indicate labels previously. I'm fine with removing it, but I'm worried that their might be tools that rely on it? But, maybe better just to remove it now before 1.0.0?

##### Raster Label Notes

If the labels are formatted as rasters - for example, a pixel mask with 1s where there is water and 0s where there is land - the following approach is recommended for including those data.