Exploring Solution Options URNM and the GIS Strategy.
-
Upload
valerie-brooks -
Category
Documents
-
view
217 -
download
0
Transcript of Exploring Solution Options URNM and the GIS Strategy.
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.