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

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 HA’s INSPIRE/GIS Strategy Does not take account of TechPol’s for Data Exchange or end-to-end SOA/SDI Architecture

8. APPLICATION SUPPORT Centralised Database Approach

9. Applications consuming URNM 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 – doesn’t 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 & Development IAM 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: 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.