Upload
quon-bell
View
67
Download
0
Tags:
Embed Size (px)
DESCRIPTION
INSPIRE, EC Water Standards and WaterML Workshop. Keiran Millard ([email protected]). HR Wallingford. Not for profit research, consultancy and software organisation in hydraulic engineering Floods, water, energy, maritime, coasts - PowerPoint PPT Presentation
Citation preview
INSPIRE, EC Water Standards and WaterML Workshop
Keiran Millard
Keiran Millard
© 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