Separate label extensions

[m-mohr]

Origin: https://github.com/radiantearth/stac-spec/issues/938

The label extension includes a number of special cases for raster labels, like those are weird labels. Work with raster labels has revealed areas that the raster label extension doesn't handle very well. The label extension as is is quite large in terms of the number of fields added, and raster and vector items will probably continue to drift. With this in mind, the label extension should be split at least into a vector-label and raster-label extension, possibly with a label-common extension holding the common fields.

This issue exists for:

• advocacy for / against splitting the label extension
• advocacy for or against the label-common extension that vector and raster label extensions inherit from

[duckontheweb]

I'm in favor of making this split for all the same reasons mentioned above.

With this in mind, the label extension should be split at least into a vector-label and raster-label extension, possibly with a label-common

How do people feel about making this label-raster, label-vector, and label-common? That way they would show up next to each other when alphabetized and the naming would have a standard convention.

possibly with a label-common extension holding the common fields.

It seems like this would create a dependency on this label-common extensions for the raster-label and vector-label extensions. It seems like we could enforce this pretty easily within the JSON schema, but do we have any examples of documenting these kinds of dependencies in other extensions?

[duckontheweb]

It seems like this would create a dependency on this label-common extensions for the raster-label and vector-label extensions. It seems like we could enforce this pretty easily within the JSON schema, but do we have any examples of documenting these kinds of dependencies in other extensions?

It looks like the STAC API spec adds a "Dependencies" field at the top of the READMEs (e.g. in the Core spec). If we go the route of having a label-common extension, maybe we should add this to the extensions template.

[jisantuc]

We don't really have a lot of examples of documenting dependencies in other extensions. It seems like it would need to be prose in the README and the json schema in the repo would need the references. You can see in card4l that there's a similar commons strategy.

I'm curious if maybe this is premature though -- we have these two kind of related structures (vector labels, raster labels) that right now have some overlapping fields, but I don't think it's essential that they'll continue to have overlapping fields. Especially while there isn't a huge user-base, it might be valuable to pay a cost in duplication so that someone using one of the extensions who has feedback doesn't need to think about how it affects the other extension.

[duckontheweb]

I'm curious if maybe this is premature though -- we have these two kind of related structures (vector labels, raster labels) that right now have some overlapping fields, but I don't think it's essential that they'll continue to have overlapping fields. Especially while there isn't a huge user-base, it might be valuable to pay a cost in duplication so that someone using one of the extensions who has feedback doesn't need to think about how it affects the other extension.

Fair point, I think it would increase the overhead of development to have to constantly think through whether something should be "common" or not and making sure those fields stay relevant to both of the other extensions.

As a starting point, we could simply split into label-vector and label-raster. If common fields emerge after some time then maybe we could reconsider a common dependency.

[cuttlefish]

:+1: for splitting the extensions. The schema might start to get rather messy if we need to regularly include conditionals. I've added one and find it pretty hard to read. It might also be easier to get better test and example coverage by separating things.