I am struggling with the DescribeFeatureType query with WFS KVP encoding.
I have this WFS: https://inspire-wfs.maanmittauslaitos.fi/inspire-wfs/au?request=GetCapabilities&service=wfs&version=2.0.0 and I can see in the GetCapabilities that there is a FeatureType called au:AdministrativeUnit
.
I could of course use DescribeFeatureType to give me the description of all Feature Types of the service, but I would like to use &typeName=XXXX in the kvp to choose only this FeatureType au:AdministrativeUnit
So I basically do the following request: https://inspire-wfs.maanmittauslaitos.fi/inspire-wfs/au?&request=DescribeFeatureType&service=WFS&version=2.0.0&typeName=au:AdministrativeUnit
But the result is not filtering at all to give me only the Feature Type with the name au:AdministrativeUnit
.
I saw that in the OGC specifications, there is sometimes written typename or typenames. I tried both of them with changing the version and I don´t get it!
Am I missing something important here?
With an other WFS, I can do the query with filtering typenames without issue!
Best Answer
It is strictly speakingtypenames
for a version 2.n andtypename
for a version 1.n request,It is strictly speaking
typenames
for a version 2.n GetFeature request but stilltypename
for a version 2.n DescribeFeatureType request; version 1.n requests usetypename
throughout, similarly it should always beWFS
for a service request (i.e. it should be capitals) likeservice=WFS&
and for version negotiation in a GetCapabilities request it should beacceptversions=2.0.0, 1.1.0, ...&
for a version 2.n andversion=1.1.0&
for versions of WFS before 2, or version can be omitted.And for completeness the syntax for the KVP is
name[=value]&
where =value is optional, and the pair ends with an&
. Where name is not case sensitive, but value is always, case sensitive.That's what it says in the specification documents, but some software doesn't adhere to this, or is lax when it comes to case sensitivity, and gives feature types if you give typename instead of typenames.
So this should work:
https://inspire-wfs.maanmittauslaitos.fi/inspire-wfs/au?request=GetCapabilities&service=WFS&
and this:
https://inspire-wfs.maanmittauslaitos.fi/inspire-wfs/au?request=GetCapabilities&service=WFS&acceptversions=2.0.0,1.1.0&
and this:
https://inspire-wfs.maanmittauslaitos.fi/inspire-wfs/au?request=GetCapabilities&service=WFS&version=1.1.0&
but none do, so the service is not showing WFS compliance.
If we cut off the trailing & then the URL's work, but omission of the & is a client prerogative, not a server option...
If the response is not as expected, the server may be at error here, not your request.