This page last changed on Jun 17, 2008 by robatkinson.

THIS PAGE IS OUT OF DATE, and will be replaced in due course.


Please see [[ https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverCommunitySchemasDownloads ]] for up to date information pending porting of functionality to geoserver trunk as a core capability.

Complex Datastore

The Complex DataStore project is a branch of development which will enhance GeoServer data modeling capabilities in order to serve out "community schemas" out of internal data structures. That is, the ability to map an internal data model to an externally defined one using a GML schema, so called "community schema".

While the ability to represent complex Feature models is provided by the latest GeoAPI org.opengis.feature interfaces, they're not yet fully supported on the core geotools and geoserver streams, so the problem to bring up a working prototype is two-fold: by one side is the need for geotools and geoserver to use the GeoAPI feature interfaces instead of the GeoTools ones, and by the other an alternative data access api is needed in order to query over a GeoAPI Feature model without messing up the stable DataStore and related interfaces.

So, at the GeoTools side of the fence, the ability of org.opengis.Filter to work over Object is exploited by the use of custom property accessors that knows how to filter complex filters, including namespace support; and a temporary data access api is used, all of it maintained on the modules/unsupported/community-schema code base.
At the GeoServer side of the fence, alternate wfs-c and web-c modules are held in the community/community-schemas code base. They're used in replacement of the official wfs and web modules in order to support the geotools enhancements without cluttering the stable versions.

The code is currently lying as a set of unsupported modules in both the geotools 2.4.x and geoserver 1.6.x code bases. Though no specific release artifact has been deployed for this prototypes, in order to use it you'll have to build them by your self.

To do so:

Checkout and build geotools 2.4.x:

$svn co http://svn.geotools.org/geotools/branches/2.4.x
$cd 2.4.x
$mvn install -Ppending

-Ppending is needed in order for maven to compile and install the community-schemas modules in your local maven repo. Be aware other (unrelated) modules in the pending profile may fail. If you want to make sure just cd modules/unsupported/community-schema && mvn clean install

Checkout and build GeoServer 1.6.x:

$svn co https://svn.codehaus.org/geoserver/branches/1.6.x
$cd 1.6.x/geoserver
$mvn install -Dcommunity -DconfigId=community-schema -DconfigDirectory=../configuration

(alternatively use the absolute path to <1.6.x checkout dir>/configuration for maven to pick up the sample community-schema configuration.

Once built, be aware you have to run the web-c module, not web.
But first give the JVM a bit of memory to eat. Make sure your MAVEN_OPTS environment variable sets it, like in $export MAVEN_OPTS=-Xmx512m.
Alternatively just set this variable directly on the mvn script, or whatever has to be done in order to give the VM enough memory if you'll try tomcat or other servlet container.

$cd community/community-schemas/web-c
$mvn jetty:run

Now what?

  • Note right now only the xmml:Borehole sample feature type is working. Sorry about that, I'll try to get more samples working asap.
  • Explore the mappings configuration file, for borehol its in <data-dir>/featureTypes/Borehole/BoreholeTest_properties.xml

There's a lot more to document about how things work. Please start by digging into the mappings file schema accompanying the above file. Hopefully with your patience and questions we'll get to something more friendly.

Document generated by Confluence on May 14, 2014 22:59