|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
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:
The proposed type hierachies can be seen alongside their previous forms here: See how the type hierarchies have changed.
This proposal is under construction.
Voting has not started yet:
- Andrea Aime
- Ben Caradoc-Davies
- Christian Mueller
- Ian Turton
- Justin Deoliveira
- Jody Garnett
- Simone Giannecchini
I am contracted to work on this until the end of July 2012. At the time of writing that leaves approximately 8 weeks.
- 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. (In progress, 1 week)
- Create a ComplexFeatureBuilder. (Started, 2 weeks, blocked by #5)
- Complete the XmlComplexFeatureParser. (Started, 3 weeks, blocked by #6)
- 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.
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.
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.