LINEAR REFERENCING SYSTEM (LRS) PILOT PROJECT REPORT

Transcription

1 LINEAR REFERENCING SYSTEM (LRS) PILOT PROJECT REPORT April 2002 sponsors:

2 TABLE OF CONTENTS 1 INTRODUCTION Background URN ORN URN/ORN Challenges Traditional segmented approach Linear Referencing Systems (LRS) LRS PILOT PROJECT LRS Pilot Project Participants Analysis and Design Process Data Models and Data Dictionaries Data Model Test and Vendor Participation CONCLUSIONS Challenges... 15

3 1 INTRODUCTION This document details the results of a Linear Referencing System (LRS) Pilot Project jointly conducted by Canada (NRCan) and Land Information Ontario (LIO). The following sub-sections and sections provide an explanation of the situation leading up to the pilot project, the stimulus for initiating the project, the project participants and expectations and the results of the project. 1.1 Background URN In 1999, NRCan, commenced the Updated Road Network (URN) Project. The URN project will replace the dated National Topographic Data Base (NTDB) with more accurate, current and detailed road network information. Wherever possible, NRCan is working with its provincial counterparts to build the URN. Once built, NRCan and the respective provincial or territorial partner will each be able to use the URN for their business purposes. Additional information on the URN is available by contacting or by visiting the web site at ORN In Ontario, LIO is the agency that is working with NRCan on the URN project. LIO has a broad mandate to support a wide range of spatial data in the province. LIO decided to extend the URN to add road information not in the URN but of interest to the province. Under the terms of the agreement, LIO is adding this information and will also maintain the URN data to a level that is acceptable to NRCan. In addition, LIO is pursuing a data sharing business model between the province and its municipalities. In the Ontario business model, the municipalities will play a significant role in maintaining the data. Updates will roll up from local agencies to the LIO Warehouse for integration into the LIO Data Warehouse. The LIO Data 3

4 Warehouse operations would then roll-up the changes for inclusion into the national URN. In Ontario, the URN plus the additional data is referred to as Ontario Road Network (ORN). Additional information on the ORN is available by visiting the Land Information Ontario web site at URN/ORN Challenges The main challenge of this project is to find a common geospatial model that will enable organisations to exchange information that complies with their respective business model. Furthermore the level of complexity of the National Road Network (NRN) and the ORN will increase when their partner data is utilized Traditional segmented approach The initial URN and ORN data dictionaries and models are based on the traditional segmented data model approach. The length of the geometric segment of a road (or the object definition) is defined by the associated URN or ORN data model. These models define the spatial relationship, feature classes and associated attributive information. The model defines the segmentation rules. As a result in the traditional approach, the segment is subdivided into smaller segments at the location of a change in an attribute value (e.g.: surface type, bridge, etc.). The following figure graphically depicts a segmented road model. Figure 1 - Segmented Road Model Example bridge node node node node node asphalt gravel 4

5 In the above example, the bridge requires a break in the geometry. Additional breaks will occur at surface type changes, etc. As can be deduced from the above, the difficulty with the segmentation approach is that the physical road segmentation must also change when an attribute value location changes. By doing so, the object definition is not stable over time. Synchronizing and exchanging changes with many maintainers and users of the URN and ORN databases will be difficult. In addition, any new attributes added to the model may also require a resegmentation of the entire database. The segmented model makes conflation with other data difficult as well. NRCan and LIO questioned the segmentation model conceived for both the URN and ORN and the difficulties of managing data with the multiple maintenance partners envisaged for each database Linear Referencing Systems (LRS) Major GIS system vendors, research groups and transportation network specialists have been researching LRS techniques and approaches. Linear referencing is an approach whereby the attribute information is related to the segments by linear measurements from defined locations such as an intersection. With this approach, attribute value and feature location changes along segments require the re-computing of the measurement value. Furthermore, additional business information may be added as a new set of attributes and linear measurements. The restructuring of major parts of the database are not usually required especially the re-segmentation of the geometry. The following figure graphically depicts an example of this approach. 5

6 Figure 2 Linear Referencing System (LRS) Example node bridge node node asphalt gravel In the figure above, the bridge is represented in a table as a linear event that occurs along a segment. The linear measurement is represented as starting a specified distance from a known location. A new bridge can be added to the network without re-segmenting the geometry. The surface types are also represented as linear events along one or more segments. 2 LRS PILOT PROJECT The URN/ORN project team realized that the research and development into LRS database design and development was at a point where this should be reviewed as a possible option for the URN and ORN. An LRS Pilot Project was designed and commissioned to investigate the practicality of LRS for the URN and ORN. NRCan, LIO and GeoConnections agreed to jointly fund the project. The project began in late spring of The project steps were: 1. Develop a logical data model and data dictionary of the features in the current ORN and URN. 2. Build a corresponding physical test database. 3. Conduct database transaction testing (spatial and attributed data load/extract, modify and delete). 4. Report the results to GeoConnections and others. 5. Understand and determine the impacts of the use of a linear referencing model for the ORN and the National URN. 6

7 The project sponsors required the project to follow these guidelines: 1. The data model that would be developed must be open. 2. The pilot (project) must have municipal participation. 3. Formal testing practices and results reporting to be followed. 4. Standards must be followed. 5. The test data must include urban and rural data types. 6. The test data must include two adjoining municipalities. 7. Include subject matter experts where appropriate. 8. Involve the private sector where appropriate. 2.1 LRS Pilot Project Participants The project participants included technical and business representatives from following agencies: Ontario Ontario Transportation Land Information Ontario City of Toronto Canada Elections Canada Transportation Canada Cuesta Systems Inc. of Burlington, Ontario, provided facilitation and project support. Geoplan Consultants Inc. of Fredericton, N.B. also provided a situation analysis to the team. The Pilot Project was intended to be a practical test to apply the latest LRS thinking to the URN/ORN situation and to determine the state of LRS technology in the commercially available off the shelf GIS and road network software. The GIS and road network software vendors with installed systems in Canada were invited to participate in the project. 2.2 Analysis and Design Process The documents that were examined by the Project Team were the: National Cooperative Research Program (NCHRP) Generic Data Model for Linear Referencing Systems ISO/TC 204 Transportation Information and Control Systems Geographic Data File, version 4 (GDF) standard 7

8 NCHRP: The central notion is that of a linear datum that supports multiple cartographic representations (at any scale) and multiple network models (for various application areas). The datum provides the fundamental referencing space for transformations among various linear referencing methods, network models, and cartographic representations. It also links the model to the "real world" through attributes that describe its location and spatial characteristics in real-world references and measures. The linear referencing system can be thought of as all those components of the model that provide methods for location referencing of business data, transformations among those methods, and linkage of the model to the "real world" and its cartographic representations. For additional information on NCHRP, please refer to the following web site: GDF; The Geographic Data Files (GDF) standard was developed as a draft submitted to the European Committee for Standardization (CEN). A consortium of public and private entities developed GDF in order to improve the efficiency of the capture, the production and handling of road related geographic information The GDF standard has been developed to meet the needs of professionals and organizations involved in the creation, update, supply and application of referenced and structured road network data. GDF is a non-application specific data model with the intention that specific applications can be built from the basic elements. For detailed information on GDF, please refer to the following web site: 8

9 2.3 Data Models and Data Dictionaries Analysis and design sessions were held between May-July 2001 to familiarize the project team with the NCHRP approaches and to translate the segmented URN/ORN data models and data dictionaries into the theoretical NCHRP NRCan, worked with Laval University to review GDF standards between December/2001 and January/2002. The URN/ORN dictionaries were compared and migrated to the GDF. Working sessions with the LRS technical team to review the findings is planned and is expected to be completed in late spring As a result, the URN/ORN data model mapped to GDF is still under review and is not at a point that it is not yet available for this report. (Draft models can be made available as noted on page 16.) 2.4 Data Model Test and Vendor Participation In October/2001, the commercial off the shelf vendors having product implementations in Canada were provided an overview of the project and were invited to demonstrate their LRS offerings to the team and to comment on the ORN theoretical model developed by the team. The objectives of the vendor participation were twofold. The first was to inform the vendor community as to the technical directions NRCan and LIO were considering with respect to managing the URN and ORN. The second objective was to assess the merits of the theoretical design with the practical implementations of the vendor community. The vendors were duly informed that their participation was entirely voluntary and that the exercise was not a precursor to a procurement exercise. Several vendors had other commitments and could not respond in the time frame that the project required. The following table lists the vendors that were approached and participated in the test. Table 1 - Vendors Invited Participated Autodesk Yes Bentley declined ESRI Canada Yes Geoplan Consultants Yes Intergraph Yes 9

10 MapInfo Canada declined CARIS declined The participating vendors were provided URN and ORN data extracts, the theoretical model developed by the team and a set of objectives that the team felt would provide the greatest insights into the practical use of commercial LRS technology for URN and ORN data management. The following table lists the test objectives that the project requested the vendors demonstrate and the summary findings from the vendor responses/demonstrations. Table 2 Test Objectives and Results CORE SYSTEM CAPABILITIES The project team understands that LRS concepts and technologies to support the concepts are not fully mature. The JAD sessions at the beginning of the project identified foundation data needs and the entities and their relationships that were required for managing URN and ORN data from an LRS perspective. The following are the data issues the team were interested in understanding how the vendor systems managed. General requirements and results: seamless database: o The systems adhered to the seamless database concept. To do so, the vendors used RDBMS technology (Oracle or SQL-Server) as the database engine and storage mechanism. NAD83: o The systems tested supported the input of multiple datum's and projections for the data in the database. geographic coordinate use: o All systems could manage the data in geographic coordinates or other projections that eliminated partitioning. client/user interface: o All systems supported a graphical (map) user interface. system openness: o The internal storage used by the systems is proprietary. The systems used Oracle Spatial or the ESRI SDE geodatabase structure. Vendor specific client interfaces were provided. o The systems also provided, COM objects and/or API tools for developing 10

11 CORE SYSTEM CAPABILITIES customized access to all data (coordinate and textual values). However, care would have to exercised when customizing that the referential integrity for entities is not compromised. Data model mapping results: In general, the data dictionary developed by the LRS Team required only slight modification for use in the vendor systems. The prototype logical data model developed by the LRS Team could not be used directly by the vendor systems. Each vendor mapped the LRS entities and relationship definitions to their system in order to mimic the intent of the LRS Team logical model relationships. In general all of the vendor systems could mimic the relationships developed in the LRS Team logical model. However, the review team noticed some weaknesses (and some strengths) in these differences. Not all of the vendor products could use all of the abstractions the team thought necessary (e.g.: traversals and anchors). Address schema management: All systems could manage civic addressing schemas as well as the anomalies that occur with these systems. All used beginning left/right and ending left/right address combinations. In general, township, lot and concession addressing systems could not as easily be modeled using the traditional beginning/ending approach. No system provided native tools to managing this system of addressing. Road and place name management: All systems managed primary and secondary names either in secondary fields or in associated tables. Geometry management: linear/point events o All systems demonstrated the representation of features as both linear and/or point events. There were variations between the systems on how this was accomplished (either using separate point and linear tables or via off-set values). non-intersecting crossings o All of the systems could manage non-intersecting networks (e.g.: overpasses). However, the more sophisticated systems could relate events to a non-intersection. For example a rail station point event on a roadway is also an event on the railway. 11

12 CORE SYSTEM CAPABILITIES Use of other thematic data for background referencing: All systems tested supported background thematic layers. The themes used in the test included hydrographic features, municipal boundaries and other features. Offset referencing for events (linear and point): The vendor systems can all manage measured offset references. However, several vendors recommended against using the percentage measures that the LRS Team were considering. GPS support: The vendors indicated that GPS data collection devices are useable with their systems to collect field data. However, this feature was not demonstrated by any vendor system. Directionality (vertex order): The vendor systems split on the requirement that the order of the vertices in the segment be in the same direction as the segment. Compatibility across systems would require segment vertex flipping if directionality was managed by a field value. DATABASE MAINTENANCE AND GEOPROCESSING FEATURES A key aspect of the URN and ORN projects is to ensure that there is both a business and technological infrastructure in place to sustain the databases after they are built. As a result, any LRS technology must be able to manage change. The vendors were requested to demonstrate the following data management features: General requirements: linear and referential integrity checking o All systems demonstrated the capability of maintaining offset values after editing the geometry. o All systems utilized referential integrity rules to manage attribute changes in their databases. validation rules o Generally the vendor systems managed rules via the database relationship rules and programmatically. However, the levels of sophistication varied. change history 12

13 DATABASE MAINTENANCE AND GEOPROCESSING FEATURES o Change history was not available on all of the systems tested. The vendors that did not have the feature indicated that the feature would be included in the next software release. coordinate value maintenance o All vendors indicated that the geoprocessing tools provided would not introduce round off errors. However, the review team did not conduct any tests to verify this assertion. URN/ORN data conversion and loading level of difficulty: As expected, all of the vendors needed to conduct geoprocessing to convert the data provided into their constructs. This geoprocessing included spatial restructuring and attribute re-assignment. The review team concluded that the tasks conducted by each vendor could be automated in a production environment. Edgematching capabilities: All of the systems that could edgematch the data that was provided. The preferred approach was to edgematched prior to database loading. Geometry editing: All systems could change geometry. However, the geometric change processes the systems employed required varying degrees of complexity. Offsets and other attributes that referenced the geometry were managed with varying degrees of automation and complexity. The features demonstrated included: o adding new segments o merge/delete existing segments o modify the shape of segments o flip the coordinates of segments Attribute editing All of the systems could change attribute values. As expected different processes and procedures were employed to change different attribute values. The methods that were used by the vendors were also dependent on how its system structured the data. The editing features demonstrated included: o attribute value changes o extent/offset value changes o combinations of the above o traversal management (on those systems that provided this feature) o directionality (on those systems that provided or required this information) 13

14 DATA PUBLISHING/DISTRIBUTION FEATURES The purpose of the URN and the ORN projects is to develop standardized road network databases for use by government departments, ministries and agencies at the federal, provincial and municipal levels, the private sector and academia. Distribution in structures that are easy to understand and use is critical. The following are the features the LRS team wanted to understand in the vendor systems: General requirements: There is a known requirement to provide data in a variety of manners. All of the vendor systems demonstrated the ability to query the database and extract/export data by the following means: o selective extraction/export o clipping by pre-set area Those vendor systems that maintained audit trails and history could also extract data by changed/modified dates. Distribution by linear referenced model: The objective of this requirement was to ensure that data could be distributed from the system with its linear referencing information intact. However, this test was inconclusive because there is no standard for distributing LRS data. Each vendor could distribute their model in the following ways: o geometry and events o events only o geometry only Distribution by segmented model: All the vendor systems could re-segment the geometry and distribute data from their LRS structures re-segmented by specific attribute 3 CONCLUSIONS The technical documents the LRS Project Team analyzed, the theoretical design work and the results of the vendor testing indicate that LRS theory and the supporting technology is mature enough to consider its implementation for the repository structures of the URN and the ORN. However, this conclusion is not without its issues. As with all GIS technology options, the generic LRS tools available from the vendor community require customization and modification to meet the URN and ORN business needs. 14

15 LIO already has an extensive investment in technology and data in the LIO Warehouse. Therefore, the LRS technology LIO adopts must be compatible and complement its existing investments and its business relationships. NRCan will pursue the task of defining the exact usage of LRS technology within the larger context of the National Road Network (NRN). This exercise however, has allowed the Centre for Topographic Information - Sherbrooke (CTIS) to better understand the implementation constraint and advantages of LRS. Whether this technology is to be used as the data management tool or as a data product service must be further investigated. 3.1 Challenges NRCan and LIO are now considering the implementation and operational costs of adopting LRS from the standpoint of: data o the effort required to re-design and test the new data models and dictionaries o the effort required to re-structure existing data into the new model o how much LRS intelligence is in the existing data (e.g.: is there enough information to populate mandatory fields) o the effort required to have contractors and suppliers provide maintenance data with LRS intelligence and an LRS ready format organizational capacities o internal management system designers and developers technical staff o external support (academia and the business sector) technology o what is the most appropriate off the self technology to use o how much additional functionality/customization is required to that software business o what are the internal cost implications o the implications on their partners o the implications on clients and stakeholder 15

16 Status - Data Dictionary and Data Model Throughout fall 2001 and winter 2002, OMNR and CTIS developed a data dictionary and data model. Both documents are being referred to as beta versions until review and input has been received from the other Canadian provinces and territories. During the April 2002 session of the Canadian Council on Geomatics, participants were provided an update on work undertaken and an opportunity to comment. From that meeting it was determined that an expert panel would review the dictionary and model for potential adoption at a national level. Work is planned to continue developing and describing 4 models: LRS, Segmented, Delta LRS, Delta segmented. As well, the followings items are to be investigated or further expanded upon: Unique Universal Identifiers (128 bits - 32 characters), GDF conformance, exit numbers, civic addressing, transport crossings, linear reference points, directionality, and the concept of road levels. Interested parties wishing to see a copy of the draft Ontario Road Network (ORN) data dictionary and model can contact: Tom Malone Ontario tom.malone@mnr.gov.on.ca Interested parties wishing to see a copy of the draft National Road Network (NRN) data dictionary and model can contact: Marcel Sabourin Canada msabourin@nrcan.gc.ca 16

17