Fix for CRS by reference implementation

[tackandr]

Hi, we are trying to provide limited area numerical weather forecast for Scandinavia through EDR API. The model is running in projected coordinates as they represent better those high latitude areas. The problem for us is now that we can't provide our custom CRS to our collection as CRS is handled already at a low level of the API and in current implementation only allows to provide CRS from authority known to pyproj.

def get_crs(crs: Union[str, pyproj.CRS]) -> pyproj.CRS:
    """
    Get a `pyproj.CRS` instance from a CRS.
    Author: @MTachon

    :param crs: Uniform resource identifier of the coordinate
                reference system. In accordance with
                https://docs.ogc.org/pol/09-048r5.html#_naming_rule
                URIs can take either the form of a URL or a URN
                or `pyproj.CRS` object
    :raises `CRSError`: Error raised if no CRS could be identified from the
        URI.

    :returns: `pyproj.CRS` instance matching the input URI.
    """

    if isinstance(crs, pyproj.CRS):
        return crs

    # normalize the input `uri` to a URL first
    uri = str(crs)
    url = uri.replace(
        'urn:ogc:def:crs', 'http://www.opengis.net/def/crs'
    ).replace(':', '/')
    try:
        authority, code = url.rsplit('/', maxsplit=3)[1::2]
        crs = pyproj.CRS.from_authority(authority, code)
    except ValueError:
        msg = (
            f'CRS could not be identified from URI {uri!r}. CRS URIs must '
            'follow one of two formats: '
            '"http://www.opengis.net/def/crs/{authority}/{version}/{code}" or '
            '"urn:ogc:def:crs:{authority}:{version}:{code}" '
            '(see https://docs.opengeospatial.org/is/18-058r1/18-058r1.html#crs-overview).'  # noqa
        )
        LOGGER.error(msg)
        raise CRSError(msg)
    except CRSError:
        msg = f"CRS could not be identified from URI {uri!r}"
        LOGGER.error(msg)
        raise CRSError(msg)

    return crs

My interpretation of the definition of a URI in https://docs.ogc.org/is/19-072/19-072.html 6.2 Identifiers together with https://docs.ogc.org/is/18-058r1/18-058r1.html#crs-overview 6. Requirements Class Coordinate Reference Systems by Reference
is that the API should retrieve a projection as a response from the URI

Requirement1:
Each CRS supported by a server SHALL be referenceable by a uniform resource identifier (i.e. a URI).

The recommendation

Recommendation1:
Servers that implement this extension SHOULD be able to recognize and generate CRS identifiers with the following format model:

http://www.opengis.net/def/crs/{authority}/{version}/{code}

should not be seen as a way how to implement this but to test the behavior instead, by requiring that the API can correctly fetch CRS by reference from those authorities. To my understanding though any URI should be accepted as long as it generates a valid response similar to the ones in the recommendation.

Current implementation in pygeoapi extracts authority and code from string and builds the CRS without actually fetching it from the reference. I think this is not how the standard intended it and it has actual implications to us as we are now forced to reproject our data to CRS84 which causes unnecessary computation, loss of accuracy and inefficient spatial representation of our domain.
I think how this should work is that pyproj.CRS is created from GML->wkt which is retrieved from the URL specified in the crs property in the collection object of the feature collection. Or at least this should be a possibility in the API.

Kind regards
Andreas Tack, Finnish Meteorological Institute