19
INSPIRE, EC Water Standards and WaterML Workshop Keiran Millard ([email protected])

INSPIRE, EC Water Standards and WaterML Workshop Keiran Millard ([email protected]) Keiran Millard ([email protected])

Embed Size (px)

Citation preview

INSPIRE, EC Water Standards and WaterML Workshop

Keiran Millard

([email protected])

Keiran Millard

([email protected])

© HR Wallingford 2007 Page 2

HR Wallingford

Not for profit research, consultancy and software organisation in hydraulic engineering

Floods, water, energy, maritime, coasts

Key role in the (on going) development of MarineXMLMarine data exchange (issues) are not much different to

water data exchange

Leading INSPIRE Implementation Project MOTIIVESpecifications for data exchange

Invited to contribute these findings to WaterML workshop and report on water data exchange in Europe

© HR Wallingford 2007 Page 3

MOTIIVE Scope

•Premise (of call)• GMES Service will be more cost-effective to deploy

through the use and adoption of OGC/ISO Interoperability standards

• This interoperability will entail true ‘mix and match’ between (and amongst) ‘core’ and ‘downstream’ data processors.

•Scope (of Motiive)• How do you apply ISO/OGC Standards to the

coastal/marine community?− Land:sea interaction (Marine Overlays on Topology)

• What do the standards look like and how does a ‘cost benefit’ manifest itself?

© HR Wallingford 2007 Page 4

Motiive Outputs

•What has Motiive achieved?• Development and Testing of INSPIRE Data Product

Methodology• Community needs for harmonisation• Community Feature Types (published as UML and XSD)• Feature Type Catalogue implementation

•Motiive, INSPIRE and OGC• MOTIIVE provides an ‘earth science’ perspective on

Inspire• Delivery of a web-enabled catalogue for the Inspire

Themes to lodge their FT’s

These findings will be useful to any community where datasets exchanged between members are ‘representation on environmental phenomena’ such as water quality, air temperature, water flows...

© HR Wallingford 2007

INSPIRE Methodology for Data Products

Requirements Requirements Requirements As - is analysis

Gap analysis

Use Case Development

Use Case Development

Use Case Development

Use Case Development

Requirements and Feature Types

Identification

Requirements and Feature Types

Identification

Requirements and Feature Types

Identification

Requirements and Feature Types

Identification

App Schema Development

App Schema Development App Schema Development

Data Product Specification Development

Implementation , testing and validation

Implementation , testing and validation

Implementation , testing and validation

Implementation , testing and

validation ( using WFS)

Requirements Requirements Requirements As - is analysis

Gap analysis

Use Case Development

Use Case Development

Use Case Development

Use Case Development

Requirements and Feature Types

Identification

Requirements and Feature Types

Identification

Requirements and Feature Types

Identification

Requirements and Sp.Object Types

Identification

App Schema Development

App Schema Development App Schema Development

Data Specification Development

Implementation , testing and

Implementation , testing and validation

Implementation , testing and

Implementation , testing and validation

Work within your community (SDIC – Spatial Data Interest Community) to develop these specifications

© HR Wallingford 2007 Page 8

‘Observation’ Feature Types

•Data Product Specification related to measuring and observations requires Feature Types based on:

• Scientific utility of the sampling regime• Limitations of the observation process

•CSML (Climate Science Modelling Language)• Consistent with community practice

− ESRI, UniData, NOAA

• Feature types and storage descriptors− Binding to NetCDF, GRIB etc.

• Implemented in UML and GML

© HR Wallingford 2007 Page 9

CSML Feature Types

CSML feature type Description Examples

TrajectoryFeature Discrete path in time and space of a platform or instrument.

ship’s cruise track, aircraft’s flight path

PointFeature Single point measurement. raingauge measurement

ProfileFeature Single ‘profile’ of some parameter along a directed line in space.

wind sounding, XBT, CTD, radiosonde

GridFeature Single time-snapshot of a gridded field. gridded analysis field

PointSeriesFeature Series of single datum measurements. tidegauge, rainfall timeseries

ProfileSeriesFeature Series of profile-type measurements.vertical or scanning radar, shipborne ADCP, thermistor chain timeseries

GridSeriesFeature Timeseries of gridded parameter fields.numerical weather prediction model, ocean general circulation model

Presently in Release 2

© HR Wallingford 2007 Page 10

CSML Feature Types (Grid Series)cd GridSeriesFeature

Cov erage Types::GridSeriesCov erage

+/ domainSet: GridSeriesDomain+/ rangeSet: Record [0..*]

CV_DiscreteCoverage

Discrete Cov erages::CV_DiscreteGridPointCov erage

+ find(DirectPosition*, Integer*) : Sequence<CV_GridPointValuePair>+ list() : Set<CV_GridPointValuePair>+ locate(DirectPosition*) : Set<CV_GridPointValuePair>+ point(CV_GridCoordinate*) : CV_GridPointValuePair

«FeatureType»GridSeriesFeature

AnyDefinition

«ObjectType»phenomenon::Phenomenon

ReferenceableGrid

«ObjectType»Domain geometries::

GridSeriesDomain

«type»Affordance::GridSeriesType

+ value: GridSeriesCoverage

+ extactPointCollection() : PointCollectionFeature+ extractGridFeature() : GridFeature+ extractGridSeriesFeature() : PointSeriesFeature+ extractPointFeature() : PointFeature+ extractPointSeriesFeature() : PointSeriesFeature+ extractProfileFeature() : Profi leFeature+ extractProfileSeriesFeature() : Profi leSeriesFeature+ extractSection() : SectionFeature

«realize»

+parameter

+value

«implement»

INSPIRE does not mandate operations for FTs – but most communities will require this

© HR Wallingford 2007 Page 11

‘Observation’ Feature Types

Motiive TestbedGeneric (CSML) Time Series

TidalWaterLevel

TimeSeries

Graph and Table

Service

© HR Wallingford 2007

WFS Implementation

© HR Wallingford 2007

WFS Implementation

© HR Wallingford 2007

FTC Implementation (19110)

© HR Wallingford 2007

FTC Implementation 19110

© HR Wallingford 2007

WaterML Workshop

• Water Resources Information Model Workshop• Canberra, Australia, 25-27 September, 2007• There were 34 participants representing 18 organizations from 3

geographical areas (Australia-New Zealand, USA,-Canada, and Europe).

• The workshop was convened in response to developments in:

• the institutional environment, with increased expectations and demands for more extensive, integrated and timely information, frequently across organisational boundaries;

• the technological environment, with improvements in information networks, sensor technologies, processing services, and with a proliferation of information models and exchange formats for water resources information.

In a nutshell…

XML is great. Everyone is using XML as a exchange mechanism for water data; but everyone is doing this differently.

This negates the bigger benefits of shared applications and information aggregation

How can we work together?

© HR Wallingford 2007 Page 21

WISE and WaterML Workshop

In addition to MOTIIVE, presented the WISE data exchange schemas and the WISE services.

This was not to comment on the schema design process, but to highlight the type of information that needs to be exchanged.

© HR Wallingford 2007

WaterML Workshop Outputs

• What should be the thematic scope for a harmonized water resources information model? What key feature types should be included, and at what stage?

• The scope for the water resources information model should contain a core set of entities that are not governed by other standards authorities.

• These should include themes such as: surface water, atmospheric water and groundwater, and involve aspects such as water quality, quantity, water use including consumption, management and transport, as well as scientific modelling of water resources.

• Key entities involved in these themes include: observations and measurements, properties that are observed and measured (e.g. porosity), features that possess properties (aquifer), processes and events (water flow, flood), human artefacts (instruments, wells).

© HR Wallingford 2007

WaterML Workshop Outputs

• How should the harmonized model be achieved? What is the target level of abstraction for the model (conceptual, logical, physical). Should the model be an aggregation, conflation, or selection of existing initiatives?

• A common conceptual data model should be developed for core entities; the model should be drawn from existing efforts (by re-using and harmonising existing content) and be modular, extensible and well-defined.

• A small number of exchange formats (e.g. XML) should be developed to exploit the model, which should be hosted in a common registry alongside the model and related vocabularies. The common conceptual model and exchange format should be tested by existing information systems in a coordinated testbed.

© HR Wallingford 2007

WaterML – Where next

© HR Wallingford 2007

Links

• Motiive• www.motiive.net

• WaterML• www.seegrid.csiro.au• Keiran Millard

[email protected]