Allow services to specify which CRS the service will offer in the GetCapabilities response

[jpass@…]

At the moment it is not possible for a WCS service operator to configure which CRS will be supported by the service. Currently the GetCapabilities response dumps all CRS supported by the software, comprising some 4212 lines of text, this is less than ideal.

The service operator should be able to configure which of the CRS supported by the software, they want their service to support.

This would (additionally) help to reduce the size of the GetCapabilities response.

For example in the BGS EarthServer service over 80% of the GetCapabilities response comprises this dump of supported CRS!

​http://earthserver.bgs.ac.uk/petascope?service=WCS&Request=GetCapabilities&version=2.0.0&

[Dimitar Misev]

In the latest version (git) of petascope, only

<crs:supportedCrs>http://www.opengis.net/def/crs/EPSG/0/</crs:supportedCrs>

is reported, e.g. see kahlua.eecs.jacobs-university.de:8080/petascope_earthlook?service=WCS&Request=GetCapabilities&version=2.0.1&

Would this be ok, or you're really interested to avoid certain CRSs?

[jpass@…]

In the example given in above comment (kahlua.eecs.jacobs-university.de:8080/petascope_earthlook?service=WCS&Request=GetCapabilities&) is this response of just <crs:supportedCrs>​http://www.opengis.net/def/crs/EPSG/0/</crs:supportedCrs> because the service only supports this CRS, or is it for some other reason?

Really if a service GetCapabilities response reports it only supports a single CRS (in this case …EPSG/0) then a client shouldn't ask for any CRS other than this supported CRS, and if the client does request a different CRS (say EPSG:27700) then the service should decline to accept this request.

I have a feeling that you are saying that the kahlua.eecs.jacobs-university.de:8080 reports only one supported CRS but actually supports all the CRS supported by the petascope software; if is so this is an error, I think.

For this enhancement request I am indeed saying that I would like to have the ability to restrict the CRS the service actually supports to a small limited number which will be listed in the GetCapabilities response, such that any request for a CRS other than those listed WILL result in an error.

[Dimitar Misev]

​http://www.opengis.net/def/crs/EPSG/0/ is a shortcut I think agreed in OGC for all CRS under EPSG/0/

Perhaps Piero can provide more details on that.

I'm not clear why would you like to restrict the capabilities (in this case allowed CRSs) to a certain subset of what the server provides?

[Piero Campalani]

Hi James, thanks for pointing out.

Yes, as Alan said, that is an (official) shortcut which we decided to use to avoid those verbose capabilities, and avoid further effort on that side. See:

git show e716a6 applications/petascope/src/main/java/petascope/wcs2/handlers/GetCapabilitiesHandler.java

At the moment, we do not allow subsettings on the supported CRSs, so the behavior is fixed.

We might think of adding a white list of allowed CRSs.
Actually, as no output reprojection is available, in the capabilities we should just list the CRS used for coverages served by Petascope (i.e. table ps_crs):

A Crs item is added to the WCS service metadata using the extension mechanism provided
by the WCS Core [OGC 09-110r3]. In its supportedCrs component it contains the list of
CRSs in which the server can return coverages.

[abeccati]

Thanks for credit Piero but it was Dimitar's saying

Anyway that's nice to have indeed but does not look like a major issue at the moment so I'm putting this as minor, unless it drives to compelling issues.

After 8.4 release we will re-examine all pending feature requests anyway.

[jpass@…]

Certainly if ​http://www.opengis.net/def/crs/EPSG/0/ is an agreed 'official OGC' short cut recognized by client software that would be a great improvement over the current full list. Could you point me to the documentation on that as I couldn't spot it whilst browsing the OGC site

For the enhancement, yes if the response of supported CRS is auto-generated from the CRS available in ps_crs, that would be the best solution, given as you say at the moment no output re-projection is available.

[Piero Campalani]

Replying to jpass@…:

Certainly if ​http://www.opengis.net/def/crs/EPSG/0/ is an agreed 'official OGC' short cut recognized by client software that would be a great improvement over the current full list. Could you point me to the documentation on that as I couldn't spot it whilst browsing the OGC site

"OGC® Name Type Specification for CRSs", Sec.7.3.1, Example 3.
​http://www.ogcnetwork.net/system/files/11-135_OGC-NA_Name-Type-Specification-for-CRSs_2012-08-07.pdf

For the enhancement, yes if the response of supported CRS is auto-generated from the CRS available in ps_crs, that would be the best solution, given as you say at the moment no output re-projection is available.

If this solution is agreed, I can implement it for 8.4 pretty quickly.
Some questions in my mind: should we put all the CRSs in ps_crs, or should we avoid publishing those like "CRS:1" or other custom identifiers for temporal axes, etc. ?

supportedCrs elements must be of type anyURI, so I guess we should just publish the .. URIs there.
​http://www.schemacentral.com/sc/xsd/t-xsd_anyURI.html

[Dimitar Misev]

Yeah, we could just filter and publish the CRS URLs.

But I agree with Alan that this is not some critical bug (it's an enhancement); it's better to focus on the 8.4 tickets that may be more important and leave this for later.

[Piero Campalani]

Replying to dmisev:

Yeah, we could just filter and publish the CRS URLs.

But I agree with Alan that this is not some critical bug (it's an enhancement); it's better to focus on the 8.4 tickets that may be more important and leave this for later.

I see it more as a bug actually; if a service has no EPSG:xyz coverages, it cannot return coverages in any EPSG projection, as it would appear instead.
I have no tickets left for 8.4, that's why I was offering myself as sacrificial developer for this.

[abeccati]

To sum up that:

Agreed to serve only CRS that are listed in ps_crs table.

Moreover:
http://www.opengis.net/def/crs/EPSG/0/ is a valid shortcut for "all EPSG" but I think the doc is not public yet.
The shortcut shall take precedence over its "child" CRS so if in ps_crs we have
http://www.opengis.net/def/crs/EPSG/0/ together with several http://www.opengis.net/def/crs/EPSG/0/NNNNNN, only the shortcut will be shown.

In that way just adding or removing it from the table allows specification of a list or the whole set as shortcut.

[abeccati]

Looks like we have a new Java developer registered so I am assigning this to him as an introductory Ticket. Lets give him some time to get acquainted with Petascope and help him get onto this via the dev list if needed.

[Piero Campalani]

A note: as long as there is no output CRS reprojection capabilities, only native CRSs are supported (hence what's in ps_crs).
In a scenario with full CRS-extension implementation, supported CRS would probably need to list the EPSG folder shortcut again, since the server is in the power to return coverages in any EPSG projection.

supportedCrs: Identifier of a CRS a result coverage can bear.

From OGC 11-053.

[abeccati]

Reassigning to component owner for future planning

[Peter Baumann]

the Capabilities document is known to be flawed by OGC, and there are (lively) discussions on how to improve it.
Generally, people tend to (mis)use it as a catalog, and not surprisingly data are either too few or too many (sometimes both) for users. A simple textfile does not offer much comfort here, unfortunately.
Note that it is not required to execute a GetCapabilities before a GetCoverage, so if the Capabilities document is unwieldy clients can consider to not request it.

[Peter Baumann]

PS: a server may abbreviate the CRS list: for example, to express support for "all EPSG CRSs" just leave out the code.

[James Passmore]

Replying to pbaumann:

the Capabilities document is known to be flawed by OGC, and there are (lively) discussions on how to improve it.

Indeed, but that isn't really the issue here.

Note that it is not required to execute a GetCapabilities before a GetCoverage, so if the Capabilities document is unwieldy clients can consider to not request it.

The issue here though is not that the full GetCapabilities response is unwieldy, the issue is that it portrays incorrect information. If my service only supports one CRS , then it is incorrect to report in the GetCapabilities response that it can support every CRS know to man (or at least to EPSG…). We have to separate the capabilities of the software and the capabilities of the service implemented.

[Peter Baumann]

hm, to me the service has the capabilities the underlying software delivers.
The Capabilities document is not meant for configuration "against" underlying software.
But if this is wanted then the petascope tables can always be hand-edited, of course.

[James Passmore]

Replying to pbaumann:

hm, to me the service has the capabilities the underlying software delivers.

I think we agree on that point, here's the scenario:

I upload data into community rasdaman and all the data loaded is in the same single projection.

The underlying software can only supply data in that same projection, because it doesn't support on the fly re-projection. Therefore the capabilities document should only advertise the projection that the software can provide based on the data loaded and available through the service.

The Capabilities document is not meant for configuration "against" underlying software.

I don't see this as a configuration request, it's not about trying to configure the software, rather it about reporting what's possible.

[Peter Baumann]

gradually beginning to understand, thanks for your patience.
What about the following: if the server only can deliver images "as is", ie: without reprojection, then this server actually does not support any CRS (transformation), hence the CRS list should be empty.
This is reflected by the fact that, as per WCS Core, you get coverages in their Native CRS ,which can be any.
WDYT?

[James Passmore]

Yes, if the purpose of the

ServiceMetadata\wcs:Extension\crs:CrsMetadata\crs:crsSupported

elements is to advertise re-projection capabilities of the service, and the service can only serve native CRS, then yes it should be omitted.

Which is lucky (or by design… because I've just seen that in our version 9. implementation there is no crs:CrsMetadata\crs:crsSupported section!

[Peter Baumann]

yes, because the CRS extension is in rasdaman enterprise
so can we consider this as clarified? If so, would you close the ticket?

[James Passmore]

Replying to pbaumann:

yes, because the CRS extension is in rasdaman enterprise
so can we consider this as clarified? If so, would you close the ticket?

The ticket has already been closed as won't fix.