Spatial data layer

[cportele]

This issue has been created as part of the public review and is based on document 19-072. See in particular section 9.2.

A term "(spatial) data layer" is introduced, but not defined. Remove the concept or clarify.

[jerstlouis]

This is intended to be the abstract concept of geospatial data, of which e.g. a Coverage or a Features collection would derive from. It was tentatively mapped to be the definition of a 'Collection', at the level of Common. Features or Coverages would re-define the meaning of a collection as it pertains to a Features and/or Coverage representation of that geospatial data layer.

[cportele]

If "data layer" is intended as an alias to "collection" then I don't see a use or benefit, at least for Features. Layer is a map-oriented term.

[jerstlouis]

@cportele the distinction between "data layer" and "presentation layer" is critical and huge.

"Presentation layer" is a map-oriented term.
When we talk about data layer, in terms of features we're talking about "feature collections".
In Mapbox vector tiles, they are called "layers". It is purely a "data" concept.
For coverage, we're talking about a coverage (a collection of data cells).

And the value is to provide this representation-agnostic abstraction of such a data layer.

So that Maps can say "you can render one or more data layers on a map", and this covers both Features and Coverages.

So that Tiles can say "you can tile any data layer", and this covers both Features and Coverages.

So that a Search for data can cover any data layers, and return either Features or Coverages or both, that you can then render on a map, and tile. And so on.

The benefit is making OGC API modules work in a modular manner, and be interoperable between each other. It may be difficult to see the value of this only through the lens of a particular set of Features use cases, but I see tremendous benefits for this from an overall set of interoperable modular OGC API specifications.

[dblodgett-usgs]

@cportele is correct in saying that "layer" is a map-oriented term. (e.g. "openlayers") but it has clearly been defined more broadly than that in many instances. ESRI-Rest, for example has some take on "layers" as an entity key in all the service types.

I think it is right to avoid using the term layer because of this vague meaning that is rooted in visualization and has a lot of, you might say, "semantic baggage".

What we need is a way to account for, as @jerstlouis says:

the abstract concept of geospatial data

I like the idea that an endpoint conforming to OGC-API standards would present a single dataset. So the abstract concept can be handled at a higher or at least more appropriate level (e.g. OGC-API Records). The generalization penalty on handling collections of (broadly defined) layers introduces a level of abstraction that is destined to confuse people without the context of a specific API to make it obvious/not abstract.

[jerstlouis]

@dblodgett-usgs Layers with the meaning of "data" layers have been used in other OGC standards, including CDB and i3s. But some people may be familiar with only one of the two meanings, and the "data" qualification may not be clarifying enough?

I like the idea that an endpoint conforming to OGC-API standards would present a single dataset. So the abstract concept can be handled at a higher or at least more appropriate level (e.g. OGC-API Records). The generalization penalty on handling collections of (broadly defined) layers introduces a level of abstraction that is destined to confuse people without the context of a specific API to make it obvious/not abstract.

I don't see why that needs to be... And I really, really, really would like to see one end-point supporting multiple datasets, without a need to involve Records.

/collections/{collectionID} -- Up to here is your abstract data layer
/collections/{collectionID}/items -- Here is the Features API representation
/collections/{collectionID}/coverage -- Here is the Coverages API representation

The main source of confusion seems to be the term 'collection' itself, not the nature of the concept.

[dr-shorthair]

Need definitions of 'spatial resource' and 'layer' in Chapter 5.

[dblodgett-usgs]

I just ran across this gem from @cmheazel in the wiki.

Chuck, you appear to be way ahead of us here. Could you maybe re-vamp that wiki as a container issue for the collection 😉 of Collection issues?

[cmheazel]

@dblodgett-usgs Done.

[dblodgett-usgs]

Hah! That's maybe appropriate, but not quite what I mean. I was referring to creating a summary issue to try and get to the bottom of the set of issues labeled "collection".

[dblodgett-usgs]

We have what we need to clarify this now from #140. Just need to implement in the spec.

[cmheazel]

Review the drafts and see if Spatial Data Layer is still used. If not, then this issue can be closed.
Moved: @joanma747
Second: @cmheazel
NOTUC