"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

GeoServer Feedback for GeoSciML Testbed 3 Adopters

This page is for discussions related to complex feature (community schema) builds of GeoServer used for GeoSciML Testbed 3. See also:

For more general GeoServer user support questions, please use the GeoServer users mailing list:


Geoscience Australia Feedback

GA - GeoServer Issues Document - March 2008-v0.4.doc

This document details all issues that relate to GeoServer version 1.6.0-RC3 with respect to community schema support. In brief these are:
  1. Support for Complex Features;
  2. Configuration requirements before successful start-up;
  3. Schema resolution.
This document was provided by Paul Buckley of GA on 18 March 2008.

-- AlistairRitchie - 18 Mar 2008

In response to GA's issues:
  1. Support for complex features is largely complete, although many parts are still broken or untested. Development is iterative. I recommend that GA set up a server and identify detailed requirements for their configuration. Please see the download page GeoserverGeoscimlTestbed3Downloads.
  2. Code and data should be separate. I recommend using the test configuration on the downloads page to validate that your servlet is functioning. Just unpack the configuration zip file, and edit the geoserver web.xml to point at it.
  3. Schema referenced via include or import statements are now honoured. The test mapping files I use reference only the top level schema. There are still some oddities.
-- BenCaradocDavies - 18 Mar 2008

MappedFeature/shape values

When prompted for an example of a polygon for a MappedFeature/shape value the following excerpt from a GeoSciML v2 instance document (GA_MappedFeature_LithologicUnit_v2.xml) was provided:
<MappedFeature gml:id=...>
        <gml:Polygon srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
                    <gml:coordinates decimal="." cs="," ts="">
This represents quite a substantial change in the behaviour of GeoServer as it currently uses Well Known Text (WKT) to encode geometry data, rather than this expanded GML representation. For example:
<MappedFeature gml:id=...>
        POLYGON((141.94618067 -36.59701912, 141.94828905 -36.60132373,  141.94951633,-36.60617081, ...))
Do we want to use the expanded GML representation for Testbed 3, or can we use WKT values?

If the answer is 'GML representation' then this will have to be added as an high priority use case for GeoServer development. (Note that it is definitely a use case, as in future we will want to use GML geometry types not able to be represented using WKT.)

What confuses me is that it seems to be possible in existing implementations of GeoServer. Check out the response to a LithologicUnit request on GA's GeoServer WFS: http://www.ga.gov.au/geoserver_geosciml/wfs?request=getFeature&maxFeatures=1&typeName=gsml:LithologicUnitType

Comments please ...

-- AlistairRitchie - 19 Mar 2008

I have tested and confirms that the WKT encoding is produced when using a PostGIS data store, as well as when using a property file data store.

-- BenCaradocDavies - 20 Mar 2008

Definitely should be GML geometries. WKT representation would not validate against GML xsd anyway.

-- EricBoisvert - 20 Mar 2008

Validation is another problem. There is insufficient information in the WFS responses currently generated by GeoServer to schema-validate them. A client would need knowledge of an wrapper schema in use. There is also an alleged complication that the features belong to a different schema, and so we would have to validate XML fragments. I think that some sort of schema-validation would be a very good idea.

-- BenCaradocDavies - 25 Mar 2008

Am I right in saying there is enough information in the WFS response to validate against the community schema used, but it is missing the key information about the wrapper schema that was used to define the FeatureType being returned? If we have that we have enough information for schema validation?

-- AlistairRitchie - 25 Mar 2008

I'm not sure I understand what is the issue. Are you (Ben) implying that there is no way to insert a "schemaLocation" attribute in GeoServer or that GeoServer does not do it right now, it refers to the auto generated schema. (I assume the "schema wrapper" is the document that maps the DB to the community schema)

-- EricBoisvert - 25 Mar 2008

Eric, the schema wrapper is a thin layer (or "profile") adding namespaces and elements to the core gsml elements. This is different to the database-to-feature-type mapping, which is not sent to nor required by the client. The WFS response contains a schemaLocation for neither the wrapper nor the core gsml schema. I do not know if it can be inserted. The validation problem is deeper, and has been discussed in the following emails on 2008-03-25 (apologies for publishing without asking):

Rob Atkinson wrote:

FYI, this means that the response will have to be validated as a document fragment - (the top level FeatureCollection will need to be ignored).

This sort of validation is not trivial, since you will need to propagate namespace declarations from the top level, extract the fragment etc. It may not be too hard to do this programattically with some library that will do this for you, but I know of no tools that do it neatly. (this may just be ignorance - I tend to only use Oxygen these days)

The alternative is a "clone and modify" of the OGC FeatureCollection schema, to specify the type of returned features - which is ugly!


Alistair Richie replied:

> the top level FeatureCollection will need to be ignored

Because it's a Geoserver wrapper schema?

Rob Atkinson wrote:

No, because the WFS spec says thats how responses are wrapped.

(I'm now of the opinion this is a mistake - it allows some funkiness in the packaging (ie the response could be a mix of things that match the query, and a set of other objects that may be referenced, for example, but its massively overcomplicating the 80% case)


-- BenCaradocDavies - 26 Mar 2008

Hmm.. I though it was simply a matter of adding schema locations for both WFS and GeoSciML and validator would be happy

<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection xmlns="urn:cgi:xmlns:CGI:GeoSciML:2.0" 
xsi:schemaLocation="urn:cgi:xmlns:CGI:GeoSciML:2.0 http://www.geosciml.org/schemas/geosciml/2.0/geosciml.xsd http://www.opengis.net/wfs  http://schemas.opengis.net/wfs/1.1.0/wfs.xsd">
      <gsml:Foliation gml:id="id_Bedding01">
     <!-- stuff removed to clarity, if this is ever possible with XML-->

This works fine with XMLSpy...

Of course, this is academic, since not all required schemas are available from public sites (are they ?)

-- EricBoisvert - 26 Mar 2008

I'm getting confused about the issue here as well:
  • Responses to requests against the current build of GeoServer provided by Ben include a location for wfs.xsd, and I can get XMLSpy to validate them OK. (There is a problem with the wrapper schema location to be dealt with - read: hacked - before you can get it to validate.)
  • Eric's solution appears to be implemented, at least for the WFS schema. Why do we have to ignore wfs:FeatureCollection?
  • Is the existence of a "schema wrapper [...] adding namespaces and elements to the core gsml elements" which is (potentially?) exposed to the client making the request the main issue here?

-- AlistairRitchie - 27 Mar 2008

oh, wait.. are we confusing the validation made by the XMLBean component (to create the internal representation GeoServer makes of the model) and the validation of document that is finally generated ?

-- EricBoisvert - 27 Mar 2008

From the user perspective: validation of the document that is finally generated.

-- AlistairRitchie - 27 Mar 2008

More on shape encoding

Email from Simon Cox on 2008-03-25:

Please note, all, that, while gml:coordinates is indeed GML 3 schema-valid, it is deprecated in favour of gml:pos.

So if it is possible to configure your server to deliver gml:pos this is preferable and more future-proofed.


-- BenCaradocDavies - 28 Mar 2008

Shape encoding now GML

geoserver-gsmltb3.2008-04-09.2.war encodes shapes as GML not WKT. I assume that the use of gml:posList is consistent with Simon's recommendation?

-- BenCaradocDavies - 09 Apr 2008

GSV feedback on build geoserver-gsmltb3.2008-05-12.1

GetCapabilities Request Error

Get an error when trying to execute a GetCapabilities request.


<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows http://eda087485:8080/geoserver-gsmltb3.2008-05-12.1/schemas/ows/1.0.0/owsExceptionReport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
    <ows:Exception exceptionCode="NoApplicableCode">
        <ows:ExceptionText>java.io.IOException null Translator error null</ows:ExceptionText>

DescribeFeatureType Request Error

Discovered this executing a getFeature request in XMLSpy. The response didn't validate, it failed when it trying to parse the DescribeFeatureType request for GeoSciML2.0 in xsi:schemaLocation:


XMLSpy Error
Document at location
(namespace 'urn:cgi:xmlns:CGI:GeoSciML:2.0')  is not a schema.
Nope, it is an exception report...
<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/ows http://eda087485:8080/geoserver-gsmltb3.2008-05-12.1/schemas/ows/1.0.0/owsExceptionReport.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
  <ows:Exception exceptionCode="NoApplicableCode">
        java.lang.UnsupportedOperationException: not implemented yet

maxFeature does not constrain results

Can't restrict the number of features returned with the maxFeatures filter. It always returns an unfiltered response (for both the PostGIS and Oracle feature types):


<wfs:FeatureCollection numberOfFeatures="2" ...

BenCaradocDavies wonders if this may be related to: http://jira.codehaus.org/browse/GEOS-1910

-- AlistairRitchie - 15 May 2008

Please note that all these defects are now listed on GeoserverGeoscimlTestbed3Issues.

-- BenCaradocDavies - 23 May 2008

Excerpt from email from Rob Atkinson on 2008-06-03, in response to a question on GeoServer support for "multiple" properties (e.g. features nested in features):

A feature may have only one property with an arbitrary (data-determined) number of multiple values. This property may be arbitrarily complex but not include further data-driven multiple values.

Any property may have multiple values may be mapped (by using an index number) from multiple database columns, including nested properties of multi-valued properties, but these have pre-determined multiplicities as a result of using mapping indices.

This is a limitation that can be removed with appropriate level of effort. The data model and serialisation strategies should be ready if the feature building code is updated.

-- BenCaradocDavies - 04 Jun 2008
Topic attachments
I Attachment Action Size Date Who Comment
GA_-_GeoServer_Issues_Document_-_March_2008-v0.4.docdoc GA_-_GeoServer_Issues_Document_-_March_2008-v0.4.doc manage 58.0 K 18 Mar 2008 - 10:36 AlistairRitchie GA issues rel. to community schema support in GeoServer v1.6.0-RC3.
Topic revision: r25 - 15 Oct 2010, UnknownUser

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).