Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


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.


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"
  • Tech StreamingRenderer how to work with Content class rather then FeatureSource.
  • No labels