School of somethingFACULTY OF OTHER
School of ComputingFACULTY OF ENGINEERING
PROJECT VISTA:Integrating Heterogeneous Utility Data
A very brief overview
Anthony Beck
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.
VISTA
The Problem
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
Which representation is correct?
Uncertainty
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
VISTA
Integration Framework
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
Virtual Integration Framework
Virtual Integration Framework
Virtual Integration Framework
Virtual Integration Framework
Virtual Integration Framework
Generic Integration
Thank you
Top Related