project vista: integrating heterogeneous utility data a very brief overview

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