Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs...

11
Water Quality Data Publishing Architecture

Transcript of Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs...

Page 1: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Water Quality Data Publishing

Architecture

Page 2: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Architecture

• Not just components….

• System behaviour– User needs– All users with a stake in success

• Governance– = User + Supplier Confidence

• Renewal and extension Use Cases

• Semantics (Information Architecture)

Page 3: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

RM-ODP

• Tried and true methodology

• Viewpoints– Enterprise– Information– Computational (components and interfaces)– Engineering– Technology

Page 4: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

CANRI

• Relatively easy – proven, don’t need to do much ad-hoc to build complete systems

• Also supported and framed by CANRI computational architecture

• Governance, Information, Engineering– Less mature, domain specific, needs work– regardless of computational platform

Page 5: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Robustness

• Build for the future– Musn’t break as new products or applications

added– Anticipate extension, integration, functions– survive change of organisations/roles

• Distributable– All components may be moved, upgraded,

rebuilt

Page 6: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Enterprise Viewpoint

• Emerging data standards

• Modular standards – Easier– Better– More stable– Some technology demands

• Lifecycle planning

Page 7: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Lifecycle planning

• Data standards need lifecycle planning– Initial implementation– Key harmonisation processes– Roadmap

• Review• Gap analysis (what would we like to re-use?)• Adopt/Adapt• Engage with interested parties• Versions• Gateways/Deprecation• Communication

Page 8: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Information Viewpoint• Features• Have properties• With domains (allowable values)

• Each property– Name– Namespace– Definition– Lifecycle– Roadmap

Page 9: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Computational Viewpoint

• WFS is fine

• Can be made to support large compressed data if required (no streaming of gigabytes expected)

• WFS + – Decouple Query semantics from response– Change request to OGC– Powerful, safer, more predictable

Page 10: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Technical Viewpoint

• Geoserver– Used in SEEGrid to prove scientific data can

be served via WFS using external data standards

– Limited object models, but still better than GIS-only

– Spatial and aspatial related data– Based on v1.2 – on a branch– Issues accepted in core roadmap– Needs refactoring of geotools libraries

Page 11: Water Quality Data Publishing Architecture. Not just components…. System behaviour –User needs –All users with a stake in success Governance –= User +

Geoserver Strategy

• Harmonise with v1.3

• Compare with Use Cases, Data model – Enterprise Viewpoint– Information Architecture– Engineering Considerations– Computational (fixed (WFS + query), phew!)