Exploring Solution Options

URNM and the GIS Strategy

CENTRALISED VERSUS DISTRIBUTED

Data Architecture

Centralised

• Geospatial applications access a common geodatabase

• Network Model is centralised

• New applications have to be designed to use this external database/schema

• Migration issues for existing systems

Distributed

• Geospatial applications have their own local database

• Network model is distributed

• Needs a common schema for data exchange

• Eases migration issues for existing systems

CONFLATIONCentralised Database Approach

Option 1 - Database Conflation – COTS tools

• Requires bespoke development

• Expensive to develop and maintain

• Does nothing for HA’s INSPIRE/ GIS Strategy

• Does not take account of TechPol’s for Data Exchange or end-to-end SOA/SDI Architecture

• Does not take account of HMG Policy on Open Source

Option 2 - Database Conflation – Open Source tools

• Does take account of HMG Policy on Open Source Software

• Eliminates licensing costs

• Requires bespoke development

• Expensive to develop and maintain (manpower)

• Does nothing for HA’s INSPIRE/GIS Strategy

• Does not take account of TechPol’s for Data Exchange or end-to-end SOA/SDI Architecture

APPLICATION SUPPORTCentralised Database Approach

Applications consumingURNM Data Services

• Geospatial applications access a common geodatabase

• Network Model is centralised

• New applications have to be designed to use this external database/schema

• Migration issues for existing systems

• Not generic to all GIS applications and databases

• May not be suited to COTS-based solutions

CONFLATIONDistributed Database Approach

Layers of Transportation Data

• The State of the Network:• The Events Layer – contains objects such as

vehicles moving across the network.

• The Unified Road Network:• The Routing Layer – contains more complex

features such as “No exit”, e.g. at the intersection of a bridge and tunnel.

• The Reference Network Layer – contains all of the base road data . This data has a linear spatial representation and has an underlying topological structure that defines the connectivity and adjacency of links in the road network.

Ordnance Survey Mastermap Layers

• The Imagery layer contains 24-bit raster graphics.

• The rest are “features” in Geographic Markup Language (GML).

• Unique common reference feature (TOID).

APPLICATION SUPPORTDistributed Database Approach

Option 1 - GO Publisher

• Provides an INSPIRE/OGC-compliant Publishing service.

• Leaves existing databases in situ – minimal impact.

• Treats GIS as a special case – doesn’t re-use generic XML common services.

Option 2 – Cascading WFS (1)

Option 2 – Cascading WFS (2)

• Provides an INSPIRE/OGC-compliant Publishing service.

• Leaves existing databases in situ – but requires upgrade to WFS.

• Treats GIS (GML) the same as other generic XML data exchanges.

• Builds on:

• OS MasterMap layers.

• EA Technology Policy Framework:• Common Information Model.

• Enterprise Service Bus.

• Inter-System Data Exchange.

• Internal GIS/Geospatial Interfaces.

FROM BESPOKE APPLICATIONS TO COTS

GIS Applications (Consumers)

HAPMS – As-Is

• Based on Pitney Bowes Insight “Confirm” COTS package.

• Supports multiple application modules including:

• SWEEP;• Whole-Life Costs;• Scheduled Road Works;• Accident Records; and• Delay Cost Model.

• Not all in-scope for IAM Programme .

Network Delivery & DevelopmentIAM COTS Example

Main candidates: Pitney Bowes Insight (Confirm), Exor, Symology.

TI2011+ Move towards COTS?

• e.g. ITIS Holdings - TrafficScience

INM - Move towards COTS

• CUTLAS is fully compliant with UTMC specifications.

• Integrates data from traffic control, street asset and other traffic/highway-related subsystems.

• Implements high performance ENVITIA MapLink command and control to provide full GIS capability.

UTMC-IAM Integration

Case Study: Oxfordshire County Council

Standards-based Integration

• Service-Oriented Architecture (SOA).

• Enterprise Service Bus (ESB).

• Incremental Deployment.• Re-use of Legacy Systems

which still provide business value.

• Sweat assets instead of wholesale “rip and replace”.

• Reduce costs.

Typical COTS Features• GIS User Interface• Support for leading Spatial Databases• Support for OGC standards – WMS, WFS, etc.• Flexible Web Services• OS MasterMap ITN support• Snap to OS MasterMap facility• Support for the Traffic Management Act (TMA)• Network Definition & Management with multiple linear referencing• Compliance/Integration with BS7666 – National Land & Property

Gazetteer• 2-way transmission of EToN Notices• Spatial representation & Management of:

• Link/Node Network structures• Street Gazetteer• Associated street data• UK PMS Defects & Treatments• Street works• Traffic pinch points• Import/Export and maintenance of NSG

Common Denominators

• GIS User Interface• Spatial Data Infrastructure• Spatial database• Standard OGC Web Services• Modular design• Open interfaces• Multiple location referencing systems may

be overlaid with automatic translation from one referencing system to another.

Conclusions • URNM was originally conceived against an As-Is Architecture with

22+ siloed solutions.• The To-Be Architecture is converging on two COTS-based

Application Frameworks:• ND&D: IAM (currently out to OJEU);• TMD: Integrated Network Management is rolling out Envitia’s Cutlas (UTMC) system.

• Each of these are converging on Open standards such as OGC Web Services.

• OGC supports a Distributed Architecture.• INSPIRE’s Transformation Services allow organisations to meet

their legal obligation whilst ensuring continuity of their existing business systems.

• URNM needs to ensure it doesn’t “reinvent the wheel” and aligns with EA Principle of “Re-use before buy before build”.

• URNM should be:• A Data Exchange Model (PIM/PSM);• A subset of the Generic Common Information Model;• An INSPIRE-compliant “Public” GML Schema.