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:

• #Filter Support
• #Data Access
• #Rendering

The following documentation is available (or at least intended):

Timeline

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:

this week:

• 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

next week:

• Write a tutorial for devs, who want to use the new Data Access model
• Have a short presentation of results and tutorial at Refractions

last week:

• Implement handling of Filter expressions defined in XPath (only simple stuff!)
• Write a tutorial for that

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.

DataService

Possible DataStore superclass, providing a more general data access API for GeoTools.

Source

Provides access to the actual data either filtered/queried or not. Purely read-only.

Store

Extends Source with writing capabilities.

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.