Elaine McAlister, Rudolph Nowicki

Street Wise in New Zealand

The Design and Construction of a New Zealand Road Database

Abstract

Increasing demand for a topologically structured, constantly maintained, flexible and generic roads database for cartographic, route analysis and navigational purposes in New Zealand has led to the birth of the project SPARCL (Spatial Address Road Centre Line).

The objective is to build a national road database to fit the largest possible range of customer needs. Using Arc/Info, ArcView and Dynamic Segmentation, basic road centre line data from a variety of sources were compared and joined, in order to produce basic routes for road name, classification and surface. This paper aims to describe the difficulties and pitfalls in designing and building such a generic database as well as illustrating the advantages.

____________________________________________________________________________________________

Background

New Zealand is small; it is 266,000 sq km; a population of 3.6 million; approximately 60,000 roads (131,000,000 km’s). Compared to other developed countries this would be considered meagre, however, the construction of a national road centre line database was an ominous task.

Why we started?

Before describing what was involved in constructing the database, it is necessary to explain the reasons for starting. Terralink NZ Limited (Terralink) is a geospatial information company whose primary interests are in collecting, interpreting and reporting information relating to land, property and the seabed. Realising the potential for a national road centre line database, Terralink conducted market research into existing road centre line databases within New Zealand and identified that there was a gap in the market for a database with the following characteristics:

• National seamless coverage
• Centre lines with a range of attributes to cover a number of market needs
• A physical road network which does not include paper roads (i.e. legal roads which have not been built)
• A generic product which covers a range of uses including geocoding
• A portable product which can be transferred between Geographic Information Systems (GIS)
• A product with comprehensive maintenance mechanisms.

The product commenced under the development name of SPARCL (Spatial Address Road Centre Line) which describes the key characteristics. As work advanced our Marketing department changed the name to National Road Centre line Database (NRCD) to emphasise the desired prominent position of the database in the New Zealand market place. Along with the strategic marketing objectives we also had to meet the following requirements:

• Form the basis for the production of street maps by Terralink's cartographic unit
• To provide data to the New Zealand Automobile Association for use in their emergency breakdown dispatch system
• To allow for future migration to GDF format for in-car navigation systems.
• To ensure core attributes would cover a range of applications for other clients
• To include date information to assist with incremental updates (although it was not specifically a temporal database)

Building the NRCD

Data Sources

Data used in the initial construction of the NRCD was derived from three sources:

(i) A national cadastral database

(ii) Urban street maps

(iii) A national topographic database.

Each database differed in terms of geographical coverage and the attributes offered to the final product.

(i) The most nationally comprehensive road centre lines in New Zealand are those from the Digital Cadastral Database (DCDB) which is held by Land Information New Zealand (LINZ). The government agency that maintains the legally defined property and road corridor boundaries. The DCDB is derived from casdastral plans and record maps ranging in scale from 1 : 500 to 1: 10,000. As part of the conversion process from paper plans to digital data, centre lines were digitised in the middle of the road corridor parcel. Two problems were prevalent when using this data in the NRCD.

(a). the DCDB road centre lines may not necessarily follow the actual centre line of the physical road.

(b). the existence of ‘paper roads’. These are roads which have been legally defined but have not been physically constructed. Seventeen percent of the road centre lines in the DCDB are paper roads.

The DCDB roads have the road name, type, suffix and other attributes associated with them. The data was consistent, well constructed and easily imported into an Arc/Info environment.

(ii) The urban street maps road centre lines cover 184 towns in New Zealand using two scales 1:15,000 and 1:25,000. These centre lines were derived from a CAD environment and therefore only the arcs could be imported into Arc/Info.

(iii) The topographic data, scale 1:50,000, was used where there was no equivalent coverage by the urban street maps.

Both the urban street maps and topographic datasets were compiled using aerial photographs and field checking techniques. These two sources were used in conjunction with the cadastral data to identify and tag the ‘paper roads’, i.e. where the cadastral had no equivalent road in either the street maps or topographic database it was tagged as paper.

It was not a simple process to amalgamate the datasets. Not all data was in digital form. In some areas scanned sheets were used as backgrounds for digitising. Some data was imported from CAD systems and other GIS often resulting in the loss of associated attributes as a result of the translation process.

Both Arc/Info and ArcView were used in the construction of the database. Arctools was used for the basic checking and editing work. The work was automated as much as possible using AML's to transfer attribute data between centre lines, populate fields automatically, perform quality assurance checks, and at the later stages, to construct dynamic segmentation routes and perform maintenance tasks. Arcview was customised using Avenue to enable the automatic tagging of paper roads, to create plots and to classify the data for easier viewing when performing checks.

Data Structure

Three primary requirements were; to keep the database as generic as possible, to be system independent and to allow multiple attribution of the centre lines without excessive splitting of the arcs. To achieve these, the database was split into two components. An underlying spatial centre line with core attributes and a range of road attributes associated with the centre lines using dynamic segmentation.

Road Definition

The first major issues to resolve were to define "what is a road?" and to evolve stable rules for representing roads in the database in terms of the definition. The Oxford dictionary defines a road as: "Line of communication between places for the use of pedestrians, riders and vehicles" [Oxford dictionary 1982] which is indicative of its function. However, defining a road in database terms proved a more difficult task. Approaches considered were:

(i) Based on name. However not all roads have a name.

(ii) By its legal status, i.e. officially recognised. But this excludes, for example, farm tracks, which are commonly used but not necessarily legal.

(iii) Based on public access. But this excludes forestry and private roads which could be vital in the case of the emergency services.

In the end we used a combination of the above to help us determine the road entity which in the database is referred to as a road segment, i.e. in Arc/Info terms an arc with nodes at either end. We recognised that a solid data model was needed to ensure the fundamental stability of the basic data. Therefore to ensure as few nodes as possible existed between road segments, the following rules for placing nodes were applied:

• at road intersections (junction of 3 or more roads)
• change in road name
• at the hanging end of an arc
• traffic lights
• change in the source between road segments, i.e. based on data lineage of road segment (e.g. agency, mode of capture) to provide audit trail
• change between road segment type, i.e. NRCD feat_code (e.g. standard pysical road and road under construction)

To enable us to carry out maintenance and resupply updates of the road database, each road segment and node were given a 12 digit static unique feature identifier (SUFI) and date information.

Road Representation

To ensure the road centre line could be used for Automatic Vehicle Location (AVL), routing applications and cartographic purposes, we attempted to retain as much detail as possible while providing simple connectivity. Complex intersections, slip roads, roundabouts and dual carriageways can be stored in detailed or simplified form. This means the building process could be accelerated as information could be captured in a simplified form while still providing the facility to add detail as required. Below are two diagrams showing how slip roads and roundabouts were simplified.

Artificial segments were used where feature reduction occurs, e.g. roundabouts with slip roads can be reduced to a single node point.

This representation allows us to provide more detailed roads when providing data at a larger scale, but also allows us to only provide the connectivity for the data at a smaller scale.

Road Elevations

The basic design of the database is based on having nodes at every junction (including bridges and tunnels). Therefore to handle road underpass / overpass situations multiple nodes are used. Arcs either side of the underpass / overpass node have to be elevated in relation to each other. This is done by populating the extra attributes f_elev and t_elev in the AAT. The renode command then renumbers the internal# of all nodes creating multiple nodes at road underpass / overpass intersections.

Diagram showing the underpass / overpass situation. 1 represents the overpass, 0 represents the underpass. The node attribute type is populated with a value of 3 meaning underpass / overpass.

Dynamic Segmentation

The key reasons for using dynamic segmentation in the NRCD are:

• As the NRCD will be used by a number of clients with different requirements, linear referencing will allow multiple attribution of the road segments without manipulating the underlying data
• It separates the spatial maintenance from attribute maintenance
• The dynamic segmentation tables can be extracted from A/I’s internal table structure, the road segment SUFI’s can be related to all route tables so these attributes can be supplied to other GIS, or non GIS.

To date, dynamic segmentation routes have been constructed for road names, state highway designations and motorways. Bridge positions, which were provided as distances from reference markers on state highways, have been geocoded using events in Arc/Info.

Attribute Definition

^* Fundamental attributes of arc segments. Feat_code defines the road segments, the remaining are the maintenance attributes of the segment.

^# Attributes that are currently held directly on the arc but which will eventually be in separate tables.

The following is a brief explanation of the key attributes associated with the arcs:

• feat_code represents the type of road, e.g. proposed, paper
• SUFI is the primary key for each arc
• class has been classified into 10 major groups (e.g. state highways, major, minor, driveways, foot tracks etc)
• town_name, tla and areaunit are all locality indicators
• one_way indicates one way roads which have been tagged with a 1 and orientated by the direction of the arc
• f_elev and t_elev are used to indicate overpass and underpass situations.

NRCD Road Node Table – ( .NAT)

The following is a brief explanation of the key attributes associated with the nodes:

• type represents the type of feature associated with the node e.g. roundabout, overpass

Quality Assurance

QA was performed on the spatial and attribute data using a combination of automated procedures and visual checking. The following are a few examples:

• all State Highways have complete connectivity for the whole country
• all road segments have unique and valid SUFIs
• all road segment feature codes have classes (e.g. roundabouts, slip roads etc )
• 95% road names and classes are correct.
• all arcs have been generalised using the Douglas Peuker Algorithm to 0.5m
• no arcs cross without a node
• there are no overshoots or undershoots
• all nodes are valid (including pseudo nodes)
• all road types, suffixes and town names have been checked consistent spelling

Positional Accuracy

The positional accuracy of the data varies depending on source. Metadata about accuracy is intrinsically linked to the source of the road segments. Urban areas are accurate to +/- 5m and +/- 20m in rural areas. The following diagram shows confirmation of accuracy in an urban area differentially rectified ortho photo.

Diagram illustrating accuracy of the NRCD against an ortho photo in an urban area.

Maintenance

To ensure the NRCD is always up to date it is maintained from a variety of sources, e.g.

(i) LINZ DCDB

(ii) Information from Local Authorities such as details on new and proposed roads, street numbering, new one way street and traffic lights

(iii) site verification

(iv) GPS data

(v) satellite imagery

(vi) orthophotos

As SUFI’s and date stamps are associated with each road segment, it is possible to identify where modifications have occurred to the database. This facilitates the provision of updated information to users who already have been supplied with a full version of NRCD. Clients are then notified and provided with only those features that have been deleted, inserted or modified. To ensure that each arc and node has a unique id and that topological and attribute checks are enforced, a series of routines are applied after each maintenance session.

Any spatial changes that are made are recorded in the modified_date field, whereas attribute changes are recorded in the att_modified_date field. Obviously changes in individual attributes cannot be monitored using this method but in the future when more user attributes are defined using dynamic segmentation then we can keep track of the changes in the attributes through those tables.

Diagram illustrating the initial and maintenance data sources in the NRCD.

Applications of the NRCD

The NRCD has already been successfully implemented by Terralink’s cartographic department and New Zealand's Automobile Association for AVL applications. The national coverage and portability of data between Arc/Info and CAD systems has also been a great advantage. Anticipated applications include: route analysis - determining optimum path; vehicle dispatch and navigation - emergency services; fleet location monitoring; and asset management.

Pitfalls to be avoided

Building the National Road Centre Line Database has not been a trivial task. From our experience the following are important issues which should be considered before embarking on a similair exercise:

• Research the market thoroughly to determine what the core attributes should be.
• Design the full data model before starting (including what attributes are going to be dynamically segmented), including spatial and attribute modified placeholders for maintenance regimes.
• Test the data model fully on a small area which includes a variety of features e.g. roundabouts, underpasses / overpasses.
• Have a maintenance program developed before starting, including knowing the frequency of updates, catering for incremental update and bearing in mind that once the primary key id is applied to each road segment it cannot change.
• Ensure there is a method of keeping track of spatial and attribute updates as well as deliveries.
• Translate the test area data between different GIS. This could affect the data model depending on how other GIS interpret arcs and nodes.

In terms of the building the NRCD we have certainly come down a long, winding road and we are looking forward to that straight, wide, open road ahead!

______________________________________________________________________________

Author Information: