Copies of the enhanced Geoserver WFS have been deployed at each of the three initial participating agencies:
note these are NOT web server addresses - do not just click the URL's from your browser
- A copy of Web Map Composer (containing prototype GML handling) is installed at http://cgsrv3.arrc.csiro.au/seegrid . This client is a middleware application that can be used to publish multiple applications, which bind workflow configurations to map views and related information sources.
Web Map Composer Sample
- these allow you to paste in one of the four query types:
* simple client for PIRSA WFS query, send and return raw XML
* simple client for WA WFS query, send and return raw XML
GA Reports Page
* simple report page to demonstrate how WFS data might be used
Setting up the demonstrator Server and Client
These instructions give an overview of the procedures used in setting up the demonstration server and client installed at http://cgsrv3.arrc.csiro.au/seegrid/savedapps/filter
. It isn't necessary to setup both the client and server on a given site. Publishers of information can setup the server components for Geoserver and notify RobAtkinson
that the service exists. RobAtkinson
can then add the service to the demonstrator portal on http://cgsrv3.arrc.csiro.au/seegrid/savedapps/filter
to provide a client interface for demonstration and testing purposes.
This page does need refactoring to separate the geoserver install instructions from the WMC client demonstration
- Tomcat 4.1.x where x >24
- JSDK 1.4.1 (latest is OK)
- Java Advanced Imaging (JAI) installed
- Web Map Composer from Social Change Online
Geoserver deployment preparation
Note: the SEEGrid project has been successful in influencing the thinking of the broader community and has pawned a new project to enhance Geotools (and consequently Geoserver). Further details are at:
The rest of this page is relevant for supporting the interim branch created by the Seegrid R&D effort.
: download WAR file
- alternatively checkout geoserver from the Geoserver repository (under complex_sco branch)
- Follow install instructions at http://geoserver.sourceforge.net/documentation/1.2.0-rc2/
- to use the embeddy jetty server use ant prepareEmbedded first (port number config is in documents/jetty.xml)
- using ant you can run the build with ant go
- Read the notes at GeometrylessJDBCDataStore
- Read the notes on schemamapping - including the release notes for the geoserver build at https://www.seegrid.csiro.au/twiki/pub/Infosrvices/GeoserverMapping/GeoserverPatchSet2004-09-30.html
- Send publically visible URL of service to RobAtkinson for next round of testing
- Contact RobAtkinson for more assistance if you are unable to establish a public URL.
In pre-enhancement Geoserver there was really only a single logical schema - which was a database table that was automatically mapped to a private XML schema representation.
There are three "schemas" in the new configuration -
- The underlying database implementation schema (multiple tables)
- The "target" GML schema we want to output
- The internal database schema of the result set of a query output
In other words, we will change the geoserver paradigm so that the registered schema is no longer a database table, but the result of a join query, which can then be customised.
We will extend this with information about the Xpath mapping from each column to the output GML schema.
During output of the query results we will map deduplicate rows and re-create the multi-valued properties (re-normalise as required by the GML application schema)
- Create a data store (if using the embedded jetty server, edit server\geoserver\WEB-INF\catalog.xml) eg look at the kyanite.oracle.geochem entry
- Create an info.xml (if using the embedded jetty server, create a directory in server\geoserver\data\featureTypes of the same name as the feature type and put info.xml in here)
- At this stage the feature type name has to correspond to a table name in the datastore; should be able to relax this restriction, but fairly low priority.
- The SCO extension to this file is an attribute named - this contains the SQL query template we will use to query related tables.
- It is possible that SCO will add additional elements to info.xml
- The query shows an inner select as a table valued expression, this is to allow a WFS filter to be applied without referencing table aliases used in joins in the filter properties.
- If non default GML2 output is required, a schema must be supplied. This file is called schema.xml and resides in the same directory as featureinfo.xml. schema.xml describes the attributes of the datastore.
- NB: With previous versions of GeoServer, schema.xml was mandatory, but GeoServer can now generate a default schema. We now need to manually create this to describe the query result.
SCO has added an xpath attribute, providing a mapping from attributes in the result set of the query in info.xml to elements/attributes of an output document; providing for nested elements, as opposed to the default "denormalised" output. This is the current focus of ongoing work.
- catalog.xml: Geoserver config: Sample datastore registration
- info.xml: Geoserver config: Feature Type metadata: info.xml
- schema.xml: Geoserver config: schema.xml - Xpath to GML
WFS Change Request
From the proposal:
The proposal introduces a mechanism whereby the WFS query may be decoupled from the response model.
This change is required in order that a deployed WFS service may satisfy certain business cases where (i) elements of the report may not be used as parameters in the query, (ii) to provide a formal mechanism to allow a service provider to limit the permitted queries for various reasons, (iii) to allow indirect query via a different feature. It is accomplished by allowing the service to specify one or more content models to be used by a client in constructing a WFS GetFeature request.
This version is a "minimalist" approach that makes fewest changes (all optional additions) to the current spec so is calculated to induce the minimal pushback from the WFS reviewers.
Initially I used the terminology "Query Model" rather than "Filter Model" with the idea that more general methods might be supported, but this way the symmetry with the current syntax is very obvious and so likely to be most acceptable.
If you can see a way to push further, then please make suggestions.
But also be prepared to provide quite detailed documentation - the level of detail that I have provided is essentially "drop-in" and thus might be accepted as-is.
Though we probably have to provide evidence of a working implementation in due course ...
I hope this would just be a matter of adjusting the syntax on the existing demonstrator.
- 04 Apr 2005
Final report with lessons learned