JPOX-Spatial allows the use of JPOX as persistence layer for geospatial applications in an environment that supports the OGC SFA specification. It defines type mappings to let JPOX know how to persist a number of different Java geometry types (JTS, PostGIS-JDBC geometry types, Oracle's JGeometry). Thus a Java developer can mix spatial and non-spatial datatypes in his POJOs and can rely on JPOX to persist and query those types.
The mission for the JPOX Extension is to:
- Use of OGC Filter to produce a query against JPOX
- Expression evaulation against a POJO using JXPath
- Glue code for JPOX-Spatial Domains Models to be viewed as a simple POJODataStore
- Additional utility code to assist intergration between POJO domain model and GeoTools as required
How you can help?
- provide a test data set (and public database) with an interesting "complex" domain model
The following needs to be sorted out:
The following documentation is available (or at least intended):
Since this extension is realised as part of a diploma thesis, we are on rather tight schedule. This is what we have planned for the remaining three weeks:
- Convince GT people of our Data Access model
- Write a (simple) JPOX-POJO implementation of our Data Access model
- Add methods we need to PropertyAccessor interface
- Write a tutorial for devs, who want to use the new Data Access model
- Have a short presentation of results and tutorial at Refractions
- Implement handling of Filter expressions defined in XPath (only simple stuff!)
- Write a tutorial for that
Since most everything in the spatial world (pun intended) with OGC Filter - this is the first step. It will enable our Data Access and Rendering intergration.
Pojo Property Accessor
We need to make use of theExpression Improvements PropertyAccessor API to teach the filter system about working with Plain-Old-Java-Objects.
This can be done in two parts:
- simple reflection to access Bean properties (or reflection straight to Java fields?)
- full xpath support with JXPath (easy since beans + collections already supported)
This will allow the post processing filters to work.
Filter to JPox Query Transformation
This work has been done for BBox query; we will need to go through the list.
Right now the GeoTools project makes use of the DataStore and Catalog interfaces for data access.
- Service - suitable
- ServiceInfo - suitable
- DataStore - array of strings and FeatureType not suitable, should move to Set of TypeName (aka Schema)
- GeoResource - suitable
- GeoResourceInfo - suitable
- FeatureSource - generalize to work with Class and Object
Here is a picture:
|Happy Happy Joy Joy|
Recently groldand has asked about supporting the "old" Feature Model and the "new" Feature Model. While we are happy not to care here in Pojoland - this dicussion points the way forward.
Is this design feasible for existing DataStore implementations like FeatureStore and future stuff like GridService? Please provide feedback and suggestions!
Possible DataStore superclass, providing a more general data access API for GeoTools.
Provides access to the actual data either filtered/queried or not. Purely read-only.
Extends Source with writing capabilities.
Given the above two the following is needed for rendering intergration:
- Teach PropertyAccessor the concept of "default geometry"
- Add getDefaultGeometry() to PropertyAccessor interface.
- Tech StreamingRenderer how to work with Content class rather then FeatureSource.