seegrid project scope

h1 SEEGRID Project Scope notes:

The SEEGrid community http://seegrid.csiro.au is progressing a project to extend GeoServer to support "Community Schemas". Please see the Use Case document for more information on why.

This is a small project with enough funds for a few months total effort, but the implementation team, Rob Atkinson and Peter Barrs from Social Change Online http://socialchange.net.au, have a fair bit of experience in Java based WFS implementations including many of the ideas presented here, and we're working closely with the sponsoring agencies and Simon Cox (one of the main GML editors, and WFS RWG) - so we are confident we can create some sort of an outcome.

This project arises out of a larger project, "Solid Earth and Environment Grid - Information Services" https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/RoadmapDocument to explore deployment of a GML-derived application schema within a sector comprising a range of business processes, scientific activity and typical data access services.

For specific thoughts related to the requirements to support "community schemas" see the following sections:

• https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/InformationViewpoint#Community_models
• https://www.seegrid.csiro.au/twiki/bin/view/Xmml/InformationModels
• https://www.seegrid.csiro.au/twiki/bin/view/Xmml/WebFeatureService

Deliverables

Initial project is aimed at supporting "Observations and Measurements" model against relational databases.
This requires, at the very least:

• GML output mapped to a predefined schema
• related features as attributes (properties)
• multi-valued properties

Desirable:

• ability to exploit non-spatial objects containing geometry (x,y,z points in particular)
• ability to link features from different feature stores (shapesfiles and db tables for example)

Code base release strategy

Our aim is to work as closely as possible with the mainstream Geoserver community to:

• agree on an approach
• explore ideas and design requirements we may have missed
• make the effort as accessible as possible to any who want to exploit it
• promulgate the concept of interoperable data, not just protocols
• see the outcomes fitted into the core capabilities and release schedules.

Is this a Geotools or Geoserver Issue?

It is understood that much of the actual coding is likely to take place within the Geotools codebase. We have nevertheless initially focussed on the WFS implementation because this set of Geotool users are going to have the greatest affiinity for the project requirements, and be the group whose uptake of improvements will drive improved interoperability in practice.