GML Consumption Library

TechnicalNotes

ChangedTypeHierarchies

Overview

  • To create tools/libraries to aid in the consumption of GML application schemas

Current Issues Facing Consumer

  1. Interpretation of a new information model can be difficult
    • Reconciling the differences between the conceptual model and implementation is an involved process; there has to be considerations to what feature types are exposed and the vocabulary of the content.
  2. Generating a WFS query, whilst standardised, is often a repetitive task
    • By WFS queries we mean both the actual OGC WFS queries and their optional OGC filters.
  3. Interpreting the structure of a WFS response as it pertains to GML and other application schemas can be rather difficult.
    • Also a model may be defined piecewise, that is the response may be built from several distinct features tied together with xlink:href attributes.
Issue #1 isn't something that can be easily addressed as it is something that is very application schema/information model specific. There are also a number of existing applications and tools to aid with the interpretation of models and schemas.

Issue #2 is, on face value, a relatively simple problem, however the actual standards for wfs and filters are extremely technical. Consumers are likely to 'reinvent the wheel' in regards to writing software to generate these types of requests and are likely to make a number of subtle errors. Having a complete library for generating these standardised requests would be ideal.

Issue #3 could be aided by supporting a number of common application schemas such as GeoSciML and possibly ERML. The actual response structure issues will need to be addressed with technical solutions/support.

Supported Usecases

Request Building

Building OGC Filters

Preconditions

The consumer is aware of the parts of the model they wish to filter and how they would like the filter to be structured.

eg: The consumer knows which attribute(s) of the feature type(s) they want to query and how the various queries will be logically tied together. i.e. They are at a stage where they could programmatically define their query (just not necessarily using the filter standard).

Use Case
required

The consumption application will be able to use primitive objects representing filter components to generate their query. The resulting query should be usable in conjunction with the WFS query builder.

ie: The consumer should be able to build a series of !PropertyIsEqualTo classes and apply logic by attaching them to instances of And and Or classes.

Use Case
optional

The consumption application may wish to shortcut the above by using a string based query language that could be parsed and interpreted. A suitable definition of this query language may already be defined.

eg: Instead of building objects, supply a string "(myproperty = 123) AND (@myattribute = 'literal')"

It should be noted that the vast majority of this usecase is already supported by existing libraries.

Building WFS Queries

Preconditions

That the consuming application knows which feature type they wish to query and any constraints in the form of filters/response types are known.

eg: The application can list the feature type, maximum number of features, OGC filter and expected spatial reference systems

Use Case
required

The consuming application will be able to programmatically create a HTTP method by specifying:

  • The WFS URL
  • The feature type
  • [Optional] The filter constraint in the form of a Filter object
  • Output spatial reference system
  • maximum number of features (and optional pagination info for WFS 2.0)

The method that is generated above, when executed, should return some form of a response object outlining the result of the request and any features returned.

The returned features should be in the form of a standard object type (eg - Feature) that may be further subclassed into application schema specific objects. eg Mines from the ERML model or Boreholes from the GeoSciML model. Unknown models should be treated as basic 'complex features'

Interpret a response

Parsing information model

Preconditions A request has been made to a WFS and a successful response returned.
Use case
required

A typical WFS response comes in the form of an XML document consisting of 1 or more feature instances. The consumption application should be able to work with 'Feature' objects or application schema specific extensions where possible. i.e. The WFS response should be interpreted as a series of Feature or subclass objects, not as an XML document.

The basic feature object should be 'useable' in the sense that all attributes, values and children are discoverable and accessible.

The following models are suitable for our testing requirements because they demonstrate the necessary complexities:

  • !GeoSciML
  • ERML
Use case
optional

Parsing of the information model is to be achieved in a generic manner; support for new schemata can be added by making user-defined classes extend particular interfaces.

eg: If a consumer has their own community agreed schema, there should be an interface(s) that they can implement which would allow their specific schema to be supported by the geotools code for mapping XML documents to POJOs

Traversing xlinks

Preconditions

The user has 1 or more features from a WFS request. These features may have 1 or more references to external features/models which are not encoded inline and are instead encoded by reference using xlink:href attributes. The IDs in the href may be in the form of resolvable URIs or they may also be in the form of IDs to other features in this service or even in some proprietary format

eg:

#Encoded inline 
<Mine id="er.mine.S0000001">
    <commodity id="er.commodity.C00001">
        <name>Gold</name>
    </commodity> 
</Mine>

#Encoded by reference 
<Mine id="er.mine.S0000001">
    <commodity xlink:href="#10"/>
</Mine>
Use case
required

Given a complex feature that may be defined in a number of pieces (seperate features with IDs) a consumption application will want an easy way of resolving these xlinks wherever possible.

Given that an xlink can reference:

  1. A feature already encoded in the document - eg '#10'
  2. A feature elsewhere in the dataset - eg 'urn:org:some:commodity:10'
  3. A feature elsewhere - 'http://some.org/10'

A number of different strategies will be required:

  1. Looking for features in the response document that match a particular ID
  2. Looking for features of a given type with a particular ID in the same WFS
  3. Looking for features at remote location based on the resolvable nature of the ID.

There will need to be support for a WFS parser that can resolve the above links using the appropriate strategies. Support for both lazy and eager resolution would be preferable, but not required. The parser must also gracefully handle situations where the resultant data does not conform to the GML specification.

Use case
optional
Plugin Resolution strategies should conform to a particular interface that can be implemented by 3rd parties and injected into the WFS parser. This would allow unique strategies to be developed by the consuming application for use with particular application schemas.

GeoTools Work

GeoTools was chosen as a basis for meeting the above usecases because:
  1. It has existing solutions for some of the above use cases
  2. It has a large and active community
  3. It's open source
GeoTools already has support for a WFS 1.1.0 client, OGC Filters 2.0 and an understanding of simple features level 0. For our client library we will need support for SF1 at a minimum with a preference for SF2.

Complex Feature Support

To support the 'Parsing an Information model' usecase we will require a library that is capable of working with complex features (simple features level 1 or SF1). Because GeoTools only supports SF0 part of the work will require developing support for SF1 and getting it supported by the community. The community support is crucial for the long term viability of the complex feature code.

There is a possibility that others may have done work in this area, if this is the case then their work should be leveraged

WFS Client

The GeoTools WFS client is more or less feature complete, what is missing is a set of utility classes that can be used to resolve feature IDs of various types. The bulk of the work in this area will involve developing a number of 'Resolution strategies' for different types of IDs and investigating possible strategies for resolving the IDs (eager/lazy evaluation)

App Schema

GeoTools has support for GML application schemas, but only by leveraging SF0. Once the above complex feature support has been developed then support for other schemas like GeoSciML and ERML should also be added.

Python APIs

Low priority - add the above support to a python library for usage within python scripts. Investigate http://www.jython.org/

-- JoshVote - 08 Feb 2012
Topic revision: r12 - 10 Jul 2012, AdamBrown