Repository navigation
Do we need a PolygonArray or PolygonCollection domain type? #218
Description
I think we have agreed (#202) that the interpretation of MultiPolygon should be as a single domain element, with a single associated range value that applies collectively to all the constituent Polygons. (This is currently inconsistent with the Playground, which would need to be fixed.) But this leaves an obvious question - how should we encode a situation where we want to associate different range values with each individual polygon? For example, recording the population of each of the countries of Europe.
Maybe we need a new domain type - perhaps PolygonArray or PolygonCollection? The domain would look structurally similar to a MultiPolygon but the associated range would be different.
This would also imply a need for a PolygonCollectionSeries.
Activity
jonblower commentedon Apr 28, 2026
It might also imply the need for a MultiPolygonCollection!! This would be needed for the use case of "give me the population of each of the European countries, associated with the geometries of all their individual constituent territories".
In reality, I wonder if this would be just too confusing, and maybe the Coverage would just associate country codes with population values. There might be a separate lookup to associate country codes with geometries (GeoJSON features).
chris-little commentedon May 5, 2026
@jonblower and others. I'm trying to clarify things for myself.
Conceptually:
Hopefully we all agree on those.
Practically:
A CoverageJSON Domain could be
a) a WKT Polygon, with multiple "holes" (0...), with a set of multiple (1...) ranges. Case (1)
b) a WKT MultiPolygon, with multiple Polygons, with multiple "holes" (0...), sharing a set of multiple (1...) ranges. Also Case (1)
A WKT MultiPolygon, with multiple Polygons, with multiple "holes" (0...), but each polygon having its own set of multiple (1...) ranges must be a collection of Coverages.
A collection of Coverages could also be represented by WKT Polygons, with multiple "holes" (0...), each Polygon having its own set of multiple (1...) ranges.
I think both the Polygon and Multipolygon representation of a collection of coverages could be represented by the existing CoverageCollection mechanism, but then possibly confoujnding the use of CoverageCollection for ensembles or second time dimension.
So if this is progressed, for me there are two issues: do we call the new Domain an
arrayor acollection(possibly causing confusion with CoverageCollection)?And is this a V1.0.1 or V1.1? I think V1.1.
chris-little commentedon May 12, 2026
@jonblower @awarde96 I think that I have resolved in my mind about the added examples.
Within the
valuesbrackets we need:We could still list an array of Polygons within the
valuesbracket with only triple nested brackets but this would be semantically different from a MultiPolygon and could be considered a collection/array of polygons. The Polygons could have different range values, whereas we have decided the MultiPolygon is associated with one range value.We could also have list an array of MultiPolygons within the
valuesbrackets with quadruple nested brackets with differing range values and could be considered a collection/array of MultiPolygons.An array/collection of MultiPolygons can function as an array/collection of Polygons but not vice versa.
So no PolygonArray, but yes MultiPolygon Array. Thoughts? (This thinking took 3 cups of coffee!)
chris-little commentedon May 20, 2026
@jonblower At the CoverageJSON Community Group on 2026-05-20, we agreed that an array or collection of MultiPolygons is the correct approach, as an array of Polygons is just a MultiPolygon, but wewere not convinced without convincing use cases. In any case, as it would be a new Domain type, it should be V1.1 at the earliest.
And we can do this with CoverageCollections, so can we close this issue?