Exploring Solution Options

1
Exploring Solution Options

• URNM and the GIS Strategy

2
Centralised versus Distributed

• Data Architecture

3
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

4
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

5
Conflation

• Centralised Database Approach

6
Option 1 - Database Conflation COTS tools

• Requires bespoke development
• Expensive to develop and maintain
• Does nothing for HAs INSPIRE/ GIS Strategy
• Does not take account of TechPols for Data
  Exchange or end-to-end SOA/SDI Architecture
• Does not take account of HMG Policy on Open Source

7
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 HAs INSPIRE/GIS Strategy
• Does not take account of TechPols for Data
  Exchange or end-to-end SOA/SDI Architecture

8
Application support

• Centralised Database Approach

9
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

10
conflation

• Distributed Database Approach

11
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.

12
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).

13
Application support

• Distributed Database Approach

14
Option 1 - GO Publisher

• Provides an INSPIRE/OGC-compliant Publishing
  service.
• Leaves existing databases in situ minimal
  impact.
• Treats GIS as a special case doesnt re-use
  generic XML common services.

15
Option 2 Cascading WFS (1)
16
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.

17
From Bespoke applications to cots

• GIS Applications (Consumers)

18
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 .

19
Network Delivery DevelopmentIAM COTS Example
Main candidates Pitney Bowes Insight (Confirm),
Exor, Symology.
20
TI2011 Move towards COTS?

• e.g. ITIS Holdings - TrafficScience

21
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.

22
UTMC-IAM Integration
Case Study Oxfordshire County Council
23
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.

24
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

25
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.

26
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
• NDD IAM (currently out to OJEU)
• TMD Integrated Network Management is rolling out
  Envitias Cutlas (UTMC) system.
• Each of these are converging on Open standards
  such as OGC Web Services.
• OGC supports a Distributed Architecture.
• INSPIREs Transformation Services allow
  organisations to meet their legal obligation
  whilst ensuring continuity of their existing
  business systems.
• URNM needs to ensure it doesnt 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.