Allow add WCS Layer with EPSG: 0 in DescribeCoverage

[ashleysommer]

Describe the bug
Not sure if its a bug or not.
I'm having trouble with QGIS interacting with our Thredds WCS endpoint. I'm not sure if its a bug in Thredds or QGIS or neither, or if I'm just interpreting it wrong.

Please see the NetCDF4 file served by Thredds 4.6.14 here:
http://esoil.io/thredds/wcs/SMIPSall/SMIPSv0.5.nc?service=WCS&version=1.0.0&request=GetCapabilities

Specifically the DescribeCoverage endpoint here: http://esoil.io/thredds/wcs/SMIPSall/SMIPSv0.5.nc?service=WCS&version=1.0.0&request=DescribeCoverage

The ResponseCRSs field contains:
EPSG:0 [Latitude_Longitude]

How to Reproduce

Add that WCS endpoint as a new WCS layer in Thredds, connect to the server, and try to add one of the layers to your project.

When QGIS queries the supportedCRSs from the DescribeCoverage endpoint, it sees the "EPSG:0" entry and interprets as an invalid CRS, so it ignores it.

When requesting data via a GetCoverage request, QGIS instead uses &responsecrs=OGC:CRS84 which of course causes Thredds to throw this error:
Response CRS [OGC:CRS84] not the supported CRS [EPSG:0 [Latitude_Longitude]]
If I substitute that with "EPSG:0 [Latitude_Longitude]" I get a valid response from WCS.

QGIS and OS versions
QGIS 3.10.1, reproduced on Windows and Linux OS

Additional context
I've created a question on the Thredds repo issue tracker too, see here: Unidata/thredds#1318

This issue is related: #28864, and this PR: #9005
But it seems to actually looks to be the opposite, it claims that when EPSG: 0 is found in the responseCRSs it should be ignored and fallback to the default OGC:CRS84.

[nyalldawson]

I strongly suspect this is a thredds bug (or a server configuration bug). EPSG:0 is clearly an invalid code...

[ashleysommer]

Ok, looks like its not something I'm doing wrong with our NetCDF4 file, even the Thredds example/sample WCS endpoint from their documentation has the same issue: https://thredds.ucar.edu/thredds/wcs/galeon/testdata/striped.nc?request=DescribeCoverage&version=1.0.0&service=WCS&coverage=ta

[nyalldawson]

I can't find much public mention of "EPSG:0". http://osgeo-org.1560.x6.nabble.com/Adding-support-for-a-new-EPSG-code-EPSG-0-td4270761.html suggest that it could be a special keyword indicating "no projection" (or non-world projection), but that proposal seems to have been voted down.
https://pro.arcgis.com/en/pro-app/help/sharing/analyzer-warning-messages/24027-map-uses-a-custom-coordinate-system.htm suggests that it may represent a custom CRS

If this is the case, we could represent this in QGIS by setting the layer's CRS to "no projection"?

[ashleysommer]

Yes believe they are using "EPSG: 0" to represent "no projection" though the use of "Latitude_Longitue" in the name suggests its probably supposed to be a CRS with proj=longlat but I'm guessing there.

I've discovered that removing the "&responsecrs=" component of the GetCoverage request string will allow the request to return the expected result. So perhaps the setting the layer to "no projection" and removing the "&responsecrs=" component of the request is a valid solution in the case of encountering the "EPSG: 0"

[ashleysommer]

I've done some digging, looks like this weird coordinate system does come from my netcdf4 file.

I am looking through the Thredds WCS code and found where EPSG: 0 is defined here: https://github.com/Unidata/thredds/blob/e96a74578920315f02acaeb88b9592e10db6ac41/cdm/src/main/java/ucar/unidata/geoloc/ogc/EPSG_OGC_CF_Helper.java#L66

It mentions "Added in CF-1.2". CF is a NetCDF4 convention spec.
It is common (by convention) to add a variable named "crs" in the netcdf file, and add attributes describing that crs. One thing you can do is add "crs.grid_mapping_name=latitude_longitude" to specify that the grid used internally to the netcdf file is actually in latitude/longitude.

See example 5.8 in the CF-1.2 spec:
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.2/build/cf-conventions.html#coordinate-system

So when a netcdf4 file has "crs.grid_mapping_name=latitude_longitude" it appears that Thredds specifies the WCS responsecrs "EPSG:0 [Latitude_Longitude]"

[ashleysommer]

FWIW, all of the relevant metadata in my netcdf4 file is the following:

Conventions=CF-1.6
spatial_ref='GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]'
crs.grid_mapping_name='latitude_longitude'
crs.long_name='Latitude Longitude'
crs.longitude_of_prime_meridian=0.0
crs.semi_major_axis=6378137.0
crs.inverse_flattening=298.257223563
crs.spatial_ref = 'GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]'
crs.crs_wkt = 'GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]'

[gioman]

@ashleysommer where do we stand with this report?

[github-actions]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

[ashleysommer]

I believe this is still a bug and still needs to be addressed.

[gioman]

I believe this is still a bug and still needs to be addressed.

@ashleysommer URL is not working anymore.

[ashleysommer]

That's right. We no longer host a Thredds instace on that domain. However this issue is not unique to our deployment. All Thredds WCS endpoints exhibit the same behaviour. For example, you can test with the official Thredds WCS Sample/Example endpoint:
https://thredds.ucar.edu/thredds/wcs/galeon/testdata/striped.nc?request=DescribeCoverage&version=1.0.0&service=WCS&coverage=ta