Download
1 / 24
240 likes | 379 Views
Anthony Beck. School of Computing FACULTY OF ENGINEERING. PROJECT VISTA: Integrating Heterogeneous Utility Data A very brief overview. Visualising integrated information on buried assets to reduce streetworks (VISTA) The Project. VISTA. 4 Year project funded by the DTI
E N D
Anthony Beck School of Computing FACULTY OF ENGINEERING PROJECT VISTA:Integrating Heterogeneous Utility DataA very brief overview
Visualising integrated information on buried assets to reduce streetworks (VISTA)The Project
VISTA 4 Year project funded by the DTI now the Department for Business, Enterprise and Regulatory Reform Joint project: Academic partners Leeds and Nottingham universities. In collaboration with 20+ utility and other partners. Goal: to reduce the direct and indirect costs of utility maintenance associated with the highways. Aim: Swift, safe, cost-effective streetworks. Catalyst: The Traffic Management Act 2008. Legislation will expect utility companies to share their asset data digitally. Leeds Research Challenge: More effective integration, representation and use of existing digital assets. Problem: Each utility organisation maintains their data in different database environments with different logical and physical models. Solution: To find mechanisms to integrate heterogeneous data to generate a seamless and consistent integrated virtual data model. Utility users should have timely and appropriate access to the data they need.
The Problem Streetworks - Small operational improvement translates into large economic saving c. 4M street openings p.a. Direct costs of £1B p.a. Indirect costs of £3B-£5B p.a. Pollution, congestion etc. Need to know asset location and attributes: Planning Management Maintenance Can take months to generate composite maps Many databases: varying accuracy and provenance Safety! Recent example – 3 near misses on high voltage electric in one city in one week. Data not collected Data ignored!
The Problem Abstraction of reality Reality
Water: Omissions Inconsistencies Spatial inaccuracies Uncertainty Which representation is correct?
Problem Domain Different ways of storing asset data Paper – CAD – GIS Raster to Vector conversion Different ways of structuring digital asset data Different syntactic and schematic models Global Schema based integration Different ways of describing asset data Semantic inconsistency Thesauri/ontology reconciliation Different ways of sharing and representing asset data Paper – CAD – GIS Different symbols and conventions Uncertainty User/domain tailored visualisations
Utility Asset Management For Street Works this rich data model can be reduced to a single print out.
Integration work in MTU and VISTA Aims: provide a framework which will integrate information from multiple utility asset stores. Syntactic (format) integration Schematic (design/model) integration Semantic integration Objectives: identify and agree a core set of location and attribute data to provide a common framework within which to represent these multiple information sources to construct and evaluate a prototype system
Why VISTA integration? In principal Integration can occur if each utility dataset were made available as a WFS In practice this would lead to: Knowledge articulation issues: semantic inconsistency Limited query, analysis and visualisation: schematic inconsistency VISTA aims to fully integrated source data models to increase domain knowledge
Virtual Integration Framework The framework supports utility integration at two levels: the schema level Integration based on a common utility data model (global schema) Resolves schematic heterogeneity the data level Ontology/Global Thesauri employed at the data level Resolves semantic heterogeneity When the same asset type is given different names by different companies When different asset types are given the same name by different companies
Resolving syntactic heterogeneity OGC interoperable snapshot Only access necessary attributes (increased security) Proprietary GIS can be altered with minimal impact on system (increased flexibility) Reduced impact on server side processing overhead (increased operational activity) Potential to materialise results using change only updates (reduced processing overhead – improved access times)
Resolving Schematic Heterogeneity • Global Schema used to mediate integration • Mappings and transforms generated between source tables and the Global Schema • During prototyping metadata managed using Radius Studio • Allows rapid validation by utility partners • Data held within Oracle Spatial repository • Generic PL/SQL code defined to integrate source data and materialise the result set • Mapping and transformation metadata held in Radius Studio will be directly integrated as a service.
Resolving Schematic Heterogeneity Currently 29 Global Schema fields grouped into 11 types Distinguished between core and non-core data Asset x 10 fields (5 core) Condition x 1 field (0 core) Confidence x 1 field (0 core) Date x 1 field (0 core) Detection System x 1 field (0 core) Dimension x 5 fields (5 core) Domain x 4 fields (2 core) GIS x 2 fields (1 core) Location x 3 fields (1 core) Rehabilitation work x 1 field (0 core) Risk x 1 field (0 core)
Resolving Semantic Heterogeneity Generation of a cross domain global thesaurus Thesaurus: a list of terms linked together by hierarchical, and associative or equivalence relationships. Can be converted into an OWL ontology Developed within MultiTes Pro Reconciling semantic heterogeneities Focus on asset types and subtypes in water and sewer domains Subject Category Scope Note Used For Broader Term
