This page sketches out a number of real world examples driving the Geoserver "Community Schema Enablement" project. 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:
These are grouped into two sets:
- A) Functionality required for real-world uses
stuff that make it behave more usefully as a service
- B) Back-end capabilities to make the product easily applied:
stuff that makes geoserver easier to deploy against existing databases
A) Functionality required for real-world uses
- ) Spatial Data Infrastructures require a WFS to serve externally defined feature types.
- A feature may be defined to include properties from many namespaces.
- ) A feature may have multi-valued properties
- An object may have several recorded positions
- A land parcel may have several owners
- A traffic light may have multiple sequencing rule sets
- A classroom may have multiple bookable time slots
- ) A feature may have multiple geometries
- ) A set of features may be inter-related:
- e.g. a sampling location and a series of samples.
- It may be desirable to configure both sampling location and sample item types in a single workflow so they can reference each other safely and consistently.
- It is typically necessary to run queries across related features:
- show me sampling locations where the current river flow = 0
- ) A feature property may be mapped to part of or more than one storage schema:
- phone = area_code + number + " x" + extension
- area_code = part of ph number
- ) Many features may share the same feature as a property
- many samples at a sampling location
- many measurements on a sample
- Need to allow features to reference related objects that are serialised once: (See Ordnance Survey MasterMap GML for heavy use of this type of thing)
B) Back-end capabilities to make the product easily applied:
- ) Static Geometr(ies) may be held in shapefiles (or other spatial data store) whilst related information is managed in a non-spatial database or other system.
- There may be many information products that re-use the geometry data. e.g. census data
- It may be inconvenient to manage geometry in an operational data management environment
- There may be multiple geometries for the same set of features
- ) Data may exist in a pre-existing database structure
This may include multiple tables and business rules and not be efficiently mapped into flat views. WFS will need to be able to map queries against the real data.
- ) Features may not exist except as a result of queries
- for example, a feature collection showing the number of pollution incidents by catchment may be created dynamically from an incident database. This is particularly true of datasets with highly variable spatio-temporal density
- ) Multiple columns could be mapped to a multi-value property: