Introduction

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):

Filter Support

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.

Data Access

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.

DataAccess

DataStore superclass.

Content

FeatureSource superclass.

Rendering

Given the above two the following is needed for rendering intergration:

Teach PropertyAccessor the concept of "default geometry"
Tech StreamingRenderer how to work with Content class rather then FeatureSource.