210 likes | 355 Vues
Case study in Water Information Modelling. Dominic Lowe, Bureau of Meteorology Spatial Information Modelling Community of Practice 2 nd meeting, Canberra , 15 October 2013. Dominic Lowe, d.lowe@bom.gov.au. BoM – Multiple Information Streams. Climate Information
E N D
Case study in Water Information Modelling Dominic Lowe, Bureau of Meteorology Spatial Information Modelling Community of Practice 2nd meeting, Canberra, 15 October 2013 Dominic Lowe, d.lowe@bom.gov.au
BoM – Multiple Information Streams • Climate Information • Environmental Information – since 2010, National Plan for Environmental Information (NPEI) • Water Information – since 2007 Water Act
Case Study: Water Information • Water Information and the Bureau • Water Data Transfer Format • Relationship with O&M, WaterML • Water Information System in BoM • Challenges
Water Act 2007 • The Act gives the Bureau of Meteorology water information functionsthat are in addition to its existing functions under the Meteorology Act 1955. • The Bureau will now be authorised to collect and publish high-quality water information. The publications will include a National Water Accountand periodic reports on water resource use and availability. • The Bureau will also be empowered to set and implement national standards for water information. A major outcome of the Bureau's work will be increased transparency, confidence and understanding of water information.
WDTF • Water Data Transfer Format • XML Schema for encoding different types of water information • Observational data, including surface & groundwater • Water Markets (permits, entitlements, allocations) • Water Use (irrigation, urban use etc.) • BoM & CSIRO collaboration – starting 2008 as part of WIRADA • Several versions released, currently at 1.0.2 • Reverse-engineered UML model • Broad conceptual alignmentwith O&M and WaterML • Associated vocabulariesand validation rules
F WDTF 2.0 (scheduled 2014) WDTF 2.0 to be reframed as specialisation of WaterML 2.0 (TimeSeries, Ratings, Gaugings, Sections) WDTF 2.0 Adapted from WaterML2.0 Roadmap (Simon Cox, OGC TC Athens 2009)
AWRIS – the national water information system • Water data managed in AWRIS Data Warehouse • Ingests WDTF and other formats • Exposes data marts to provide backend resources for applications and reporting tools • Data Warehouse schema based on WDTF conceptual model
National Water Account http://www.bom.gov.au/water/nwa/2012/document/summary.pdf
AWRIS • Operational: • Millions of files ingested to date • Some WDTF, some other formats (e.g. CSV) • Many data providers, several tools for WDTF generation • Some water regulations supported better than others • A lot of effort still spent on ingest/post-processing to massage incoming data and work with data providers.
Components of water information system > 200 Data Providers Use Cases (e.g. Water Regs) Domain Knowledge Tool Vendors Business Rules Encoding Ingest processes Conceptual Model Examples Persistent Storage Logical Rules Docs Applications Vocabularies Information model and artefacts evolving to better meet business requirements
Governance challenges • Strict governance is key: • Schemas, Semantic Rules, Vocabularies must be well versioned and maintained according to agreed rules and processes. • Persistent identifiers, linked data concepts useful. • Connected governance frameworks need to be established at different levels: • Models, vocabularies, systems
Defined Business Rules • "Did you feed them after midnight?" • "Well, I gave them some chicken." Machine-readable: UML, xml schema, RDF, schematron etc. for scalable rules management - semantic and syntactic.
UML 'profiles' for business rules? Good in theory. e.g. different UML profile for each Water Information category. Attempted for WDTF 1.2 but became very unwieldy and high maintenance e.g. a change of model at the root level must be updated through all profiles manually. How to capture business rules effectively still open issue. Schematron useful for implementation but not for conceptual design phase. Other solutions?? Topic for reference group??
Data products • Data providers and tool vendors deal with data products not concepts. • They are generally dealing with the encoding level not UML. • Examples are informative, but are often interpreted as normative... • Examples should be specific and targetedto use cases. • Examples should reflect real world applications. • Most consumers of data won't investigate the underlying conceptual model. Need to make interpretation of models easy – more emphasis on examples, documentation etc.
R&D > Enterprise Tooling Roadmap SolidGround DocGen PiD SiSSVoc FullMoon Operational (BoM) R&D (CSIRO) Enterprise Governance Experimental Instances Functional Instances (in use) Initial Operational Instances Evolution takes time!
Thank you Dominic Lowe d.lowe@bom.gov.au