"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 Application Schema Support Development Plan 2010


  • This planning document outlines GeoServer app-schema development we are contemplating.
  • This document will change.
  • We do not guarantee that all or even any of the proposed work will be completed in the time frames indicated, or ever.
  • All disclaimers of warranty in the GeoServer licence apply.
  • For more information, please contact Ryan Fraser or Robert Woodcock.

Quarter 1: January 2010 to March 2010

Support data-driven polymorphism

Application schemas often specify properties that can be a variety of types. GeoServer app-schema currently requires types to be fixed at mapping time. This precludes support for data-driven polymorphism. Known use cases:

  • Implement support for data-driven polymorphism use cases.

Implement caching schema resolver

Implement a new caching schema resolver that eases testing and deployment by supporting classpath and cached download schema resolution in addition to the existing use of an OASIS Catalog.

The use of a cached download of schemas will allow users to deploy GeoServer app-schema without preparing an OASIS Catalog. Schemas will be retrieved once for each deployment.

Support for classpath resolution of application schemas will allow Java unit tests to be written that use Maven schema bundles. This avoids storing schemas in subversion, while still allowing unit tests to run without network connection. Furthermore, schema bundles are jar files that could be deployed with GeoServer, removing the need for a catalog or downloaded schemas.

Order of schema resolution:
  1. Resolve schema location in OASIS Catalog.
  2. Resolve schema location on Java classpath.
  3. Download schema from remote HTTP resource and cache it on local storage.

  • Implement caching schema resolver
  • Package GeoSciML 2.0 and dependencies as Maven artifacts to support offline unit tests.

Quarter 2: April 2010 to June 2010

Improve platform support

Get the build working on 64-bit and OpenJDK

Christian Mueller has deployed Hudson jobs that cover the range of:
  • { Sun Java 5, Sun Java 6, IBM Java 5, IBM Java 6, OpenJDK } (X) {32-bit, 64-bit }
where (X) denotes an outer product. See the discussion on the GeoServer developer list here:

The Hudson instances are available here:

We need to, at the leas,t make sure app-schema does not break any of these builds. At the moment, app-schema is a known offender in this regard. Reasons for this include:
  1. Extensive use of HashMap in core code in a way that exposes iteration order. For example, namespace and schema dependencies. HashMap iteration order is dependent on memory addresses and, while repeatable on a single platform, varies across platforms.
  2. Bad app-schema unit tests test that assume order of things like namespace declaration and schema imports.

Both are bad practices. Together they often break the build on platforms other than our reference Sun Java 5 32-bit.

  • Submit bug fixes for core code to make behaviour more stable across platforms.
  • Fix app-schema unit tests that make unwarranted assumptions about order or otherwise cause build failure on non-reference platforms.
  • Liaise with Christian Mueller and the GeoServer community to ensure that app-schema does not obstruct efforts to build on non-reference platforms.

Migrate unit tests to GeoSciML 2.0 (or later)

Existing unit tests are based on ancient unpublished GeoSciML versions stored in subversion. Once the new resolver is available, it should be possible to migrate all unit tests to use GeoSciML 2.0 or later (even a mix of these).

  • Migrate all GeoTools app-schema and GeoServer app-schema unit tests to use GeoSciML 2.0 (or later).

Implement schema-validation unit tests

Once unit tests are migrated to published GeoSciML, add unit tests that ensure that encoded responses are schema-valid.

  • Implement unit tests that use Xerces schema validation to validate GeoServer WFS response documents against unmodified GeoSciML 2.0 (or later) schemas.

Establish reference data set and test suite for complex feature WFS

Build a reference data set for testing the functionality and correctness of a complex feature WFS.

The reference data set should include:
  1. Reference data set in SQL suitable for import into PostGIS or Oracle Spatial.
  2. WFS Query documents in XML format suitable for POST submission.
  3. Annotated instance documents and or descriptions indicating the expected correct response. These need not be complete XML responses, but should provide sufficient detail to permit a developer to write an automated test to determine if the response is correct.

The reference data set, queries, and annotated responses should exercise as many polymorphism use cases and filter queries as possible. Software is only as good as its test suite.

The reference data set must be in the public domain. It is intended that the reference data set form the basis of a future CITE test suite for complex WFS. It must be unencumbered.

Implement unit tests that:
  1. Initialise (clear) a spatial database.
  2. Load the reference data set.
  3. Issue the reference queries.
  4. For each response:
    1. Schema-validate the response.
    2. Content validate the response.

If the unit tests connect to an external database, they will need to be instances of OnlineTestCase.

  1. Obtain representative test data that covers a variety of use cases, including data-driven polymorphism, multivalued properties, and denormalised input tables.
  2. Convert the test data into a portable form that can be loaded into both PostGIS and Oracle Spatial via JDBC.
  3. Write GeoServer app-schema mappings that allow GeoServer to connect to PostGIS or Oracle Spatial and deliver the reference data set as WFS feature types defined in GeoSciML 2.0 (or later).
  4. Write GeoServer app-schema-test unit tests that perform schema and content validation to ensure that the GeoServer responses match the sample instance documents.

Quarter 3: July 2010 to September 2010

Implement GML 3.2 support

GML 3.2 is the latest version of GML, and is used for many new application schemas.

  1. Migrate existing GeoTools GML 3.2 support skeleton to a new module gt-xsd-gml32.
  2. Implement gt-xsd-gml32 bindings and corresponding unit tests.
  3. Add GML 3.2 support to gt-app-schema.
  4. Write gt-app-schema unit tests to exercise this functionality.
  5. Write GeoServer app-schema-test unit tests to demonstrate GML 3.2 support.

Implement WFS 1.1 / GML 3.2 OutputFormat

The WFS 1.1 specification permits the use of an outputFormat to specify an alternate response encoding. See:

  1. Implement a GeoServer WFS 1.1 OutputFormat that delivers a GML 3.2 response. The root element of the response should be GML 3.2 FeatureCollection.
  2. Write GeoServer app-schema-test unit tests that exercise the encoding of GML 3.2 responses.

Quarter 4: October 2010 to December 2010


  • Support for 3D geometries
  • Configuration GUI
  • Refactor AppSchemaDataAccessRegistry so it is not static, and so is not broken by the impending GeoServer resource/publishing split, which would require multiple registries.


Query is broken across mapping functions - for example those that convert an internal ID into a qualified URN. This is a major limitation.

-- RobAtkinson - 2010-03-03

Supporting spatial queries over X,Y columns (aka the old geometryless datastore) is of broad interest still. Inverse mapping functions to build and decompose geometries, coupled with query across mapping functions would probably solve the problem. This could be extended to 3D point features.

-- RobAtkinson - 2010-03-03

Vocabulary cross-walk support - allowing in-memory vocab mappings instead of forcing database extensions. This would also support an element of central configuration management, with vocabs downloaded during geoserver config time, and reporting back to the enviroment via GetDomain operation (what terms from the central vocab are actually used in this database....)

-- RobAtkinson - 2010-03-03

GML3.2 support should be tested using a simple INSPIRE schema to provide an entry point to that community ASAP, then the more complex GeoSciML cases can follow as GeoSciML3 emerges.

-- RobAtkinson - 2010-03-03

It may be more realistic to schedule GML 3.2 support for Quarter 3 2010.

-- BruceSimons - 2010-03-04
Topic revision: r10 - 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).