Conflict between CRS extension and Core

[cportele]

Requirement 16 in the Core requires that the content for the feature collection metadata is that same in the /collections and /collections/{collectionId} responses.

The CRS extension states:

To prevent unnecessary duplication of lists of supported coordinate reference systems, a global list of supported coordinate reference systems may be provided as part of the feature collections metadata.

As a result, a server that just provides the CRS in the global list in /collections will not meet the requirement in the core. Either we relax the requirement in the Core or we change the CRS extension to be consistent with the Core.

[jampukka]

Is the current draft of the CRS extension readable somewhere?

I can also see a need for limiting supported coordinate reference systems per collection.
For example one or more collection requires certain crs for high-precision, but not all of the collections in the service.

[cportele]

@jampukka - Yes, here: https://github.com/opengeospatial/WFS_FES/tree/master/extensions/crs.

The main content is in https://github.com/opengeospatial/WFS_FES/blob/master/extensions/crs/clause_06_crs.adoc.

[jampukka]

@cportele thanks!

After reading the parts in question it's clear that the issue I raised doesn't exist.
Or it can exist - but only if the service provider chooses to use the global list.

/rec/crs/fc-md-crs-list-global-default also conflicts with Core Req 16 when all collections in the service do not have the same storageCrs (the order of the elements in the array changes)
(Also the "crs": {...} in the example illustration should be "crs": [...])

[aaime]

I believe it would be useful to allow different lists of value for global and per collection, having a set of common, global CRSs in the global (e.g., WGS84, Web Mercator, global equal area projections and the like) and maybe some extra local CRSs of choice on a per collection basis.

[jampukka]

@aaime you're suggesting that the supported coordinate reference systems of a collection should be (global+collection specific), right?

I personally don't like the idea, as it makes parsing the crs "capabilities" of a collection more difficult.
The client would have to combine the global and the collection specific lists after parsing them both.
Also, when the {collectionId} is "known" (for example as user input) the client would have to fetch /collections instead of just /collections/{collectionId}.

[aaime]

No, I merely suggest that a collection can override the global settings, the "extra local CRSs" was just part of the example I had in mind, but did not mean to imply having to parse both.
To make it more clear: if the collection has its own local list of CRSs, then that replaces the list of values in "/collections"

[jampukka]

Thanks for clarifying, I agree overriding is less problematic.

@cportele is it stated somewhere that the collections crs property becomes optional if the global list is provided? The two would still have to co-exist so that storageCrs can be determined, no?

The global list seems to create more problems than it solves, maybe just drop it?

[cportele]

if the collection has its own local list of CRSs, then that replaces the list of values in "/collections"

That is the current logic. At least how we interpreted it in our implementation.

is it stated somewhere that the collections crs property becomes optional if the global list is provided?

It is implied by the current word, but not that explicit.

The global list seems to create more problems than it solves, maybe just drop it?

But for servers with many collections/layers and many supported CRSs the redundancy can be overwhelming, so we need some solution for these cases.

[jampukka]

But for servers with many collections/layers and many supported CRSs the redundancy can be overwhelming, so we need some solution for these cases.

That is true.

Changing the CRS extension to be consistent with the Core would mean copying the global list (if exists) to each /collections/{collectionId} response. Or is there another way I'm not seeing?

Thinking about possible future extensions and more properties getting added to the /collections schema - can this solution get ugly?

One idea is to separate the /collections and /collections/{collectionId} schemas. In /collections only include the collectionId and a link to the metadata document for each collection and add properties for service-wide settings (for example the global list for crs). In /collections/{collectionId} include all properties, but not the global ones, and provide a link to the parent metadata.

Another possibility could be to add an option to select what information /collections returns, sort of like sections in GetCapabilities, but I'm not sure if it solves the issue (fine-grained control might be needed for this to make sense). Would also probably need some sort of filtering/limiting possibilities as discussed in #76.

[pvretano]

Some comments ...

(1) No, the local list does not replace the global list. My intent was that it augments it. The point of the global list was to prevent endless repetition of the same subset of supported CRSs. I'll have to check the wording in the extension text since that intent does not seem to have been conveyed properly.

(2) Core REQ 16 seems a little ambiguous to me and based on the discussion here I have implemented it incorrectly in my server. I interpreted it as meaning the the response to accessing /collections/{collectionId} is the same as accessing /collections. The primary different in the response is that the collections array for /collections contains the metadata describing ALL the offered collections while the collection array for /collections/{collectionId} only contains a single object containing the metadata for the {collectionId} feature collection. Could we add an example or two in the core to make the intent a bit more explicit?

(3) Does Req 16 imply "character-for-character" identical content?

What about a solution to the redundancy problem using JSON pointers (https://tools.ietf.org/html/rfc6901)? What I have in mind goes something like this:

GET /collections
{
"links": [...],
"crs": [... global list...],
"collections": [
{"name": "feature1", ..., "crs":[#/crs]},
{"name": "feature2", ..., "crs":[#/crs, CRS_A, CRS_B, CRS_C], ...},
{"name": "feature3", ..., "crs":[CRS_D, CRS_E, CRS_F], ...},
{"name": "feature4", ...},
...,
]
}
So, for feature1 the list of supported crs's is the global list.
For feature2 the list of supported crs's is the global list plus CRSs A, B and C.
For feature3 the list of supported CRSs is D, E and F but NONE from the global list since the JSON pointer to that list (i.e. "#/crs") is not included in the list.
Feature4 is non-spatial and so CRS's -- global or otherwise -- do not apply.

GET /collections/feature2
{"name": "feature2", ..., "crs": [...global list...,CRS_A,CRS_B,CRS_C], ... }

Would this approach violate Req 16?

NOTE: I am not sure that this is the correct use of JSON pointers but my basic idea is that a global list can be included in the /collections response and then referenced (somehow) as desired by the offered collections. So, the global list is not inherited but must be explicitly referenced.

[cportele]

Req 16 is not intended to mean that the lexical content is the same, it is the value space that must be consistent. The issue is that so far there was no case where the two would differ, but now we have such a case. So I think we need to clarify Req 16 in that direction. From a Core perspective we should also only require that the elements defined in the Core like name, title, etc are the same. What applies to extensions should be stated in the extensions like CRS. I will assign this issue to me to update the text around Req 16.

I agree with your proposal in (3) and would support to amend the CRS extension in that way. This addresses the original intent, but has guidance how this is done consistently. I will assign the issue also to you for updating the CRS extension.