|Motivation:||Add support for ComplexFeatures. GeoTools should be able to parse a complex WFS response and construct a set of Feature objects from it.|
|ComplexFeature Parsing & Building Support|
complex features FTW
This page represents the current plan; for discussion please check the tracker link above.
- API Changes
- Documentation Changes
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:
Voting has started:
- Andrea Aime:
- Ben Caradoc-Davies: +1
- Christian Mueller:
- Ian Turton:
- Justin Deoliveira:
- Jody Garnett:
- Simone Giannecchini:
- WFSDataAccessFactory integrated into 'Factory' hierarchy.
- WFSContentDataAccess integrated into 'DataAccess' hierarcy.
- A new 'GetParser<...>' hierarchy created to supplant existing 'GetFeatureParser' hierarchy. XmlComplexFeatureParser integrated into this.
- A new 'FeatureBuilder<...>' hierarchy created to generalise functionality from 'SimpleFeatureBuilder' so that it can be used by a new ComplexFeatureBuilder class.
- Create an AttributeBuilder.
- Create a ComplexFeatureBuilder.
- Complete the XmlComplexFeatureParser.
- Update documentation. (in progress)
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.
The attributeValue, above, is created by a static Converters.convert(...) method which takes a raw text value and a binding (Java Class object).
In the case of ComplexFeatures the propertyValue, above, is constructed with an AttributeBuilder and bound to a Java Class object.
Excerpt from ComplexFeatureBuilderTests
- New documentation will be required to cover the steps involved in processing a complex WFS response.
- 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.