White Paper Describing the

Roads Atlas of BC

Revision 1.7

October 11, 1999

By: Bob Janowicz

President: GIS Innovations Ltd

Phone 604.261.1017 Fax: 604.261.1097

Email: bobj@gis-innovations.bc.ca

Postal: 310-1200 West 73^rd Avenue

Vancouver, BC, V6P-6G5 CANADA

Table of Contents

Roads Atlas of BC

Table of Contents

Introduction

The Problem How to Build and Maintain a Reliable Atlas

The Solution The Road Atlas of BC Field Program

Geocoding (Address Matching)

Road Atlas Maintenance Program

The Logical Data Overview *

Conclusion

Availability

Appendixes - Data Documentation

Introduction

This paper describes in fair detail, the rational, the usage, the technology and the history of the current Road Atlas of BC program. First, we will look at who are the most critical users of road databases, and why. Then we will briefly examine the existing road databases, hence explore why this project was started at all. This leads into some of the first key decisions taken that defined the whole program. We will describe some key technical aspects of the program, such as positional accuracy, road name and address accuracy. We will describe the supplemental data to the roads file, the Enhanced Base Map (EBM) and the Facilities file. Finally, we will close with some discussion of the support and how users and local-regional government can and should get involved.

Roads Databases are Used to Locate and Navigate

There are two uses for road network databases, to LOCATE a place, and to NAVIGATE your way there.

Roads databases and 9-1-1

The most demanding user of databases to LOCATE by address or by street & cross-street description, and then NAVIGATE there are the modern 9-1-1 Computer Aided Dispatch (CAD) systems. Demanding? We are dealing with costly systems of public safety where time is not only money, but lives.

To begin to understand the database needs for 9-1-1, you need to first understand that there are two flavours of 9-1-1. Standard 9-1-1, in which the telephone company intercepts a call to 9-1-1 and routes it to a call centre. Enhanced 9-1-1, in which the call is routed to an emergency call centre AND the phone company informs the centre of the incoming call’s ANI/ALI. ANI/ALI stands for Automatic (phone) Number Identification and Automatic Location Identifier, aka the service address. This was hot stuff ten years ago; but today it is better known as call display, except 9-1-1 gets the address too. With either the ANI/ALI address, or the address given by the caller, the CAD system attempts to LOCATE this address based upon a database of road names with address ranges. If a match is found, the location is centred on a map, flagged with some kind of arrow, and the system determines the default response unit. All of this in the blink of an eye. If the CAD system cannot match the address, the 9-1-1 CAD Operator tries to work with a potentially hysterical or perhaps incapacitated person at the other end of the phone, works through the secondary matching algorithms like "soundex" of other road names in an attempt to LOCATE the caller. If it all fails the CAD Operator must force in the call and guess the best unit to respond based upon their local knowledge. In a previous era, the CAD Operators were all local to the community and the fallback to local knowledge worked fine most of the time. These days the trend is to concentrate the 9-1-1 centres in part to better use staff, and to take advantage of advanced systems, including CAD. For example: E-COMM in Vancouver; the new RCMP centre in Kelowna covering all of the Similkameen, Okanagan and Shuswap; and the 3 centres BC Ambulance has to cover all of BC. The impact of this trend to fewer dedicated centres is the CAD Operators are covering huge areas, far beyond their local knowledge base. The final result is that the whole 9-1-1 system is becoming dependent upon complete and accurate digital road databases to LOCATE the caller.

Was There a Need for a NEW Roads Databases

Until 1998, virtually many towns in BC had its own 9-1-1 system, and most were small and not of the type that even used a map based address range system. It is just recently that new generation CAD systems are being put into service in BC, including E-Comm, the new RCMP centres, and the replacement system for full provincial coverage for BC Ambulance later this year. The situation was simple; without the demanding 9-1-1 users, no-one assembled a database people could put their faith in.

The StatsCan SNF File

This is not to say that no roads databases existed prior to the Road Atlas of BC project. For many years, Statistics Canada created and sold Street Network Files (SNF). These digital maps were created quickly to support the huge and expensive task called a census, with no particular regard to geographic accuracy. I know of instances in a major metropolitan area where the SNF was out by a factor of 2 blocks in places. For a census, as long as the roads were all relative to each other and cohesive, the data met the needs of a census at a minimum cost. Secondly, the SNF files were only created for the larger centres, leaving the smaller towns and rural BC with no mapping at all. Thirdly, the fault rate acceptable for data to support a census is simply not as critical as what is needed for 9-1-1. Lastly, Statistics Canada has no mandate to update their map between each census, so their data is released every 5 years; about 18 months after a census.

Several Years ago, I was involved as a consultant with the installation of a road database to support a new 9-1-1 CAD system for Edmonton Police. It took both myself and the City three months of work to reposition, resolve and correct the SNF with the City’s address and parcel databases.

That experience left me with one big question. If it took that much effort to clean up one flat, well mapped city, what would it take to do the same for all of BC?

The Transportation Centreline Network (TCN File)

The other existing roads database is the TCN from the BC Ministry of Transportation & Highways. This file, much like the SNF, was created for a macro government purpose, to calculate the transfer payments due to BC from the Federal Government. Again, like the SNF, the roads were created by digitizing civic maps and transcribing the road name and address ranges. Again, while better than the SNF, positioning was not important. Again, the assumption was made that if the planning maps showed a right-of-way, a road must exist. The TCN is noteable for having whole developments that were planned, and never built. Again, in some smaller communities the road names were never captured at all. Again, as a macro project to justify big issues, accuracy was not critical. Lastly, the TCN was created in the early 1990’s, and has not been seriously updated since.

The Problem
How to Build and Maintain a Reliable Atlas

GIS Innovations Ltd. concluded that neither the SNF nor the TCN file were complete, reliable, or spatially accurate enough to meet modern needs. This extends to all the others that are derivatives of either the TCN or the SNF. Simply put, neither are good enough to bet our lives or the lives of our emergency personnel upon.

The lessons from both the TCN and the SNF are that you cannot build a proper roads database using just cadastre because you cannot assume:

• that just because a right-of-way exists, that the road exists. Nothing could be further than the truth. We have seen many times in these databases where a road is "mapped", but no such road exists. In many cases, the road does not exist, and never will because the road allowance goes through a ravine, over a cliff, or imagines a bridge that has never existed.

• that the road name in the planning maps is actually the road name used on the street, or is the one on the street sign;

• that the civic planning maps are always accurate or even up-to-date;

• the road is open because many roads are blocked with gates or with concrete barriers.

Furthermore, the above information is useful to LOCATE a place, but it does not tell you how to NAVIGATE there. The key issues above only deal with addressing, not the rules of the road like speed limits, one way roads, width or height limits and so forth. The conclusion was obvious; we would have to go to the field and validate each and every road to confirm the information required.

The Solution
The Road Atlas of BC Field Program

We believe there is no point to having data in a GIS unless it is reliable data. Fundamental to the Road Atlas is our road program. We mounted a positioning system into two Sport Utility Vehicles (SUV), that we refer to as rovers, and then recorded the position of the rover every second while we drove every road. With virtually no exceptions, if we cannot drive a road, it is not in the Road Atlas. Occasionally, a stretch of a road is temporarily blocked due to construction or other exceptional circumstances, and we will "map" around this. But otherwise, if the rover cannot drive a road it does not exist in our database. Other than the Road Atlas, no other provincial road file has the reliability of the acid test, "can the road be driven?"

• The Road Atlas contains roads as is and where is, because we drove them. In other words, it does not contain phantom roads that have never existed or would otherwise lead you over the cliff or ravine.

Data Capture System

We made a key decision that we would go to every road and confirm not only its existence, but also the road name and the address range. We also decided to expand the scope to include the rules of the road. What was needed was a way to capture not only the trace of the road, but to capture thousands of bits of information, as is, and where is. The field capture system devised by GIS Innovations Ltd. made several strategic decisions instrumental to the Road Atlas program’s success. Elements of our system include:

• We use a very high-grade, single frequency, combined GPS-GLONASS system from Ashtech. The result is that the majority of our GPS observations have an error of less than a meter, resulting in our final road centreline geometry being accurate to within 2-5 meters (1 sigma) and 5-10m (2 sigma).
• We are adding inertial navigation systems (INS) to our mapping trucks. With the addition of INS, we will be able to reconstruct the path of the truck even when it loses GPS lock. This will give the Road Atlas of BC project a unique ability to work in satellite deprived areas, such as narrow, tree lined, one lane roads.
• We devised a one touch keyboard for easy and quick capture by the driver of road information such as speed, number of lanes, surface material, addressing, side road features such as bridge start and bridge end, and so forth. This one touch keyboard is integrated with the positioning system. To date we have captured over 600,000 pieces of information about the roads and addresses of BC.
• We integrate S-VHS video with our data capture. While we hope to create new classes of positional imagery, we are presently using the video for QA purposes. This enables us to review certain decisions by the drivers, without having to go back to that spot a second time. At the moment, the video is an archive of virtually every road in BC. If anyone is interested in this information, they should contact us.

Field Method

Our drivers go on the road armed with the assembled maps and sketches in hand. Essentially, the driver proves each map, driving all existing roads, and being alert for new ones not identified earlier. Generally a road is mapped by going to one end and mapping (the recording of geopositional data) uninterrupted to the other end. At the beginning of a road, and along the way, the driver carefully checks the spelling of the signpost to the spelling on our maps, and traps any errors. Along the way of the road being mapped, the driver enters in all the navigation information as it is observed, such as selected bridge abutments, or addresses of the first and last houses on both the left and right of every block. They also enter their position relative to the centreline. Comments are made on the paper map as necessary. At the end of each road being mapped the road is stroked off with a highlighter. The driver then goes to the next road, and maps it. Generally speaking, the drivers try to map neighbourhoods in two hour traverses, take a break, and go on to the next two hour neighbourhood. The two hour limit is the length of the accompanying video tape, and has the added benefit of giving the driver the opportunity to get out and stretch and otherwise take a short mental break while the previous tape is being rewound.

Drivers are given the ownership of their assigned area. The drivers then quickly learn the character of their area, something that can only be gained by being there. The field mapping is not infallible; drivers are people with good and bad days. Technology is not infallible, files get lost or overwritten, disks get full, and sometimes the GPS satellites are just not in the sky above when you want them. The road signage is not infallible; in some places the signs disagree with the registered plans, and sometimes contradict each other for the same road. Addressing is not always consistent with the plan. Yet through all this, the field program, when combined with office QA and integration with other data where available, provides the best results possible. Anyone who thinks this RNS can be done without doing exhaustive field work simply wrong.

Geopositional Accuracy

There is no point to having data in a GIS unless it has sufficient positional accuracy to be both fit for purpose, and can integrate with your other spatial data. In Canada in general, and BC in particular, the industry is still grappling with core issues related to geopositioning. BC covers 4 UTM zones, 8-11. While the provincial bases have been converted to NAD83 (North American Datum 1993), many regional or municipal bases are still NAD27.

• The Road Atlas is managed NAD83, but can be re-projected as required using FME.

• The Projection can be anything, such as UTM, BC Albers, or unprojected Lat-Long

GPS Positioning

Our primary positioning is by Differential Global Positioning System (DGPS). GPS is fast becoming both a highly useful, and often misused piece of technology.

In order to use GPS effectively, you need to understand a few simple basics. The whole system depends upon your GPS antennae having a clear line of sight to at least 4 orbiting satellites to triangulate a position. That may sound simple, if you are in an airplane or on a boat. In the real world of BC, we have mountains and tree lined roads, both of which interfere with your GPS antennae’s ability to see enough satellites. Secondly, the main system of GPS is a commercial application of a system created by the US Air Force to support military operations. In the name of National Security, the USAF fudges the signals from their satellites resulting in a wandering error of up to 100 m; a feature only the USAF would call selective availability. President Clinton has directed the USAF to discontinue this practice, in the next 10 years or so. Thirdly, the radio transmissions from the orbiting satellites travel through the various layers of the atmosphere at differing angles of incidence, resulting in differing refraction factors, causing distortions in what would otherwise be a straight radio path. These atmospheric refraction factors can add up to 10 m of spatial error. While this may not matter much to locating a tank on a battlefield, an enemy headquarters building, or a blue water sailboat, they heavily impact the usage of GPS to accurately survey something like a road in BC.

To solve the first problem, seeing enough satellites, the Road Atlas program selected the GG-24 GPS technology from Ashtech. What is unique about this receiver is that it is tuned to receive both GPS and GLONASS. GLONASS is the Russian equivalent of the GPS system, and in true cold war mentality, essentially copied the USAF system. The resulting combined system has nearly doubled the number of positioning satellites from which to locate the minimum 4 required. The impact on the project of this selection is that we are able to obtain positions when no other GPS technology would be able to. Secondly, the Ashtech system is a premium system resulting in positioning, second to none. Thirdly, the Ashtech system is one of two systems highly regarded by the elite and academics of kinematic (moving) GPS. As an aside, the other system is from Novatel in Calgary, who are anticipated to also release their combined GPS-GLONASS system later this year.

To solve the second problem, the selective availability of GPS, a user requires a second GPS to be stationary at a known point, referred to as a base. A person then uses special software to process the base station data with the rover data, to determine the Differentially corrected GPS (DGPS) position. The positional accuracy achieved by this varies from a few centimeters to a few metres, depending upon the quality of GPS system used, whether the system is tuned to a single or dual frequency broadcast of the satellites, and how well spaced the satellites are (the wider apart in the sky the better). Dual Frequency systems are very expensive (~$30,000), and must be used within about 12 km of a base. While this is great for static survey near a base, it is wholly impractical for mapping Highway 99 from Vancouver to Whistler. Premium Single Frequency receivers (L1 code and carrier phase), such as the GG-24, can yield sub meter (30-70 cm) results reliably within 50 km, and sub 2m within 200 km of a base.

To solve the third problem, atmospheric differences distorting the radio paths of the satellites, a project must keep its rover units near to the DGPS base. The Road Atlas project uses many sites as bases in our areas of mapping. Generally speaking, we want to remain within 200 km between our base and our rovers. To achieve this, we have established temporary bases in Penticton, Kelowna, Vernon, Salmon Arm, Kamloops, Williams Lake, Prince George, as well as a permanent base in south Vancouver. As the project continues throughout BC, additional bases will be added. Typically, our bases are located on the either the main roof or the roof of the elevator shaft of the tallest hotel in town. Besides having the attraction of typically being nice places to stay, these sites tend to provide the highest security possible for the equipment. This also gets our base antennae above all the trees and other buildings in town which reduces the satellite loss due to obstructions, as well as reduces a phenomenon known as multipathing. Multipathing occurs when the radio signal from a satellite reflects towards the base antennae from a flat surface resulting in false or ambiguous positioning. Taken as a whole, our proximity to our own well positioned base station for our DGPS processing reduces our spatial error.

TRIM Integration

All of this positioning technology is not used in a vacuum. All the roads within the Road Atlas are cross checked against all the roads within the TRIM roads database. TRIM is the 1:20,000 Terrain and Resource Inventory Mapping database created and maintained by the Ministry of Environment. TRIM roads were captured using standard stereo pair photogrammetry. The standards for TRIM are that all features are to be within 10 m, 95% of the time. By reviewing our GPS positioning results with the roads within TRIM, we have an independent confirmation of the positioning to a 10m standard, and further confirmation for the Road Atlas, that we have not missed any valid roads.

Occasionally, our GPS is unable to see enough satellites to determine a position continuously. There are times when the combination of the current satellite configuration, the terrain, and the tree cover simply obscure too many satellites. In these circumstances, under our agreements with the Province, some positioning information from TRIM roads is used to define the position of the roads within the Road Atlas. To date, this has been used to refine about 2% of the roads within the Road Atlas.

If TRIM roads are so "reliable", why not just use them? While TRIM is highly useful for filling in gaps in difficult places, the TRIM roads are interpreted from air photos. This means, the roads are only as recent as the last photo series. Secondly, differentiating between real and temporary roads, such as this year’s usage of a track across a farmers field is not completely reliable from photos only. Thirdly, photos do not indicate if a road is passable for the general public, or is blocked off. Fourthly, TRIM roads were captured in a "stream digitizing" mode, resulting in lots of minor wiggle in the road work which we do not want in the Road Atlas. Fifth, the TRIM roads were captured to a standard of 10m, and our GPS is mostly +/- 1m. Lastly, TRIM roads do not nor will they ever include the attribute intelligence, like the road name, addressing or navigation attributes.

Fraser Valley Ortho-Photo Integration

The Road Atlas was also cross checked against the imagery within the Triathalon Ortho-Photo series of the Fraser Valley of 1995. Again this helps us validate the completeness and positioning of our roads with another independent database, the images. In several instances, our work slightly differs from what is seen in the images. A user must understand that ortho-rectification is the processing of image pixels against a Digital Elevation Model (DEM). In other words, an ortho photo regenerates a synthetic image by applying "corrections" to each pixel relative to the angles and conical optics of the original image and some ground modeling. While highly refined, this is not a flawless process. Nor does a 1m pixel convey that that pixel is geo-positionally placed within 1 m on the earth. Our favorite example of this is that the ortho process "corrects" the decks on bridges such as the Alex Fraser Bridge, as if that road work was on the ground/water surface; when in fact the true position is much higher, resulting in a distortion of about 10m. The full impact of these effects is of limited consequence to most users of either the images or the Road Atlas. The largest impact is that some roads and interchanges were rebuilt (eg Nordel in Delta) and other roads have been added since the images were captured, and users should not jump to conclusions when differences are noticed.

Inertial Navigation

Even with a combined GPS & GLONASS system, we feel we are losing visibility to enough satellites more than we would prefer. To reduce our loss of satellite lock issues, we are in the process of adding an Inertial Navigation System (INS) to our mapping trucks. Exactly what we are doing is confidential, but it includes the addition of some or all of: single wheel counters, dual wheel counters, digital compasses, digital clineometers, single axis accelerometers, tri-axial accelerometers, single axis Fiber Optic Gyros (FOG), tri-axial FOGs, and so forth. Is this stuff cheap? NO, but it is part of the cost of getting the job done right.

By processing the relative movements of the vehicle during intervals where not enough satellites are visible, we are able to define the absolute path between the known GPS positions before and after the satellite obstructions.

Geocoding (Address Matching)

Civic Address List & Cadastre Integration

The Road Atlas is also cross checked against any Address List and/or Cadastre, when such data has been provided. The state of Cadastre in BC is, in a word, fascinating. Some places have up to date and accurate GIS systems, while others are out of date and paper based; and everything in between. In a word, if someone could talk every jurisdiction out of a copy of their Cadastre, you still could not create an accurate and reliable Road Atlas. On the other hand, what would be provided would be another valuable cross check. When we get a cadastre, we carefully compare our field notes with the information in the cadastre. The goal is to spot differences. The vast majority of the time, our field work agrees with the cadastre, and all is well. Occasionally there are differences. We focus extra attention to determine why. Did our driver enter a typo? Is the road name posted on the cadastre misplaced? Does the name on the cadastre not agree with the road sign? Is this house out of sequence, or on the wrong side of the street? What do the other databases, such as the phone directories, and the other address registries and maps say? Sometimes the error is ours, and we quietly fix it. On the other hand:

• If the fault is in the cadastre, or an incorrectly labeled sign, or an apparent error in addressing, we document the concern and notify the appropriate authority.
• We are pleased to see that as a result of our feedback, the communities involved have already begun to correct their street signs, and/or formally notify residents of new addresses or road names changes.

We sincerely appreciate the good will and trust each authority places in our project when they provide their data. Our goal is to reduce the faults present in our data so that everyone, including the 9-1-1 services, has the best data to work with. It would be counter to our goals and sensibilities to discover an incorrectly posted street sign, and not tell the right people so that the sign can be fixed before the ambulance wastes time looking road that they cannot find because the sign is wrong.

• To date, most regional districts and local governments have provided us data to assist us in the project. Between their assistance to us, and our feedback to them, the Road Atlas of BC is truly becoming part of a wider solution of building reliable GIS databases in BC.

BC Government Address List

Through the agreement between GIS Innovations and the government of BC, the Road Atlas project has access to a maintained, province-wide address list (without names) for the purpose of quality assurance. In particular, GIS Innovations Ltd is cross-checking roughly one million addresses with the road name and address range data, to ensure consistency and completeness.

How Good Is The Address Matching

The simple answer is that we are much better than any other database out there. The RCMP tested our data before they installed the Road Atlas into the Kelowna Communications Centre. The fault rate of addressing fields from ANI/ALI was about 15%. The fault rate in the Road Atlas was less than 1%, on a sampling of about 9000 addresses throughout the Okanagan-Shuswap. We have done additional comparisons to data provided in the GVRD, and again we have less than a 1% fault rate. In fact, after correcting one minor spelling mistake in our Vancouver data, we were less than 1/1000 when compared to the parcel based Address List from the City; and these have since been fixed. As an aside, we found about the same number of faults in the civic address list and are forwarding this back to the City.

Address matching is not just about getting this project done well once. The truth in BC is addressing is under constant review somewhere. The Road Atlas project is discussing how we can help at least two regional districts inventory or assign addressing to some of their constituents. We also recognize that occasionally a part of BC gets readdressed. Canada Post has a slow but steady program to covert everyone from rural route with site & compartment addressing to civic house number-street name addressing. Road Names are frequently changed, both within towns and within the rural fabric. Some roads get a name assigned for the first time, others renamed as roads are joined. Lastly, occasionally some towns "rationalize" new names for all their roads.

How will we hear about all of these changes, plus the standard new development? We are working on that. Considering that if for any reason the Road Atlas does not get notification of such changes, then the 9-1-1 communication centres do not have new changes. We are confident that each and every town and region will see that it is in their best interest to work with the Road Atlas project; and that each and every town will get some benefit by the detailed road name and addressing review performed by the project.

• Not only is the objective to get it all right the first time, half the objective is to keep it right.
• Every road name is compared to the name in TCN, but compared does not mean the same as.
• Every road that has a real name, is attributed with that name, with an anticipated fault rate of wrong or missing names at much less than 1 per 1,000. We recognize that even if the house number (or range) is not assigned, wrong or garbled, the correct locality and name will get emergency personnel very close, except in major centres where every road is already clearly named anyway.

Road Atlas Maintenance Program

There is no point to having a database, unless it is up-to-date, and reliable. Maintenance is where the Road Atlas of BC really comes through. To maintain roads, that is to add new roads, remove de-commissioned ones, and so forth, we simply send the mapping truck back to the area to drive the new roads. During the maintenance loops is when we can catch up on local changes, get news of new developments to then monitor, and when we will add new classes of information.

Maintenance is a program cost. Simply put, the mapping truck is essentially a full time job. On alternating months, the rover will traverse either the Fraser Valley, or SE Vancouver Island. Two or three time a year the rover will loop through the Okanagan-Shuswap-Cariboo-Prince George sections. Once a year the rover will get to virtually every town in BC, if only to get that one new road. Put another way, the road system covering 2,700K people (70% of the population of BC of 3.9M) is updated every other month, and another 850K people (or 22% of the population) are updated 2-3 times a year.

The Road Atlas maintenance cycle is:

• bi-monthly in the Greater Vancouver, Fraser Valley and Capital Regional Districts;

• 2-3 times a year along the central Vancouver Island, Whistler-Sunshine Coast, the Cariboo Hwy corridor to Prince George, and the Okanagan-Shuswap;

• annually throughout most of the rest of BC;

• Every three years in the most remote places in BC.

Within the GVRD, FV, CRD, all activity will be updated to the best of our knowledge. On the bi-tri annual loops through the Okanagan & Central Interior corridors, virtually all updates we know of will be done. Excepting that not all roads outside of the main routes and organized towns may be readily accessible at all times. If you ask people in Edmonton, they will remark that contrary to poplar belief, there are only two seasons, winter, and construction. This holds true for much of the interior and northern BC as well. Additionally, under our agreement with GDBC, we both recognized that many roads in BC would be debatable as to whether or not they would be in scope, where scope was defined as a permanently habitated, named road. To avoid a contest, we agreed to do about 20 days per year of these secondary or tertiary roads, as part of the maintenance program. Over the next four years, 80 days of work will cover a tremendous amount of the most sparsely occupied and recreation parts of BC.

Is this excessive? Not really. If the data is too out of date, it is of limited use to anyone, including emergency communications centres, major utilities, cities, regional and the provincial government and every one else. With the Road Atlas being current, there is no need for every town, district, or city to maintain their own file. Instead, by working with us, we can keeps the Road Atlas as up to date as the locals could. Working with includes adding us to their list of organizations to be notified whenever there is a change of addressing, or a new "customer" service is requested by the address does not geocode. The full cycle goes like this: we get notices of new stuff, we add them to our list of places to get, we go out and map them, we monitor-keep updating the area active until that development is complete. This means that all users, local government, 9-1-1, and the wheels of private industry all have good, reliable and current data to make decisions with. How do we fund this? Easy. We collect maintenance fees from our users.

The Logical Data Overview

The Road Atlas of BC is best thought of as four key layers:

1. The Roads
2. Key Places and Facilities
3. The Enhanced Base Map
4. An expanding number of inter-related layers

The Roads Layer

• The road geometry (lines) weeded to a 1.5 m standard, at a +/- 2 m positional accuracy, 1s ;

• The LOCATE attributes of regional district left & right, city left & right, street name and alias, and address range;

• The NAVIGATE attributes like speed limits, one way restrictions, turning restrictions, etc.;

• The NETWORK attributes: from & to nodes, angular relations, segment length, the cross-street pairs, etc.

• The METADATA attributes like geometry method, last date modified.

The Key Places and Facilities Layer

is a well attributed layer that is best thought of as:

• The 9-1-1 stations, like police, fire and ambulance stations;

• The key health-emergency facilities: like hospitals;

• The key Transportation links like airports, ferry terminals, helipads, key bridges and tunnels, customs, weighscales, tollbooths etc.;

• The key public structures like schools & colleges, community centres, courts & jails, stadiums & arenas;

• Civic and Regional District outlines (approximate), Public Parks and campgrounds;

• Selected private places, such as key malls, and other key landmarks

• And more classes of facilities as time goes on, like post offices, libraries, ski hills, recreation sites, picnic sites, marinas, rail lines, key landmarks, key industrial sites and so forth.

The Key Places & Facilities included will be attributed with the facility name, address (if appropriate), placeType, internet hot link if known, and so forth. Additionally, once added their existence will be monitored, should that facility be closed, renamed, or moved

The Key Enhanced Base Map Layer

is an extract of the 1:20,000 provincial TRIM map database. These layers have no attribution, and are not verified. These layers include:

• Hydrography: coast line, lakes, river banks, streams;

• Hydrographic Structures: canals, seawalls, dykes, piers, breakwaters;

• Transmission structures: pipelines, transmission lines, transmission towers;

• Rail: lines, LRT, abandonedTrack;

• Industrial Sites.

Within the TRIM base, we are working out ways to weed and thin the hydrography outside of the habitated corridors. Around towns, as much detail as possible will be retained. The Road Atlas users do not need all the stream details possible away from towns. If someone does they should buy the Watershed Atlas from GDBC, which will integrate to the Road Atlas EBM (as it is the source data).

The Inter-related Layers

The Inter-related Layers are a series of planned expansions to the core Road Atlas. These layers will be individually purchasable, and will be created as we can. These layers include:

• Integration to Census data;

• More refined civic naming alternatives, such as the BCTel name;

• Postal Codes;

• Land usage and land zoning;

• Any "administrative" zones (school, forest district, electoral, what ever).

Conclusion

The Road Atlas of BC is a highly effective tool for anyone interested in locating services, clients and prospects. This Atlas is ideal for fusion with other applications, such as selected land usage, census and tourism. We anticipate that this high quality GIS database will meet each users’ needs in a reliable, timely, and very cost effective fashion, and look forward to being responsive to your needs.

Availability

The Road Atlas of BC is supplied "ready to use" in most popular formats through the dealers, noting that most of these are very capable of conversions to other formats as well, but in general:

• ESRI Canada for ARC/INFO or Shape file;

• Tetrad for MapInfo;

• Pacific Alliance for MicroStation Geographics or MGE;

• Kanotech for MapMagic or AutoCad formats;

• Tantalus for on line access;

• Or GIS Innovations Ltd. for any of the above, or specialty formats and needs.

Note that delivery GIS Innovations Ltd is normally by electronic mail, or private FTP accounts from our server.

For More Information Contact:. the dealers and/or GIS Innovations Ltd. by phone at 604.261.1017, by fax at 604.261.1097, by email at bobj@gis-innovations.bc.ca, or by mail to 310-1200 West 73^rd Avenue, Vancouver, BC, V6P-6G5.

Appendixes - Data Documentation

Entity Relations

Feature Name Table

The feat_name table can be supplied. This table contains the feat_name ID column, a concatenated name column, and a series of columns with the name parsed out. A supplemental table is available to fully expand, or change to some other common abbreviations, the various fields of the parsed name.

Remarks:

• The directional values are the typical (N,S,E,W, NW,NE,SW,SE)’
• The type values are the typical (Av ,Rd, St, Hwy and so forth)
  We have added some non-standard ones (FSR).
• The name is the name excepting some normalizations:
  numeric names are converted from alpha, without trailing "rd & th" (eg: First St Þ 1 St)
  punctuation (.’) has been removed (except the dash), "&" becomes "and", and so forth.
• The structure like (Frtg, Onramp, Offramp, Bridge, Tunnel, Viaduct)
  and example usage would be{///Granville/St//Bridge}.

Location Attributes

Remarks:

• The positions from-to and left-right are determined by the segment vector direction.
• By definition (standard) the vector direction is in the direction of increasing addressing, where such a standard can be applied.
• Even/Odd side assumptions should not be made. The fields addressed_left & right describe even and odd. The codes are "E"=even, "O"=odd, "N"=not addressed, "C"=continuous addressing, "e"=even but in reverse direction (high to low), "o"=odd reverse, "c"=continuous reverse.
• Many roads are double even or odd, and often are increasing up one side and decreasing down the other side. For example, Penticton cul de sacs go: 100-148, 198-150. Additionally, many small "side" roads are often numbered as a wrap around of the numbering of the side of the main road that the small road comes off of. For example, a Key Dr may be numbering even like 108,116,124, then go up Key Pl as 132,140 and back down as 148,156; then continuing along as Key Dr with 162,170 and onward. Hence Key Pl is addressed_left and right as "e","E".
• Sub addressing within strata, trailer parks and so forth is attempted. Understanding that the whole "complex" is xxx A St, the single_addr will be xxx, and the FromLeft-ToRight values are sub addressing.

Navigation Attributes

• Lanes left and right are char(1) not integer because most roads in BC have less than one lane guaranteed for travel in either direction. For example, most residential roads do not have a yellow line, and if every car possible was parked in every legal spot, only one lane of travel would have to be shared by both directions of travel, hence our "N" (narrow) code. Additionally, some roads are so narrow, that parking is not allowed (or would even be thought of), and only one vehicle can pass, period. These restricted width roads are coded "R". By obvious conclussion, lanes left and right are both either R,N or they can be any whole integer number of lanes (0,1,2,3,4) for each direction of travel.
• Nav_direction codes include:
  "B" for travel in both directions;
  "1F" & "1R" describing OneWay travel Forward or Reverse, relative to the vector direction (primarily defined by addressing direction);
  "DF" & "DR" for divided road (roads with a barrier or median in the middle);
  "2F’ & "2R" for roads not actually divided, YET, but where, in our judgement, they are good candidates to be divided, or that give you the perception of being divided. For example, Loughheed Highway through Burnaby and Coquitlam is mostly by any of medians, concrete or chain fences, but with a few blocks where there are extra wide shoulders between the flow of traffic, but no concrete barrier, yet.
• Nav_from/to_stop describe the barriers to unhindered travel at each end of each segment. The codes include: "S" stop sign, "Y" yield sign, "L" traffic light (full time or actuated), "R" roundabout, "C" cul de sac, "U" underpassing, "O" overpassing.
• Max width, height, weight are the largest vehicle one can pass through. For example, if there are differing height limits per lane at an underpass, what is the largest vehicle that can pass.
  FootNote, these are being restructure to be "end" attributes, to better define how one could get an oversize vehicle to a spot.
• Nav_from/to_rail are codes describing any rail crossings at either end. Though not complete, this will ultimately indicate codes like: "U" or "O" for under or overpass, "C" controlled, "U" uncontrolled, and more.
• Turn restrictions are further refined in 6 columns, left, straight and right at both the from and to ends. The codes are "SS" for Sunday Saturday, "MF" for Monday-Friday, "MS" for Monday-Saturday.
• Turn restriction times are coded to trap AM rush hour, PM rush hour, both AM and PM, or the implicit, always (if turn restrictions is not null).
• We recognize that some software would prefer FromEdge to ToEdge structures, and these can be generated is someone requests.

Road Classification

We classify each and every road segment to codes based upon what the local traffic authorities say, plus our own observations, and inferences based upon the pattern of lanes, speed limits, and right of way flow (stops and lights). This occasionally puts our codes different than the local authority has, because in some cases a right of way is designated as an arterial, but many not be that way at this time. Our codes are:

• Note we sub-class highway, arterial and collector into major and minor.