[Geoserver-devel] "name" attribute disappearing in DescribeFeatureType: regression since 2.0.2?

GeoServer GeoServer Developer
1

Hi,
GeoServer 2.1.x changed behavior compared to 2.0.2 when it comes to handling the
GML built in attributes for simple features: 2.0.2 used to report “name” in the feature
type own namespace, but 2.1.x is instead assuming “name” is in the gml namespace
instead. Compare the 2.1.x result:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)" xmlns:cite="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)" xmlns:gml="[http://www.opengis.net/gml](http://www.opengis.net/gml)" xmlns:it.geosolutions="[http://www.geo-solutions.it](http://www.geo-solutions.it)" xmlns:nurc="[http://www.nurc.nato.int](http://www.nurc.nato.int)" xmlns:sde="[http://geoserver.sf.net](http://geoserver.sf.net)" xmlns:sf="[http://www.openplans.org/spearfish](http://www.openplans.org/spearfish)" xmlns:tiger="[http://www.census.gov](http://www.census.gov)" xmlns:topp="[http://www.openplans.org/topp](http://www.openplans.org/topp)" elementFormDefault="qualified" targetNamespace="[http://www.openplans.org/topp](http://www.openplans.org/topp)">
  <xsd:import namespace="[http://www.opengis.net/gml](http://www.opengis.net/gml)" schemaLocation="[http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd](http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd)"/>
  <xsd:complexType name="polygons_5Type">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="wkb_geometry" nillable="true" type="gml:GeometryPropertyType"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="date" nillable="true" type="xsd:date"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="test" nillable="true" type="xsd:string"/>


          <xsd:element maxOccurs="1" minOccurs="0" name="test2" nillable="true" type="xsd:string"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="polygons_5" substitutionGroup="gml:_Feature" type="topp:polygons_5Type"/>
</xsd:schema>

with the 2.0.2 result:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)" xmlns:cite="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)" xmlns:gml="[http://www.opengis.net/gml](http://www.opengis.net/gml)" xmlns:it.geosolutions="[http://www.geo-solutions.it](http://www.geo-solutions.it)" xmlns:nurc="[http://www.nurc.nato.int](http://www.nurc.nato.int)" xmlns:sde="[http://geoserver.sf.net](http://geoserver.sf.net)" xmlns:sf="[http://www.openplans.org/spearfish](http://www.openplans.org/spearfish)" xmlns:tiger="[http://www.census.gov](http://www.census.gov)" xmlns:topp="[http://www.openplans.org/topp](http://www.openplans.org/topp)" elementFormDefault="qualified" targetNamespace="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)">
  <xsd:import namespace="[http://www.opengis.net/gml](http://www.opengis.net/gml)" schemaLocation="[http://localhost:8080/geoserver_202/schemas/gml/3.1.1/base/gml.xsd](http://localhost:8080/geoserver_202/schemas/gml/3.1.1/base/gml.xsd)"/>
  <xsd:complexType name="polygons_5Type">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="name" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="wkb_geometry" nillable="true" type="gml:GeometryPropertyType"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="date" nillable="true" type="xsd:date"/>


          <xsd:element maxOccurs="1" minOccurs="0" name="test" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="test2" nillable="true" type="xsd:string"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="polygons_5" substitutionGroup="gml:_Feature" type="cite:polygons_5Type"/>
</xsd:schema>

This is breaking applications relying on DescribeFeatureType to discover the
available attributes that were working with 2.0.x.

As far as I can see there is no flag that can be set, we just switched hard to the
new behavior.

I already had one company I’m following switch back to 2.0.x because of this…
not nice. At the very least this behavior should be admin configurable imho.

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

2

On Thu, Mar 10, 2011 at 1:16 PM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

I already had one company I’m following switch back to 2.0.x because of this…
not nice. At the very least this behavior should be admin configurable imho.

Opinions?

Ah, noticed another detail, the result of DescribeFeatureType is now also somewhat inconsistent with
rest config, which is reporting “name” as an unqualified attribute, and with GetFeatureInfo in gml2
format, which is reporting in the response
topp:namethe name</topp:name>
instead of gml:name, but referring back to the describe feature type result for its schema, which
as shown above says otherwise (so this makes the feature info gml2 schema invalid)

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

3

Hmm… I am unaware of anything we did to explicitly change this behaviour. It was my understanding that gml3 always maps an attribute named “name”, to gml:name. Although with gml 2 this is configurable. WHat do the corresponding GetFeature outputs look like? Are they consistent with the DescribeFeatureType schema?

I think an option to control this is fine… we just need to isolate what the change was.

On Thu, Mar 10, 2011 at 4:16 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
GeoServer 2.1.x changed behavior compared to 2.0.2 when it comes to handling the
GML built in attributes for simple features: 2.0.2 used to report “name” in the feature
type own namespace, but 2.1.x is instead assuming “name” is in the gml namespace
instead. Compare the 2.1.x result:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)" xmlns:cite="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)" xmlns:gml="[http://www.opengis.net/gml](http://www.opengis.net/gml)" xmlns:it.geosolutions="[http://www.geo-solutions.it](http://www.geo-solutions.it)" xmlns:nurc="[http://www.nurc.nato.int](http://www.nurc.nato.int)" xmlns:sde="[http://geoserver.sf.net](http://geoserver.sf.net)" xmlns:sf="[http://www.openplans.org/spearfish](http://www.openplans.org/spearfish)" xmlns:tiger="[http://www.census.gov](http://www.census.gov)" xmlns:topp="[http://www.openplans.org/topp](http://www.openplans.org/topp)" elementFormDefault="qualified" targetNamespace="[http://www.openplans.org/topp](http://www.openplans.org/topp)">
  <xsd:import namespace="[http://www.opengis.net/gml](http://www.opengis.net/gml)" schemaLocation="[http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd](http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd)"/>
  <xsd:complexType name="polygons_5Type">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="wkb_geometry" nillable="true" type="gml:GeometryPropertyType"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="date" nillable="true" type="xsd:date"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="test" nillable="true" type="xsd:string"/>


          <xsd:element maxOccurs="1" minOccurs="0" name="test2" nillable="true" type="xsd:string"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="polygons_5" substitutionGroup="gml:_Feature" type="topp:polygons_5Type"/>
</xsd:schema>

with the 2.0.2 result:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)" xmlns:cite="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)" xmlns:gml="[http://www.opengis.net/gml](http://www.opengis.net/gml)" xmlns:it.geosolutions="[http://www.geo-solutions.it](http://www.geo-solutions.it)" xmlns:nurc="[http://www.nurc.nato.int](http://www.nurc.nato.int)" xmlns:sde="[http://geoserver.sf.net](http://geoserver.sf.net)" xmlns:sf="[http://www.openplans.org/spearfish](http://www.openplans.org/spearfish)" xmlns:tiger="[http://www.census.gov](http://www.census.gov)" xmlns:topp="[http://www.openplans.org/topp](http://www.openplans.org/topp)" elementFormDefault="qualified" targetNamespace="[http://www.opengeospatial.net/cite](http://www.opengeospatial.net/cite)">
  <xsd:import namespace="[http://www.opengis.net/gml](http://www.opengis.net/gml)" schemaLocation="[http://localhost:8080/geoserver_202/schemas/gml/3.1.1/base/gml.xsd](http://localhost:8080/geoserver_202/schemas/gml/3.1.1/base/gml.xsd)"/>
  <xsd:complexType name="polygons_5Type">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="name" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="wkb_geometry" nillable="true" type="gml:GeometryPropertyType"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="date" nillable="true" type="xsd:date"/>


          <xsd:element maxOccurs="1" minOccurs="0" name="test" nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="test2" nillable="true" type="xsd:string"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="polygons_5" substitutionGroup="gml:_Feature" type="cite:polygons_5Type"/>
</xsd:schema>

This is breaking applications relying on DescribeFeatureType to discover the
available attributes that were working with 2.0.x.

As far as I can see there is no flag that can be set, we just switched hard to the
new behavior.

I already had one company I’m following switch back to 2.0.x because of this…
not nice. At the very least this behavior should be admin configurable imho.

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

On Thu, Mar 10, 2011 at 4:22 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Mar 10, 2011 at 1:16 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

I already had one company I’m following switch back to 2.0.x because of this…
not nice. At the very least this behavior should be admin configurable imho.

Opinions?

Ah, noticed another detail, the result of DescribeFeatureType is now also somewhat inconsistent with
rest config, which is reporting “name” as an unqualified attribute, and with GetFeatureInfo in gml2
format, which is reporting in the response
topp:namethe name</topp:name>
instead of gml:name, but referring back to the describe feature type result for its schema, which
as shown above says otherwise (so this makes the feature info gml2 schema invalid)

Sorry… I don’t quite understand. rest config reporting as an unqualified attribute? And WMS GetFeaturInfo creates a GML2 document that points back to a GML3 DFT schema?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

On Thu, Mar 10, 2011 at 6:16 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmm... I am unaware of anything we did to explicitly change this behaviour. It was my understanding that gml3 always maps an attribute named "name", to gml:name. Although with gml 2 this is configurable. WHat do the corresponding GetFeature outputs look like? Are they consistent with the DescribeFeatureType schema?
I think an option to control this is fine... we just need to isolate what the change was.

I see it happening on both GML2 and GML3, but you're right, the
behavior is different.
GML2: DescribeFeatureType does not list the "name" attribute (it did
in 2.0.2) but the
GetFeature output says
<topp:name>the name</topp:name>

so it is inconsistent, it's actually generating gml that would not validate

GML3: DescribeFeatureType does not list the "name" attribute but the output uses
gml:name (in 2.0.2 it used topp:name in both)

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

6

On Thu, Mar 10, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Thu, Mar 10, 2011 at 4:22 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Mar 10, 2011 at 1:16 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

I already had one company I'm following switch back to 2.0.x because of
this...
not nice. At the very least this behavior should be admin configurable
imho.
Opinions?

Ah, noticed another detail, the result of DescribeFeatureType is now also
somewhat inconsistent with
rest config, which is reporting "name" as an unqualified attribute, and
with GetFeatureInfo in gml2
format, which is reporting in the response
<topp:name>the name</topp:name>
instead of gml:name, but referring back to the describe feature type
result for its schema, which
as shown above says otherwise (so this makes the feature info gml2 schema
invalid)

Sorry... I don't quite understand. rest config reporting as an unqualified
attribute? And WMS GetFeaturInfo creates a GML2 document that points back to
a GML3 DFT schema?

The GML2 document points back to the GML2 DescribeFeatureType, that does not
include the name attribute in the schema, so it's invalid.

Ah, btw, where is the GML2 treatment of "name" configuration?
And by the same token, shouldn't we have an equivalent GML3 one?
Whether to use topp:name or gml:name against simple features seems like
an arbitrary choice to me, what was the reason to do that?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

7

On Thu, Mar 10, 2011 at 10:42 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Mar 10, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Thu, Mar 10, 2011 at 4:22 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Mar 10, 2011 at 1:16 PM, Andrea Aime
<andrea.aime@anonymised.com…> wrote:

I already had one company I’m following switch back to 2.0.x because of
this…
not nice. At the very least this behavior should be admin configurable
imho.
Opinions?

Ah, noticed another detail, the result of DescribeFeatureType is now also
somewhat inconsistent with
rest config, which is reporting “name” as an unqualified attribute, and
with GetFeatureInfo in gml2
format, which is reporting in the response
topp:namethe name</topp:name>
instead of gml:name, but referring back to the describe feature type
result for its schema, which
as shown above says otherwise (so this makes the feature info gml2 schema
invalid)

Sorry… I don’t quite understand. rest config reporting as an unqualified
attribute? And WMS GetFeaturInfo creates a GML2 document that points back to
a GML3 DFT schema?

The GML2 document points back to the GML2 DescribeFeatureType, that does not
include the name attribute in the schema, so it’s invalid.

Ah, btw, where is the GML2 treatment of “name” configuration?
And by the same token, shouldn’t we have an equivalent GML3 one?
Whether to use topp:name or gml:name against simple features seems like
an arbitrary choice to me, what was the reason to do that?

If I remember correctly there is a setGmlPrefixing method on FeatureTranformer which controls whether gml attributes are prefixed with gml or the application schema namespace.

I totally agree that it would be most appropriate to have an option to configure this behaviour, both for gml2 and gml3. The reason gml3/wfs 1.1 follows the behaviour it does is that the cite testing require the “name” attribute to be the one from the gml namespace.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

8

On Thu, Mar 10, 2011 at 7:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

If I remember correctly there is a setGmlPrefixing method on
FeatureTranformer which controls whether gml attributes are prefixed with
gml or the application schema namespace.

Ok, that controls the output of GetFeature, but the issue here seems to be
the output of DescribeFeatureType, which does not have the name attribute
when it should be there

I totally agree that it would be most appropriate to have an option to
configure this behaviour, both for gml2 and gml3. The reason gml3/wfs 1.1
follows the behaviour it does is that the cite testing require the "name"
attribute to be the one from the gml namespace.

Scratching head... 2.0.2 does not use gml:name, uses topp:name, but afaik
it passed cite tests. Did the tests change in the meantime?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

9

On Thu, Mar 10, 2011 at 8:08 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Thu, Mar 10, 2011 at 7:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

If I remember correctly there is a setGmlPrefixing method on
FeatureTranformer which controls whether gml attributes are prefixed with
gml or the application schema namespace.

Ok, that controls the output of GetFeature, but the issue here seems to be
the output of DescribeFeatureType, which does not have the name attribute
when it should be there

I totally agree that it would be most appropriate to have an option to
configure this behaviour, both for gml2 and gml3. The reason gml3/wfs 1.1
follows the behaviour it does is that the cite testing require the "name"
attribute to be the one from the gml namespace.

Scratching head... 2.0.2 does not use gml:name, uses topp:name, but afaik
it passed cite tests. Did the tests change in the meantime?

Btw, if you want to reproduce use the attached sql dump file (I wanted to give
you a shapefile but "description", another example of skipped property that
won't fit the column name length limitations).

In face of this db schema:

   Colonna | Tipo |
Modificatori
--------------+------------------------+---------------------------------------------------------------
gid | integer | not null preimpostato
nextval('polygons_5_gid_seq'::regclass)
name | character varying(255) |
wkb_geometry | geometry |
date | date |
test | character(255) |
test2 | text |
xyz | character varying |
abc | character varying(255) |
description | character varying(255) |

the WFS 1.0 DescribeFeatureType is:

<xsd:schema elementFormDefault="qualified"
targetNamespace="http://www.openplans.org/topp&quot;
xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot;
xmlns:cite="http://www.opengeospatial.net/cite&quot;
xmlns:gml="http://www.opengis.net/gml&quot;
xmlns:it.geosolutions="http://www.geo-solutions.it"
xmlns:nurc="http://www.nurc.nato.int"
xmlns:sde="http://geoserver.sf.net"
xmlns:sf="http://www.openplans.org/spearfish&quot;
xmlns:tiger="http://www.census.gov"
xmlns:topp="http://www.openplans.org/topp&quot;&gt;
<xsd:import namespace="http://www.opengis.net/gml&quot;
schemaLocation="http://localhost:8080/geoserver/schemas/gml/2.1.2/feature.xsd&quot;/&gt;
<xsd:complexType name="polygons_5Type">
<xsd:complexContent>
<xsd:extension base="gml:AbstractFeatureType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="wkb_geometry"
nillable="true" type="gml:GeometryPropertyType"/>
<xsd:element maxOccurs="1" minOccurs="0" name="date" nillable="true"
type="xsd:date"/>
<xsd:element maxOccurs="1" minOccurs="0" name="test" nillable="true"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="test2" nillable="true"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="xyz" nillable="true"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="abc" nillable="true"
type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="polygons_5" substitutionGroup="gml:_Feature"
type="topp:polygons_5Type"/>
</xsd:schema>

and the result of Geteature is:

<wfs:FeatureCollection
xsi:schemaLocation="http://www.openplans.org/topp
http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp%3Apolygons_5
http://www.opengis.net/wfs
http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd&quot;
xmlns="http://www.opengis.net/wfs&quot;
xmlns:wfs="http://www.opengis.net/wfs&quot;
xmlns:topp="http://www.openplans.org/topp&quot;
xmlns:gml="http://www.opengis.net/gml&quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
<gml:boundedBy>
<gml:null>unknown</gml:null>
</gml:boundedBy>
<gml:featureMember>
<topp:polygons_5 fid="polygons_5.3">
<topp:name>the_name</topp:name>
<topp:wkb_geometry>
<gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt;
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates decimal="." cs="," ts=" "
xmlns:gml="http://www.opengis.net/gml&quot;&gt;174\.36216079,\-36\.70019588
174.28250991,-36.61977587 174.28250991,-36.61977587
174.36216079,-36.70019588</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</topp:wkb_geometry>
<topp:description>desc</topp:description>
</topp:polygons_5>
</gml:featureMember>
</wfs:FeatureCollection>

See topp:description and topp:name?

Actually the GML2 output is the expected one, it's the DFT and all the
WFS 1.1 outputs that
have changed since 2.0.2...

Cheers
Andrea

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

(attachments)

polygons_5.sql (12.7 KB)

10

Hi,

I noticed this problem as well yesterday when I ran getFeature request with
name and description columns.
Using WFS 1.0.0 for simple features, it returned name and description with
my custom namespace.
Using WFS 1.1.0, however, they were encoded as gml:name and gml:description.
I was using December build though, so I thought it might already be fixed in
trunk, and I have not tested it with the latest code. Niels' patch might
have fixed this? http://jira.codehaus.org/browse/GEOS-4382
It was committed mid February in trunk.

Rini

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/name-attribute-disappearing-in-DescribeFeatureType-regression-since-2-0-2-tp6157475p6160199.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

11

On Fri, Mar 11, 2011 at 4:23 AM, Rini Angreani <Rini.Angreani@anonymised.com> wrote:

Hi,

I noticed this problem as well yesterday when I ran getFeature request with
name and description columns.
Using WFS 1.0.0 for simple features, it returned name and description with
my custom namespace.
Using WFS 1.1.0, however, they were encoded as gml:name and gml:description.
I was using December build though, so I thought it might already be fixed in
trunk, and I have not tested it with the latest code. Niels' patch might
have fixed this? http://jira.codehaus.org/browse/GEOS-4382
It was committed mid February in trunk.

I don't think so, I was running yesterday's svn checkout to reproduce
those issues

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

12

Thanks for the steps to reproduce andrea. I should have time end of day today to look at this.

On Thu, Mar 10, 2011 at 11:53 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Mar 11, 2011 at 4:23 AM, Rini Angreani Rini.Angreani@anonymised.com wrote:

Hi,

I noticed this problem as well yesterday when I ran getFeature request with
name and description columns.
Using WFS 1.0.0 for simple features, it returned name and description with
my custom namespace.
Using WFS 1.1.0, however, they were encoded as gml:name and gml:description.
I was using December build though, so I thought it might already be fixed in
trunk, and I have not tested it with the latest code. Niels’ patch might
have fixed this? http://jira.codehaus.org/browse/GEOS-4382
It was committed mid February in trunk.

I don’t think so, I was running yesterday’s svn checkout to reproduce
those issues

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

13

On Fri, Mar 11, 2011 at 5:28 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks for the steps to reproduce andrea. I should have time end of day
today to look at this.

It seems the situation vs name and description is also broken on 2.0.x somehow

Making a request against the cite tests EntitéGenerique feature type
we get in the
output:

<sf:EntitéGénérique gml:id="EntitéGénérique.f004">
      <gml:description>description-f004</gml:description>
      <gml:name>name-f004</gml:name>
      <gml:boundedBy>
        <gml:Envelope srsDimension="2"
          srsName="urn:x-ogc:def:crs:EPSG:4326">
          <gml:lowerCorner>60.5 0.0</gml:lowerCorner>
          <gml:upperCorner>64.0 6.25</gml:upperCorner>
        </gml:Envelope>
      </gml:boundedBy>
      <sf:description>description-f004</sf:description>
      <sf:name>name-f004</sf:name>
      <sf:attribut.Géométrie>
        <gml:Polygon srsDimension="2"
          srsName="urn:x-ogc:def:crs:EPSG:4326">
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList>60.5 0.0 64.0 0.0 64.0 6.25 60.5 6.25 60.5
                0.0</gml:posList>
            </gml:LinearRing>
          </gml:exterior>
          <gml:interior>
            <gml:LinearRing>
              <gml:posList>61.5 2.0 62.5 2.0 62.0 4.0 61.5 2.0</gml:posList>
            </gml:LinearRing>
          </gml:interior>
        </gml:Polygon>
      </sf:attribut.Géométrie>
      <sf:boolProperty>true</sf:boolProperty>
      <sf:str4Property>abc3</sf:str4Property>
      <sf:featureRef>name-f003</sf:featureRef>
    </sf:EntitéGénérique>

See how name and description are reported both in the gml and sf namespaces,
the test complains it's not expecting sf:name and sf:description ...
However the describeFeatureType 1.1 reports:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot;
xmlns:gml="http://www.opengis.net/gml&quot;
xmlns:it.geosolutions="http://www.geo-solutions.it"
xmlns:sf="http://cite.opengeospatial.org/gmlsf&quot;
elementFormDefault="qualified"
targetNamespace="http://cite.opengeospatial.org/gmlsf&quot;&gt;
  <xsd:import namespace="http://www.opengis.net/gml&quot;
schemaLocation="http://localhost:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd&quot;/&gt;
  <xsd:complexType name="EntitéGénériqueType">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="description"
nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="name"
nillable="true" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0"
name="attribut.Géométrie" nillable="true"
type="gml:GeometryPropertyType"/>

          <xsd:element maxOccurs="1" minOccurs="1" name="boolProperty"
nillable="false" type="xsd:boolean"/>
          <xsd:element maxOccurs="1" minOccurs="1" name="str4Property"
nillable="false" type="xsd:string"/>
          <xsd:element maxOccurs="1" minOccurs="0" name="featureRef"
nillable="true" type="xsd:string"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="EntitéGénérique" substitutionGroup="gml:_Feature"
type="sf:EntitéGénériqueType"/>
</xsd:schema>

so in my understanding the above gml, even if odd, should be valid,
since name and description
were also declared in the sf namespace. However the cite test complains:

Messages from parser p:XMLValidatingParser.GMLSF1:
        Validation error:
  cvc-complex-type.2.4.a: Invalid content was found starting with
element 'sf:description'. One of
'{"http://cite.opengeospatial.org/gmlsf&quot;:attribut\.Géométrie\}' is
expected.
Validation error:
  cvc-complex-type.2.4.a: Invalid content was found starting with
element 'sf:description'. One of
'{"http://cite.opengeospatial.org/gmlsf&quot;:attribut\.Géométrie\}' is
expected.
2 validation errors detected.

(the specific test is wfs:wfs-1.1.0-Basic-GetFeature-tc29.4)

Ah btw, the WFS 1.0 tests did run fine, no failures there

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

14

Rini saw different behaviour (different encoded name) in WFS 1.1 and WFS 1.0.

On 12/03/11 01:20, Andrea Aime wrote:

(the specific test is wfs:wfs-1.1.0-Basic-GetFeature-tc29.4)
Ah btw, the WFS 1.0 tests did run fine, no failures there

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

15

Looking at the situation here is what I found (which really just sums up everyones findings).

2.0.x:

WFS 1.1/GML3 duplicates any attributes that come from abstract feature type like name and description. Found the bug and committed the fix on 2.0.x.

2.1.x:

WFS 1.0 GetFeature is inconsistent with regard to it’s DescribeFeatureType output. Or vice versa. The reason is that historically GML2 output always maps these attributes to the app schema namespace, unless running in cite compliant mode in which it maps them to the gml namespace. Whereas the DFT output always maps them to gml. A straight forward and short term fix would be to do a check in the DFT for GML2 and non cite compliance. If that condition holds then we don’t map the attributes to gml.

A better longer term fix would be to make this behaviour configurable for both WFS 1.0 and WFS 1.1 adding a config option to GMLInfo to control the behaviour for the various versions. Making the defaults mirror the behaviour of the individual versions today. That is in GML2 we would by default map the attributes to the app schema namespace, and in GML3 the default would be not to map them to the app schema namespace. I started on a patch for this and it should be pretty straight forward, but would need a general consensus and review in order to get it into the 2.1.0 release.

On Sun, Mar 13, 2011 at 7:04 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com…> wrote:

Rini saw different behaviour (different encoded name) in WFS 1.1 and WFS 1.0.

On 12/03/11 01:20, Andrea Aime wrote:

(the specific test is wfs:wfs-1.1.0-Basic-GetFeature-tc29.4)
Ah btw, the WFS 1.0 tests did run fine, no failures there

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

16

On Mon, Mar 14, 2011 at 4:50 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Looking at the situation here is what I found (which really just sums up
everyones findings).
2.0.x:
WFS 1.1/GML3 duplicates any attributes that come from abstract feature type
like name and description. Found the bug and committed the fix on 2.0.x.

Aah, good, that should address a number of cite test failures in WFS 1.1

2.1.x:
WFS 1.0 GetFeature is inconsistent with regard to it's DescribeFeatureType
output. Or vice versa. The reason is that historically GML2 output always
maps these attributes to the app schema namespace, unless running in cite
compliant mode in which it maps them to the gml namespace. Whereas the DFT
output always maps them to gml. A straight forward and short term fix would
be to do a check in the DFT for GML2 and non cite compliance. If that
condition holds then we don't map the attributes to gml.

Yep, that should get us back in a consistent state

A better longer term fix would be to make this behaviour configurable for
both WFS 1.0 and WFS 1.1 adding a config option to GMLInfo to control the
behaviour for the various versions. Making the defaults mirror the behaviour
of the individual versions today. That is in GML2 we would by default map
the attributes to the app schema namespace, and in GML3 the default would be
not to map them to the app schema namespace. I started on a patch for this
and it should be pretty straight forward, but would need a
general consensus and review in order to get it into the 2.1.0 release.

Sounds like a good plan. Can I help in some way?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------