© MarineXML 2006 Slide 1 of 16 RISE / MOTIIVE HAB+PB Brussels, Belgium, 4 th October 2006 MOTIIVE...

RISE / MOTIIVE HAB+PBBrussels, Belgium, 4th October 2006

© MarineXML 2006 Slide 1 of 16

MOTIIVE12 Month Summary

Keiran Millard1, Andrew Woolf2, Jeremy Tandy3 ,Chris Higgins4, Roger Longhorn5, Rob Atkinson6

1HR Wallingford, Wallingford, UK2Central Laboratory of the Research Councils, Harwell UK

3Met Office, Exeter, UK4EDINA, University of Edinburgh, UK

5IDG, Belgium6Social Change OnLine, Australia



Marine overlays on Topography• Land Meets Sea

– What differences drive different data models?• Same issues - but more critical in met/marine

– What similarities are there?• Navigation community

• Modelling across and between different domains– Common patterns

• Meteorology and Marine Community– Feature / object data models

• “Separation of Concerns”– Operational Service Chains

• “Processing Affordance”



Marine overlays on Topography

• Standards Development Expertise– GML Authorship– Inspire drafting teams– Domain standards development

• WMO, IHO

• Service developers• Key focus on getting ‘standards in

place’ for implementation



What’s driving the developments?

Data DataData Data

Hydrodynamics

WaterQuality

Component

ComponentComponent

Component

EO In-situ

Data Data

Model

ICZMR Customer

base

WFD Customer

baseHydrodynamic Data

(nowcasts, forecasts, hindcasts)Data

Typology Map

SustainabilityIndicators

Sediment Cell

Mapping

Shoreline Impact

Topography

WQ Indicators

Navigation Customer

Base

Component

NavigationCharts

GMES, GEOS, GOOS…. The badge may be different, but the general need to pull together different data sources, processing services and users in a cost-effective (interoperable) manner remains.

Nothing new…

find and use data…

but this is a hard problem to solve

Metocean Information needs;

-less concerned about charting and map production

-More concerned with service chaining

INSPIRE…How do you use ISO & OGC standards to deploy cost-effective services? - MOTIIVE

-Extend service to new jurisdiction (region)-Add New data sources-Add new processing models-Add new customer



Back to ISO TC211 • The key to interoperability is the formalisation of

shared knowledge in communities through the definition and cataloguing of ‘feature types’. – But what is ‘a Feature?’ and how should is be

defined? • Conceptual models for features can be

formalised in a canonical XML encoding through the Geography Markup Language (GML). – But what is the best way to develop a GML

Application Schema? – RISE Methodology• Registries can be used to manage Features

– But we don’t have a reference registry implementation



Marine Community defining Features?

SciencePhysicalChemical

Biological

Dredging & Extraction

Conservation

FisheriesAquaculture

Water Quality

Energy

=

The marine community is broad and there is no ‘one size fits all marine feature’ (MarineXML Position Paper 2005).

Meteorology

Navigation

As this is the community, the lack of clear rules means there is significant scope for variation in how the feature is defined; these feature types may lack coherence and consistency with each other. So….



What is a Feature in the Marine Domain? • If something has a specific name or classifier

then it is probably a feature (Met Office Workshop Communique)

• Features are an implementable subset of a conceptual model that may be based on;– Geometry / topology– Semantics [Natural Language] / Governing equations– Sampling regime

• This separation of concerns results in the ability to create a set of consistent Feature Types



Separation of Concerns…cd Logical Model

DomainConceptualModel

Cov erageView

RepresentationalView

SimpleFeaturesView

StorageModel

O&MView

«interface»ProcessingAffordance

«realize»«realize»

«import»

…to be able to create a suite of consistent Feature Types that can be defined in response to a specific requirement (use case).

“Subscribe rather than describe”

The Climate Science Mark-Up Language (CSML) developed by NERC Data Grid provided a robust Application Schema to realise the ‘coverage view’.

Processing Affordance means ‘what can I do with the data’ and is central to what interoperability is all about.

The OGC collection and processing meta-model (Cox et al).

What works with ‘vanilla GML’.

May not be implementable



Processing Affordance.

• Operational Interfaces for Feature Types– This leads to true interoperability; allowing a user to

discover an object of interest, browse by navigating associations and execute a chain of processes on some dataset to derive added value.

• Defines a declaration of intent, describing the operations that can be invoked– Feature has attributes p,q,r to support f(p,q,r)

• Is supported by the GFM, but not XML Schema– One possible approach is to define PA as an object in

a registry– Likely need for an extension of the GML profile of

UML (changes to rules of mapping UML to GML)



CSML Features

Includes wrapper for NetCDF, GRIB, NASAAmes

Seven Feature Types

CSML feature type principles:•offload semantics onto parameter type•offload semantics onto CRS•‘sensible plotting’ as useful discriminant



Interoperability cannot be achieved by an application schema alone.

• A set of well defined service interfaces are vital to ensure that data can be accessed in an implementation agnostic fashion .

• A key enabler of interoperability is the registry. The registry provides the capability to publish (and govern) application schemas, phenomena dictionaries, controlled vocabularies, service bindings etc. for all to see and use.

• Furthermore, it is the registry that enables associations between objects to be expressed.

• This leads to true interoperability; for example, allowing a user to discover an object of interest, browse by navigating associations and execute a chain of processes on some dataset to derive added value.



Achievements #1• Agreement with marine GMES projects (IP WIN / GSE

MARCOAST) on the ‘best approach’ for using OGC / ISO specifications to underpin data services. This ‘best approach’ highlights the need for a reference implementation of a Feature Type Catalogue to facilitate the development and deployment of Application Schema. Co-development workplan established in principle.

• Engagement with World Meteorological Organisation and United Nations Working Group on Geographic Information with regard to development and alignment of best practices and supporting infrastructure for deployment of data standards.



Achievements #2• Establishment if a ‘Domain Modelling’

WG’ under the auspices of OGC– Long term sustainability

• Broad alignment with RISE on the specification for the development of AS and testing this method in the marine domain

• Comprehensive analysis into the approaches that can be used to evaluate the cost-benefit of data standards to underpin SDI development



Issues #1

• End-user engagement– What do users need to know?

• Achieving alignment– Very successful, but impact on

programme



Implementation #1• The EU MOTIIVE and the Australian Oceans

Portal project are collaborating to deliver an ebRIM registry/repository implementation, focusing on delivering a feature type catalogue– service bindings, data standards driven query models,

presentation resources and processing chains will also be exposed within the registry.

• The Met Office has proposed to initiate a parallel track to develop a second reference implementation based on the OGC Catalogue Services for Web (CSW) for (at least) the same set of use cases.



Implementation #2• MARCOAST / WIN / MOTIIVE /

ORCHESTRA registry testing.– Common GMES position– To be used in ECOOP / MERSEA

• A number of interoperability tests across MOTIIVE/ Oceans Portal, MarineXML and Met Office registries.

• OGC Change Requests– Details in domain modelling WG.



End Outcomes #1• Reference Implementation of a FTC

– This exploitable is a concrete (reference) realisation of the abstract ISO19110 specification for a Feature Type Catalogue (FTC). The purpose of this reference implementation is for other to use to develop and deliver web-based services. The lead partner on developing this deliverable is SCO, with CCLRC, EDINA and HRW used in its testing and deployment as part of MOTIIVE. The GMES project WIN (MARCOAST) will also have some input to this process. It has been preliminary agreed that OGC will take ownership of this specification and make it available alongside the other OGC specifications.



End Outcomes #2• FT Definitions for use in the marine

domain– This exploitable result is a series of data models

and GML application schema of ‘marine Feature Types’. Although classed as ‘Marine FT’s’ they are broadly applicable to any domain undertaking measurement and modelling of the environment. It builds on the CSML specification developed as part of MarineXML by CCLRC and this specification is revised and extended to take accounts of the user needs identified as part of MOTIIVE. It has been preliminary agreed that CCLRC will manage and maintain these FT’s for others to use.



End Outcomes #3• Methodology for using OGC

Specifications– This exploitable deliverable represents

knowledge on using OGC specifications to develop and deliver information products and services. It makes reference to the two exploitable deliverables in the previous chapters. This methodology is being jointly developed with the RISE project and MOTIIVE partners. It has been preliminary agreed that this will be a public document, but post-project ownership (from an update perspective) needs to be clarified.



Developments in Marine Standards

www.marineXMLnet

www.motiive.net

[email protected]



MOTIIVE Deployment

Service binding to FTCs

-Water Level on map

-Water level as time series

-Water level as report

-Water level as ‘specialist’ FT

To meet different user needs







CSML in MarineXML Test Bed

XM

L P

arser

SeeMyDENC

Data Dictionary

S52 Portrayal Library

SENC

MarineGML

(NDG) Feature

Types

XML

XML

XML

Biological Species

Chl-a from Satellite

ModelledHydrodynamics

XSLT

XSLT

XSLT

XSLT

XSD

XSD

XSD

XML

XML

XSLT

XSLTMeasuredHydrodynamics

S-57v3 GML

XML

XSD

XML

XSD

Worked well for all coverages, but ‘unimpressive’ for the data on biological sampling stations (O&M)

Translation of data from native data models to CSML;

•Forecast wave data

•Sediment and Chl-a from satellite

•Measured current data at different depths

•Biodiversity at designated sampling stations



CSML FeaturesCSML 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

ProfileFeatureSingle ‘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

Date post:	04-Jan-2016
Category:	Documents
Upload:	christian-peters
View:	215 times
Download:	2 times

© MarineXML 2006 Slide 1 of 16 RISE / MOTIIVE HAB+PB Brussels, Belgium, 4 th October 2006 MOTIIVE...

Documents