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

Roadmap (and progress report) for support of GML Observations and Measurements patterns in WFS and WCS

Rationale: a large number of data standards will emerge in the near future, driven by FGCD, INSPIRE, ANZLIC and other national and international Spatial Data Infrastructures activities.

Many of these will be utilise the ISO19115 ( XML implementation = ISO19139) metadata patterns. All major jurisdictions are developing data standards based on ISO models, that will introduce this standard as "Feature level" metadata - i.e. either attributes of Features that use  element types from ISO 19115, or related objects that reference the feature themselves.

Proof of the Pudding

See the attached examples for some sample outputs achieved using this build 

A significant proportion of application domains will require data models based on the "Observation and Measurements pattern".  Both ISO19115 and O&M patterns share common technical challenges:

  • multiple related XML schemas defining the data model
  • fairly complex, concrete, but highly abstract, container objects - things that need to be instantiated but which are realised through highly constrained "profiles" (MD_Metadata, Observation etc)
  • Use of attributes that are weakly typed (anyType, anyFeature) that need to be realised as concrete types
  • deep nesting of elements in gml schema

This roadmap attempts to break down the pathway to a fully supported ability to handle observational data into a series of discrete steps that can be introduced progressively to the Geotools trunk, to deliver business benefits via Geoserver.

Progress Summary

The "complex-features" branch provided a partial implementation which has informed potential improvements to the "Feature Model" at the heart of Geotools  and the geoAPI.  This work has been ported to Geotools trunk (currently supporting version 2.4) as an unsupported module "community-schema" and tested through geoserver 1.6.x community module: "Geoserver-c" which has a set of community modules that replace wfs and web, allowing building of a deployable WAR  file that uses the new modules to handle WFS requests.  Reconciling this module with mainstream wfs and web modules will occur on geoserver trunk in late 2008

A war file will shortly be available on Sourceforge for this implementation. We are endeavouring to keep this available on the geoserver trunk, tracking the geotools trunk.

Sample configurations are available from https://svn.codehaus.org/geoserver/trunk/configuration/community-schema

There is a resourced activity to support and bring this capability home to the production geoserver release, out of CSIRO Australia. More details will be provided later, at the moment the focus is getting the existing modules capable of delivering GeoSciML.

The task of "bringing this home" is however reasonable complex, and can be broken into a series of milestone goals which provide useful functionality in their own right.  The following provides a potential list of "Business goal milestones" and the technical tasks required.

 The next step is to consolidate progress made to date and to explore additional resourcing options and the ability to accelerate development.

Jody Garnett

I will try and translate this page for the developer crowd.




Details

Here are the ISO number translated for the open-source community:

ISO19139 XML binding of ISO19115
ISO19115 Metadata for spatial data
ISO19119 Service metadata

The only way to access this information usefully is:

Jody Garnett
You need to try out the above, rather then worry about ISO being bad for open source (it is).
This is a case of our user community having a much harder problem then our development community - the goal is to reuse, reUSE, REUSE data (a much more expensive prospect then code resue). In order to do this the user community would like to take the definition of "time" contained on one of those above ISOXXXX documents and fold it into their definition of their data. Do NOT be put off by the word metadata here; they are grabbing the definition on folding it in as a part of their real data set.
By making use of common data concepts for these basic ideas everyone benifits.





Business Goal:

1. Support GML Simple Features Profile Level 0 for WFS 1.1 (Business Goal)

Status

CHECK THIS PLEASE: Justin

Complete. 

GML 3.1.1 is now supported by the gt-xml modules. This capability was created for the OGC OWS 4 activities, and now forms part of the core geotools codebase. The community-schema build exploits these modules.


technical requirement:

Support the gml:FeaturePropertyType (which allows "inline" or "by Reference" ) so that it supports encoding as a simple attribute
 <myns:Reference xlink:href="urn:blah:blah:featureID" >
 

Jody Garnett

Quick Hack: translate every FeatureAttributeType into the above xlink notation.

This is a part of GML we have never had to support given the limitations of our current feature model. This is the first short-comming we need to address and a temporay hack (even in GeoTools 2.4 will suffice).





Technical plan:

a) Enable use of Feature Factory impl

Jody Garnett

Actually a series of changes designed to isolate the codebase from specific implementation of Feature. In the event most of this came down to use PropertyName (ie Expression) to access content.


Status

CHECK THIS

Unknown.  Community-schema operates within the limitation that Features must be "inline" in order to support queries.  This is potentially a major limitation, but can be worked around by creating specialised "container" feature types.



b) milestone release gt 2.4 to allows OWS 4 delivery, leaving trunk to merge improved feature model

Jody Garnett

Complete



c) needs the ability to map the output from the feature during gml production. This mapping could be derived from reading the target schema, or could be allowed to be defaults overridden by configuration.

Status

Partially complete ( for geometryless data store only),  with limitations on feature complexity.

a)   Community-schema operates within the limitation that Features must be "inline" in order to support queries.  This is potentially a major limitation, but can be worked around by creating specialised "container" feature types.

b) only a single attribute can be multi-valued if derived from multiple records.  Multiple elements of a single record can be mapped to a fixed number of elements (i.e. result set columns) of the same name (gml:name[1] = authName, gml:name[2] = aliasName) etc.

In particular, the "inline" or "byReference" hint is going to be needed, and this is not available in the schema.
(and other gml namespace elements) are currently delegated to the feature model and not handled there.

Status

CHECK THIS

Unknown.  Community-schema operates within the limitation that Features must be "inline" in order to support queries.  This is potentially a major limitation, but can be worked around by creating specialised "container" feature types.

d) geoserver build using milestone build

2. Support GML Simple Features Profile Level 1 for WFS 1.1, but with externally defined schema (Business Goal)

technical requirement:

  • Multiple values and XML attributes any property, but only one simple geometry (Curve?)NB - maybe dont need to fix namespace handling in filter, but would be good!

technical plan:

  • Port complexds: Read target schema (using GTXML) and support complexDS mappings
Jody Garnett
This is the basic level of functionality needed to be used, organizations are looking for a solution that will let them publish their content according to a "provided" schema, GML3 looks very good on paper and is usually selected as a starting point for this sort of thing.
  • Developers: Please note that our target users here are not those responsible for providing the schema, they have no wiggle room.
  • Users: please note that use of GML3 is still an early standard, it only recently has only recently validated as an XML document, this is the reason that even as a several year old standard there has been almost no adoption.





3. Support ISO metadata (19115,19139) (Business Goal)

Allowing Geotools to support a wide range of Feature Types with common metadata elements, and potentially traditional "metadata record" type objects as features. This may be used to support typical OGC CS/W services for geoserver or other technologies in the future.

Status

Can use an adaptation (to GML3.1.1) of the normative ISO19139 schemas (which are in GML 3.2)

See examples: some good results using this, but not a comprehensive exercising of the possiblities by any means.

Need a suite of test cases developed against the trickier and most common parts of the spec. 

 

technical requirement:

  • Complex types, but known patterns (special case of GML SF Level 2)
  • use normative ISO19139 schema (i.e. dont ignore this when parsing applicaton schema)
  • An ability to override types where ISO 19139 provides an xs:anyType placeholder.

technical plan:

  • possibly create an ISO19139 module to delegate type creation. (schema parsing is fraught, but if it is to be done, should be done once, not per feature type)
  • configuration override for data types

    research issues:

  • best practice for type substitution and namespace handling (eg ISOtype hints)
    •     mitigation: allow namespace override on objects found in schema, this would allow a local type that defined the element contents to be declared in the configuration
Jody Garnett
Remeber ISO numbers != sleep, this goal is all about letting the user community reuse data definitions - this time they happen to be from an ISO standard on metadata.





4. POJO database support (Business Goal)

Support POJO business objects providing access to data objects.

technical requirement:

allow data product schema driven feature type configuration to be mapped to java objects exposing a persistence layer.
2 obvious examples occur:
1) accessing a Hibernate introspection based realisation of a data store
2) accessing EJB business objects. In this case it will be assumed that "remoting" issues are handled by a EJB based layer that hides the remoting implementation. Constraint is solution runs in an EJB container.
NB - transactions not required.

technical plan:

create FT mappings layer for query/response mapping (can complexDS do this for us if we have a basic hibernate introspection based autoDS?)

research issues

Confirm EJB integration architecture and platform compatibility (can run geoserver under Websphere, JBOSS )
Should we create a subclass of data stores "AutoDataStore" that use introspection (as per most current stores), and a subclass of data stores that receive a schema definition from a configuration (eg XSD schema parsing, configuration). coverage based Datastores probably fall into the latter case.

This might be useful to make behaviour a little clearer and more coherent?

Jody Garnett

Pojo's are simply acting as an easy to understand definition of a model, the mapping between models (ie into a community schema) should be a similar problem in both cases. The Expression API allows us the ability to query both Feaures and POJOs in a similar manner.

Developers: POJOs represent an attractive model that many organizations either have, or find cheap to produce - we should be doing everything in our power to harness this.
Users: we have a couple working examples of using POJOs, these are only at the proto type level - running something other then Features through our software will take time, mapping POJOs into a feature is a much faster alternative (that is acceptable as long as operations are not needed).




5. Basic support ISO 19123 for 2D coverages as features (Business goal)

(allows GML feature to be passed as a metadata-rich handle to a WCS call that can get the data)

technical requirement:

  • Create complex type for coverage data store when defined, containing metadata using ISO1923 pattern
  • GML feature will contain xlink:href to WCS call to allow recipient of coverage object to get data directly.

NB (querying the contents of a coverage store via a WFS filter is not expected at this level, restricted to 2D coverages)

technical plan:

  • review coverageDS and geoAPI interfaces against business requirements (full set!)
  • CRS data type to suport serialisation (NB this is "complex features" but maybe a simple case where the complex object type is special - knowns how to handle configurations for input and output mappings)
  • Coverage FeatureType builder
  • Wrap coverageStore with a DataStore API implementation
  • WFS filter query mapping to WCS call as rangeSet value of coverage Feature (xlink:href to the WCS)
  • ? create an ISO19123 module to delegate feature type creation during schema parsing

    research issues:

what should the feature type be called? i.e. Do we support soft-typed coverages only CV_2DRectifiedGridCoverage,  in which case being able to advertise a series of alternative configurations for a single Feature Type may be an issue
Coverages are in fact a "special case" of observations, should we use Observation as the root class? Advantage: support for Observations in general.

Jody Garnett

As part of the ISO TC211 set up coverages actually do extend Feature, this makes sense as a Feature is "something that can be drawn on a map". We need to keep track of progress on the GeoAPI interface, and make sure Bryce and Justin continue to keep communication going.




6. Support ISO 19123 for multi-dimensional continuous coverages as features (Business Goal)

technical requirement:

  •  * Ability to configure data store using multiple dimensions (may be supported by WCS support for nD coverages
  • Ability to query multiple dimensions, include temporal dimensions via WFS (Filter)

Research issues

  • Temporal and Vertical dimensions - should these form part of CRS? What do queries look like?
  • Do we need to support operations on Feature Types in general, and expose these through the filter? (2D can probably ignore this, and use available built-in geometry operations?)
Jody Garnett
The trick here is using WFS to query a 2D or nD coverage, the WFS offers a much more capable query language in the form of the Filter specitification. Technically this is possible (Coverage should extend Feature after all), the generated output - at least with WFS 1.1 - can be requested in a varity of formats. This option should be much cheaper then pushing the extension of scope through the OGC process, and you can find groups doing similar things in terms of publishing specific kinds of content through the as WFS Profiles.
Even if we are limited to GML, the OGC has shown how (for surveyors) one can embeded binary data into GML using PCDATA.






Document generated by Confluence on May 14, 2014 23:00