GeoServer WFS DescribeFeatureType response missing attribute when request has namespace in the path

GeoServer GeoServer User
1

Hi,

I had a problem with using field named “name” in GeoServer WFS service. That problem has been resolved with Overriding GML Attributes but raised more questions.

Is it a valid request to GeoServer having namespace in the path?

Like this
http://localhost:8080/geoserver/ne/wfs/service?service=wfs&version=1.1.0&request=DescribeFeatureType&TypeName=ne:populated_places

Is the above request equivalent to this?
http://localhost:8080/geoserver/wfs/service?service=wfs&version=1.1.0&request=DescribeFeatureType&TypeName=ne:populated_places

“name” field is missing from the response when there is namespace in the path (first one).
(Try this with Override GML Attributes enabled in WFS settings with geoserver Natural Earth demo dataset.)
What is the expected behavior here?

What is setting GML 3.2 on/off responsible for? (Is it responsible for overriding gml in WFS 2.0.0 requests?)

I have run WFS queries with different versions testing Natural Earth demo dataset with/without namespace in the path and also setting Override GML Attributes on/off.

Test summary:

  1. If there is namespace in the path, no “name” field is returned for WFS version 1.1.0 and 2.0.0 requests regardless of the state of settings.

  2. If there is namespace in the path, “name” field is always returned for WFS version 1.0.0 request regardless of the state of settings. (This is really good that we always have a way to get correct response.)

  3. Setting Override GML Attributes for GML 3.2 on/off has no effect on this matter in any of these test cases (Possibly 2.0.0 requests are routed to GML 3 because when it’s state changes there is an effect on 2.0.0 request).

# Test requests
# Request without namespace
curl -XGET "http://localhost:8080/geoserver/wfs/service?service=wfs&version=1.0.0&request=DescribeFeatureType&TypeName=ne:populated_places" -o ne_populated_places_1.0.0.xsd
curl -XGET "http://localhost:8080/geoserver/wfs/service?service=wfs&version=1.1.0&request=DescribeFeatureType&TypeName=ne:populated_places" -o ne_populated_places_1.1.0.xsd
curl -XGET "http://localhost:8080/geoserver/wfs/service?service=wfs&version=2.0.0&request=DescribeFeatureType&TypeNames=ne:populated_places" -o ne_populated_places_2.0.0.xsd
# Request with namespace
curl -XGET "http://localhost:8080/geoserver/ne/wfs/service?service=wfs&version=1.0.0&request=DescribeFeatureType&TypeName=ne:populated_places" -o ne_populated_places_1.0.0_ne.xsd
curl -XGET "http://localhost:8080/geoserver/ne/wfs/service?service=wfs&version=1.1.0&request=DescribeFeatureType&TypeName=ne:populated_places" -o ne_populated_places_1.1.0_ne.xsd
curl -XGET "http://localhost:8080/geoserver/ne/wfs/service?service=wfs&version=2.0.0&request=DescribeFeatureType&TypeNames=ne:populated_places" -o ne_populated_places_2.0.0_ne.xsd
2

Hello @osgeouser (that is quite the generic handle!)

gml:name

I am glad you were able to figure out something is “interesting” with GML well-known properties like “name” and “pointProperty”.

Because “name” is already defined by gml:AbstractFeatureType, as gm:name [0…*], it not necessary to explicitly list it in the DescribeFeatureType response? The GML output will correctly validate as the attribute name is in fact defined…

Chances are the WFS 1.0.0 functionality could be fixed to not include gml:name also.

virtual services

Yes it is valid to have namespace in a path - this is an important feature of GeoServer known as “virtual service” as it allows a single GeoServer to provide multiple geospatial web-services (one for each workspace, or even one for each layer). Previously people installed multiple copies of GeoServer on different ports in order to provide different teams their own GeoServer to work with.

  • global services: the top-level web services which list all layers. These can be disabled in global settings.
  • workspace services: publish all the layers in a workspace
  • layer services: publish just a single layer

aside: I used had a PR here merged that updates the virtual services docs. I hope it makes this easier to understand.