validation of crs (case sensitive)

[Dnoack49]

Dear all,

when validating the following dataset:

https://inspire.brandenburg.de/services/ad_alkis_wfs?service=WFS&version=2.0.0&request=GetFeature&Count=10&typenames=ad:Address

we receive the error
CC: Reference systems, Spatial reference systems
rsa.a1: Spatial reference systems in feature geometries
rsa.a.2: Default spatial reference systems in feature collections

A spatial geometry uses an unexpected coordinate reference system 'http://www.opengis.net/def/crs/epsg/0/25833'. Please refer to table 2 of the data specification for the list of expected coordinate reference systems.

However, this crs is listed in the INSPIRE-Registry:
https://inspire.ec.europa.eu/crs/25833

we have validated another dataset which did not throw this error:
https://inspire.brandenburg.de/services/sd_arten_wfs?service=WFS&version=2.0.0&request=GetFeature&typename=sd:SpeciesDistributionUnit&Count=10

The same crs is used: http://www.opengis.net/def/crs/EPSG/0/25833

The only difference between these two datasets is that in the second example the EPSG is written in Caps.
Should the validator not also accept both versions: http://www.opengis.net/def/crs/epsg/0/25833 AND http://www.opengis.net/def/crs/EPSG/0/25833
With both URL the crs is accessible online.

kind regards

[ftporthlnug]

Using your request for the "erroneous" WFS dataset No. 1, https://inspire.brandenburg.de/services/ad_alkis_wfs?service=WFS&version=2.0.0&request=GetFeature&Count=10&typenames=ad:Address

I get the following header with boundary box

<wfs:FeatureCollection timeStamp="2025-11-05T15:15:20.677+01:00" numberReturned="10" numberMatched="866017" xsi:schemaLocation="http://inspire.ec.europa.eu/schemas/ad/4.0 https://isk.geobasis-bb.de/schema/inspire.ec.europa.eu/schemas/ad/4.0/Addresses.xsd http://www.opengis.net/wfs/2.0 https://isk.geobasis-bb.de/schema/ogc/wfs/2.0/wfs.xsd http://www.opengis.net/gml/3.2 https://isk.geobasis-bb.de/schema/ogc/gml/3.2.1/gml.xsd">
wfs:boundedBy
<gml:Envelope srsName="http://www.opengis.net/def/crs/epsg/0/25833" srsDimension="2">
gml:lowerCorner380588.137 5694968.424</gml:lowerCorner>
gml:upperCorner431887.899 5699823.531</gml:upperCorner>
</gml:Envelope>
</wfs:boundedBy>

with a sample member
wfs:member

(...) (and geometry)

<gml:Point gml:id="o12006.id.256192651.position.Geom_0" srsName="http://www.opengis.net/def/crs/epsg/0/25833" srsDimension="2">
gml:pos380588.137 5699823.531</gml:pos>
</gml:Point>

Using your request for the "correct" WFS dataset No. 2, https://inspire.brandenburg.de/services/sd_arten_wfs?service=WFS&version=2.0.0&request=GetFeature&typename=sd:SpeciesDistributionUnit&Count=10

I get the following header without boundary box
<wfs:FeatureCollection xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd http://inspire.ec.europa.eu/schemas/sd/4.0 https://inspire.brandenburg.de/services/sd_arten_wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=DescribeFeatureType&OUTPUTFORMAT=application%2Fgml%2Bxml%3B+version%3D3.2&TYPENAME=sd:SpeciesDistributionUnit&NAMESPACES=xmlns(sd,http%3A%2F%2Finspire.ec.europa.eu%2Fschemas%2Fsd%2F4.0)" timeStamp="2025-11-05T14:18:47Z" numberMatched="unknown" numberReturned="0">

with a sample member
wfs:member
<sd:SpeciesDistributionUnit gml:id="SpeciesDistributionUnit_10kmE440N333_korm_DIANDELT">
gml:description
Bundesnaturschutzgesetz: besonders geschützt; Rote Liste Deutschland: keine Angabe; Rote Liste Brandenburg: gefährdet; Natura2000: keine Angabe
</gml:description>
(...)
(and geometry)
sd:geometry

<gml:Polygon gml:id="SpeciesDistributionUnit_10kmE440N333_korm_DIANDELT_SD_GEOMETRY" srsName="http://www.opengis.net/def/crs/EPSG/0/25833">
gml:exterior
gml:LinearRing
gml:posList
254708.010 5896464.599 244729.082 5897160.517 244031.762 5887180.325 254010.873 5886485.061 254708.010 5896464.599
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>

Given the different extents, x-dimension starting with 38.. and with 25.., respectively, and y-dimension starting with 569.. and 589..,, respectively,
is it possible that WFS dataset No. 1 has extents that are inconsistent to EPSG 25833, i.e. UTM33N ?
I.e. that the delivered geometry is another one than EPSG 25833 and that the validator returns an error because of that?

[Dnoack49]

Dear @ftporthlnug ,

thank you for your response. Despite the differences in the beginnings of the x- and y-dimensions the "erroneous" WFS dataset No. 1 is consistent to the EPSG 25833/UTM33N.

I have marked an example of xy-Positions for the

"erroneous" WFS dataset No. 1 (green Point) 380588.137 5694968.424
"correct" WFS dataset No. 2 (blue Point) 254708.010 5896464.599

in the graphic below (they are just far apart but remain in our German State Brandenburg:

in Addition, another Provider which offers this Dataset in EPSG:25833 the same error occurs:
https://www.geodaten-mv.de/dienste/inspire_ad_alkis_download?service=WFS&version=2.0.0&request=GetFeature&Count=10&typenames=ad:Address

so we assume that it could be an error in the validation process.

[fabiovinci]

Dear @Dnoack49,

the error occurs because the validator checks the specific values that serve as unique identifiers for the CRSs, which are available in the attribute "CRS External URI Identifier" of each CRS.

You need to update the values in your dataset with the correct ones, particularly those with EPSG in uppercase: http://www.opengis.net/def/crs/EPSG/0/25833.

[Dnoack49]

Thank you @fabiovinci , we will have a look at this and close the issue when corrected.