Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Motivation:Add support for ComplexFeatures. GeoTools should be able to parse a complex WFS response and construct a set of Feature objects from it.

Contact:

Adam Brown

Tracker:

ComplexFeature Parsing & Building Support

Tagline:

complex features FTW

This page represents the current plan; for discussion please check the tracker link above.

Description

GeoTool's lack of support for parsing XML into complex features limits its utility as a GIS toolkit.

I propose to add this functionality by augmenting the codebase such that there are complex-compatible analogues or alternatives to all the classes necessary for WFS-based communications. Existing type hierarchies will be modifed and added to to provide this new functionality. In making these changes I will strive for maximum reuse of existing code and will follow the coding patterns and API conventions currently employed; as such, the code for performing a complex feature request will be much like the code for a simple feature request. Breaking changes will be eschewed.

Central to this work is a new XmlComplexFeatureParser which will use an AttributeBuilder and a ComplexFeatureBuilder to create objects that represent the content of WFS XML responses.

The addition of the following classes has had varying levels of impact on their encompassing type hierarchies:

  • WFSContentDataAccess
  • WFSDataAccessFactory
  • XmlComplexFeatureParser
  • ComplexFeatureBuilder

The proposed type hierachies can be seen alongside their previous forms here: See how the type hierarchies have changed.

Resources

GML Consumption Library Use cases

Status

This proposal is under construction.

Voting has not started yet:

Tasks

I am contracted to work on this until the end of July 2012. At the time of writing that leaves approximately 8 weeks.

 

no progress

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. (tick) WFSDataAccessFactory integrated into 'Factory' hierarchy.
  2. (tick) WFSContentDataAccess integrated into 'DataAccess' hierarcy.
  3. (tick) A new 'GetParser<...>' hierarchy created to supplant existing 'GetFeatureParser' hierarchy. XmlComplexFeatureParser integrated into this.
  4. (tick) A new 'FeatureBuilder<...>' hierarchy created to generalise functionality from 'SimpleFeatureBuilder' so that it can be used by a new ComplexFeatureBuilder class.
  5. Create an AttributeBuilder. (In progress, 1 week)
  6. Create a ComplexFeatureBuilder. (Started, 2 weeks, blocked by #5)
  7. Complete the XmlComplexFeatureParser. (Started, 3 weeks, blocked by #6)
  8. Update documentation. (Blocked by #7)

That would leave 2 weeks to respond to faults from community, bug fixes, documentation updates etc.

I'll update these time estimates as I progress.

API Changes

Public API for making WFS request

BEFORE (Example of SIMPLE feature request)
AFTER (Example of COMPLEX feature request)

Take note of the comments enclosed by double asterix, i.e; /** comment **/. They point out some important differences between the two code samples. Each one has letter identifier preceded by a hash. I will hearafter refer back to these identifiers to elaborate more on the code they annotate:

  • #A: The 'getDataStore' method iterates through a collection of factories until it finds one that meets the requirements of the connectionParameters passed in. I added a new optional GML_COMPLIANCE_LEVEL parameter to be passed through to impose a restriction on the type of DataAccess object that can be passed back. I.e. one that supports complex features.
  • #B: When dealing with complex features we can utilise the app-schema-cache to cache schemata.
  • #C: I created WFSDataAccessFactory which conforms to GML_COMPLIANCE_LEVEL 2. It creates and returns a WFSContentDataAccess object. WFSContentDataAccess borrows extensively from WFSContentDataStore with notable exceptions being its lack of reliance on simple types in methods such as getSchema, updateSchema, etc.

Comparison and Contrast between SimpleFeatureBuilder, ComplexFeatureBuilder usage

The builders are used by their corresponding XML feature parsers to associate attributes with names.

SimpleFeatureBuilder
SimpleFeatureBuilder

The attributeValue, above, is created by a static Converters.convert(...) method which takes a raw text value and a binding (Java Class object).

ComplexFeatureBuilder
SimpleFeatureBuilder

In the case of ComplexFeatures the propertyValue, above, is constructed with an AttributeBuilder and bound to a Java Class object.

Excerpt from ComplexFeatureBuilderTests

Excerpt from ComplexFeatureBuilderTests

 

Documentation Changes

  • New documentation will be required to cover the steps involved in processing a complex WFS response.
  • http://docs.geotools.org/latest/userguide/library/data/wfs.html
    • Add details of new connection parameter 'GML_COMPLIANCE_LEVEL'.
    • Add a new example of a WFS request showing the retrieval and consumption of a complex version.
  • No labels