Printer Friendly

Regional District of Nanaimo URISA 2006 implementing an "across the board" web-GIS solution.


Abstract: The Regional District of Nanaimo (RDN) is one of the fastest growing regions in British Columbia, Canada with a population of more than 131,000 people and some of Vancouver Island's most livable communities. Located on Vancouver Island, The RDN provides and coordinates a range of services in both urban and rural areas, depending on local needs. The RDN's responsibilities and services include regional and community planning, transit, liquid and solid waste treatment, recreation and parks, building inspection and bylaw enforcement, water and sewer utilities, general administration and emergency planning. Cadastral mapping is also a District function. With the RDN's responsibility for so many different functions, the GIS team was required to develop and manage mapping and property related data as required for each of those functions. Hard copy maps met the legal and practical requirements, but the need for detailed, current information and the need for an efficient means of look-up, stimulated corporate support for development of an interactive web map. ArcIMS was added to our arsenal of ESRI software and the default HTML viewer was used to deploy an in-house web map service. As the volume of data grew, the GIS team divided the increasing number of layers into separate map services, but the system grew more and more difficult to manage. As well, the 'power users' grew to need and expect more functionality which could only be achieved through custom scripting or a third party application. With no programmers on staff the GIS team required a web-GIS solution that would be simple to author and maintain while providing a user-friendly and attractive web-portal. RDN selected Orion Technology's OnPoint(tm) web-GIS solution. Our GIS team was able to import their existing map services and connect OnPoint(tm) to the existing databases throughout their organization to create a fully integrated web-GIS solution. The in-house services were then easily modified for publishing on the web for public use. This presentation will be of interest to anyone looking to integrate data from throughout their organization into one easy to manage web-GIS solution and will highlight new insights and lessons learned.



I will start with a brief description of the Regional District of Nanaimo, the RDN. Where it is and what services it provides and then I will relate the evolution of our mapping function and close with a summary.



The Regional District of Nanaimo (RDN) is one of the fastest growing regions in British Columbia, with a population SLIDE 4 now of more than 131,000 people and containing some of Vancouver Island's most livable communities.

Located on Vancouver Island, SLIDE 5 the RDN is comprised of four member municipalities, The City of Nanaimo, The City of Parksville, The Town of Qualicum Beach and The District of Lantzville and 7 Electoral Areas covering the unincorporated areas.


The RDN provides and coordinates a range of services in both urban and rural areas, depending on local needs. The RDN's responsibilities and services include regional and community planning, transit, liquid and solid waste treatment, recreation and parks, building inspection and bylaw enforcement, water and sewer utilities, general administration and emergency planning. Cadastral mapping is also a District function.

With the RDN being responsible for so many different functions, the GIS team was required to develop and manage mapping and property related data as required for each of those functions. Hard copy maps met the legislative and practical requirements, but the need for detailed, current information and the need for an efficient means of look-up, stimulated corporate support for development of an interactive web map.


My own story parallels that of the RDN mapping and GIS. I began with pen and ink and that was before the days of those cushy automatic pens that you shook to get started until it splotted on your work. I began with ruling pens and calligraphy style hand lettering.

Mapping in the RDN began in the seventies, shortly after incorporation. The original 1inch to 400 feet Cadastral series was built from outdated and inaccurate small scale Provincial mapping. Subdivisions were plotted and best fitted from legal plans. By 1980 the series had been re-scaled to a modern standard 1:5000 but it was still based on an out dated map sheet system. We got pretty sophisticated in the eighties and used pin registered overlays to produce zoning maps and address maps. Other small scale map series were developed by splicing together photo reduced negatives of the 1:5000 series.

The maps were appreciated for their detail and evidence of skill. But the obvious downside was made very evident by the sudden and rapid growth of development in the region at that time.


The base map series was always out of date. The series that were derived by using overlays took weeks to rebuild. Some series were never rebuilt. Meanwhile the main users; Planning and Building Inspection were swamped with enquiries, many of which were on new properties.

New map sets were developed to implement newly introduced broader levels of planning with new regulations and newly imposed constraints. The function of the planner became very complex. They struggled to provide accurate property information. They struggled to provide complete property information. The Planners were not happy.

To add to their misery, any custom mapping had to be planned well in advance to allow enough time for us to draw it out and for the ink to dry. Analysis was limited to measuring areas with a planimeter and adding them up.

The Corporation recognized the problem and realised that wrong information could be given out and lawyers and lawsuits don't come cheap. It was also time to consider re-working the cadastral map series to conform to the current standard Provincial map sheet system and somehow shift from NAD27 to NAD83. It wasn't going to be easy or cheap. It made no sense for it to be handled as a manual drafting exercise so we began to consider a digital solution. Stories abounded of difficulties encountered by other authorities who had gone through a conversion to GIS.


We heard how long and expensive the process could be.

The RDN is a relatively large area with a small population and a limited tax base. This was our challenge, how to convert our cadastral map series into a digital format in short time with limited funds and with minimal staff who have no experience no training and no computers.


Our introduction into digital mapping and GIS began in 1996 with the Regional Growth Management Plan, a high level long term planning project that required the assembly of information from many sources and analysis that could only be achieved using GIS. With Provincial funding for the Plan and some creative budgeting we acquired 2 computers, a plotter and software. Consultants completed the work but RDN mapping staff (me) were expected to maintain and revise the data. So with trepidation and minimal training we began to tinker in PCArcINFO and ArcView. This wasn't just our introduction to GIS; it was also our introduction to computers. I was learning ArcINFO commands while figuring out what an 'A drive' was.

It proved to be a good introduction for us. We only had one layer to work with. It had a simple structure and no annotation. Spatial accuracy was not critical and there were not many edits to do. But it gave us a feel for the environment of GIS. Over time we became somewhat comfortable with PCArcINFO. Not proficient though. ArcView was easier to grasp and was used for publishing.

Additional funding was provided to convert our Cadastral Maps to digital. I have heard many times that a project such as this needs a champion. In our case it was the Manager of Development Services who was our immediate supervisor. He had the need, the vision, the drive and was very creative with budgets.



How do we capture the data and what do we do about spatial control? We decided against attempting a high degree of spatial accuracy and chose to focus on the accuracy of data and text. The reasons for this were: Speed of conversion, The need to capture the whole district meant using untested data from other sources to add to the existing mapping which covered only the populated areas, The project was driven by the Planning Department whose need for recording and analyzing property data was far greater that having sub-metre accuracy, Lack of control points, We decided to continue to use PCArcINFO and ArcView.

The RDN did not have a Property Database System. Some departments had created ad hoc sets of records in Excel and Access without any standards. A GIS system was seen to be a tool that could eventually replace those files with a comprehensive property record system.

Through consultants the maps were scanned and vectorised, edgematched and pulled and stretched into a product that became our digital cadastral base. An orthophoto layer was used for a 'best fit' control.

Upon final delivery of the data a third person, skilled in ArcINFO editing, was hired to continue with the task of updating and improving the layers. We used PCArcINFO to maintain the cadastral base layers and a custom tool in ArcView to publish the map series.


It wasn't pretty in many places and annotation was downright ugly but the information was fundamentally correct and it was kept current. Many users bemoaned the transition from the old sets and griped about the poor line-work and ugly annotation but they appreciated the effort involved and saw the constant improvements.

Over time we replaced the other map series such as House Numbering and Zoning with new digital versions and manual drafting came to an end.

But, the Planners were still not happy. We had moved into the digital world. We had gone from the ammonia printer to a HP650 plotter but the front counter was still covered in map sets. They still had the struggle of researching and providing complete and accurate property information.

Only the tools of mapping had changed. We had to find a way to make the Planners happy.

We had to make the GIS staff happier too. One of the three GIS workstations was used to maintain our cadastral layers. The other two stations were issued with duplicate layers. All three created locally stored project data. This nightmare of data currency and duplicity was further complicated by the limits of PCArcINFO. It limited the number of features that could be held in a single coverage. Seamless coverage was not possible for the district so we had eleven coverages, one for each jurisdiction and their boundaries kept changing.

To go forward we needed to solve these problems. The value of converting to GIS had been proven and the corporation was now committed to advance. So funding was made available in 1998 to upgrade to ArcINFO and to acquire a new server dedicated for mapping.

So now we had all our data on a single server. We still had to work with duplicate coverages but at least they were now seamless.

The next stage of the vision was to enable staff to view the data on their desktop.


ArcIMS was added to our arsenal of ESRI software in year 2000, our millennium project. Maps were authored using the ArcIMS authoring tool and some HTML scripting and the default HTML viewer was used to deploy an in-house web map service. We kept it simple to begin with and concentrated on providing the layers most needed by the Planners. (I keep mentioning Planners because they are our power users and because mapping and GIS was a function of the Planning Department and they were paying the bills.) More layers were added over time as they were developed. These included, parks, new orthophoto, floodplains, road centerline, service area boundaries (sewer, water, fire protection etc) and so forth. We were able to extract property ownership from our Financial system and add that too. That got people really excited. You see, this webmap was the first tool that enabled staff to access property data on the desktop. This enabled staff to respond to property enquiries from their desk. The Planners were beginning to smile.


As the stack of data built in the web map we found that the users became more frustrated with having to turn on the layers they wanted and turn off the ones they didn't want. Other departments began to use the webmap and didn't want to open it with zoning and Official Community Plan information as default open layers. We divided the increasing number of layers into separate map services according to the needs of principal users. This also solved the problem of symbolizing the many layers given the limited range of options available in the authoring tool. We enhanced the map services as much as possible with our very limited programming and scripting skills. The on-line discussion groups were extremely helpful, as were our local ESRI staff.

But the system had its limitations:

The data source for the services were shapefiles; duplicates of the original coverages and shapefiles. Property ownership tables had to be built by a member of the Finance staff and then joined to the LOT coverage before exporting to shapefile.

Replacing these static files took some finesse. Even with the services stopped, the files often remained 'locked' and could not be over-written so replacement ones had to be renamed and the scripts edited with the new name.



The decision to implement this next level of GIS technology when it became available was not difficult.

We had in-house experience and support. (The RDN been running SQL Server for some time for Finance and other departments' applications.) It meant a single data source for all GIS workstations and the ArcIMS map services (equal currency), It gave GIS access to live tablular views of other databases, It promised fast and efficient response times.

It also meant the implementation of an SDE Geodatabase and data migration. Lesson: It could not have been done without the commitment and support of our IT department.

I cannot stress enough the importance of having a mutually appreciative partnership between GIS and IT.

In our case IT liked us so much that they took us over this year. So now we skip to having our SDE Geodatabase all wonderfully installed and functioning perfectly. Just like in the demos.


The transition to SDE also meant that the ArcIMS services had to be re-built to take advantage of direct access to the feature classes in the geodatabase. The new services were still authored using the ArcIMS authoring tool with some additional HTML scripting. Direct access to the original, maintained data was a huge benefit. The Planners had always been our best supporters and had been using the web map services to assist with telephone enquires all along. Now that the data was always current they got really happy and had a monitor installed on the enquiries counter. Paper maps remained on the counter but soon became out-of-date and were being used less and less.

Now was the opportune time to take a fresh look at the web map system and see how it could be further enhanced.



Power users had by now grown to need and expect more functionality:

They wanted easier search tools with more options

They wanted improved print and export functions

They wanted an attractive look

Users liked the separate map services but became frustrated when switching between them because they would have to repeat the search, We wanted to be able to open the map at selected properties from other applications such as Utility Billing and Building Inspection. The public expected access to a web map, Other agencies expected a web map, Our administration supported a public web map,

It became very apparent that what was needed could only be achieved through custom scripting or a third party application. With no programmers on staff it was decided to seek a web-GIS solution that would be simple to author and maintain while providing a user-friendly and attractive web map.



In 2004 the RDN selected Orion Technology's OnPoint(tm) web-GIS solution. OnPoint is a web based application that we administer and edit through Internet Explorer.

With on-line support we were able to install the software, configure the connection settings and connect to our existing map services to get on-line within a couple of hours. Each service is assigned to a tab. A user can switch between tabs and stay at the same extent. We began with a Property Tab with the basic layers: Lots, Address Points, Roads etc, a Land Use Regulations Tab and a Service Areas Tab.

Over the next few days we learned to define and refine the tools that needed to be available to the user and we built up the required search and query tools.


This is what a common search is like. Site configuration is achieved through a very user-friendly edit interface that even I can understand.


This is how we configured a free form Query for the hard to find properties. Working through the edit panels SLIDE 24 we quickly became familiar with refining the appearance of the map and applying alias names to layers and fields SLIDE 25 and setting the order and grouping of layers and optional fixed extents.

We soon released the map to staff for feedback and testing. As with any change, it got mixed reactions but was generally received favourably.

Some comments were actually helpful and led to enhancements. For example, Planners asked for a search tool for finding specific land use zones. The old HTML map services were kept running for only a few weeks before we stopped them. By then staff had fully accepted the new services.

The system proved to be reliable and stable and continued to be so as more features were added.

One way we enhanced the web map was by building tabular views in SQL and using the OnPoint edit interface to relate them to pertinent layers in the map services.

For example: We wanted to enhance the display of property records by including all the street addresses that occur on each property.


This is what we had to work with:

The 'LOTS_POLY' featureclass table has a unique RDN_ID applied to each property,

Addresses are attributes of a point featureclass called 'HOUSE' and the record for each feature contains a unique HOUSE_ID, the address number and the ROAD_ID number which links to a Roadname look-up table.

'LOT_FOLIO' is a table that has fields for the RDN_ID, the HOUSE_ID and the FOLIO which, incidentally, provides a link to assessment data.

This 'LOT_FOLIO' table contains a record for each property and each housepoint. Where a property has two or more houses then there are two or more records, each with the same RDN_ID but different HOUSE _ID.

We authored a tabular view in SQL that pulled from these records and distilled them down to two fields:

RDN_ID and FULL ADDRESS. The FULL ADDRESS combines the address number and the road name.


Using the OnPoint edit interface we were then easily able to set a relationship between the property layer and the SQL table view and so display each address that occurs on a property.

We followed a similar process to link in the Zoning to the Property display.

Other tabular views were built from the Finance Department's BC Assessment Authority SQL database to add ownership and other details to the Property display.

Links were built to make available pdf pages of Zone descriptions SLIDE 28 and tif images of legal plans. SLIDES 29 30 This slide SLIDE 31 shows the configuration settings to open Legal Plans

A 'Mapit' button was added to the interface of the Building Inspection and Utility Billing applications. This button relays a simple script to the OnPoint map service which opens and zooms to the property that is being viewed on the application.


Recent enhancements include buffering and export tools to enable staff to create notification lists in excel for mail-out.


It wasn't long before we had reached a level of comfort with the web map services and the system that spurred us to take a deep breath and launch a web map service for the public.

This was easily achieved in OnPoint by creating a new instance and copying over the configuration file.


Some layers and fields had to be removed from the public web access and this was simply achieved in the OnPoint Administration edit tool by unchecking the 'Allow Display' box in each case.


IT staff established the settings to make the service available to the web and we were on-line. The key point here is that we did not need to create any additional ArcIMS services for the public site.

SLIDE 35 This shows our current architecture.

Our SQL Database, ArcSDE and ArcIMS run on the same server. The server hosting OnPoint is in the DMZ.

The system is almost maintenance free. If the ArcIMS service is changed by adding or replacing a layer then the OnPoint service must be synchronised to recognize the change and the settings adjusted as desired.

The public site has been a success. Most feedback is complementary. We have no accurate figures on the frequency of hits but we hear from residents, potential residents, professionals in all facets of the property related industry and government agencies so it is well used. We promoted the site through our website, media releases, District newsletters, brochures, and during regular enquiries.

A bonus is a drop in the volume of telephone and personal enquiries.


We have also tested incorporation of a new ArcIMS service authored in ArcMap and added to the internal web map service as a new tab. It replicates a conventional cadastral map with all the linework and lots and complete annotation. The purpose of the test was to check the clarity of display and speed of performance. To date there has been no measurable change in performance of the site and we intend to add the service to the public site.

We expect this to further reduce enquiries and may also reduce the requests for printed maps.



We will continue to improve the accuracy and quality of our data. Orion has announced that they have rewritten OnPoint as a .NET application and will be releasing very soon. They promise that a tool has been written to convert current configuration files to work in the new version so we are hoping for an easy transfer. Orion had a booth at this conference and they were demonstrating this product. Three of the new features that interested me are: The ability to embed the OnPoint Search tool into other .NET applications, Map Tip capability and Combining multiple ArcIMS services into one OnPoint map,

This may give the opportunity to author more of the map services in ArcMap. ArcMap Server produces better looking maps and better placed labels but looses performance with too many layers. I am hoping that I can divide the layers into separate efficient Maps and recombine them in a single OnPoint service. Data currency in web services will also be improved. ArcIMS requires a compression of the SDE Geodatabase to catch edits whereas ArcMap is able to read from the add and delete tables. We will see on this one.

Our Environmental Department has recently had developed a .NET application for asset management. GIS is currently building geodatabase featureclasses that contain the water and wastewater service lines and infrastructure locations. These will be added to the Web Map with the intent to create a bi-directional link to the asset management application.

The RDN is also intending to acquire a Property Database System and one of the requirements will be for bi-directional interaction with our OnPoint Web Map Application. This will be our next major challenge.



What I had hoped to express in this presentation is that we are a comparatively small local government office. Funds are tightly budgeted and it has always been run with minimal staff. I consider our GIS and mapping service to be simple, functional and effective. We achieved this with minimal training but loads of support and enthusiasm.

Our success can be attributed to a few key points:

We had a champion at management level We had corporate support The GIS team was provided the required software and basic training The GIS team was supplied with high end equipment The GIS team understood the functions and responsibilities of the organization The GIS team knew what data was needed and how it would be used Good affiliation between GIS and IT A skilled database administrator was essential for the deployment of SDE and the Geodatabase The GIS team was left to do the job without interference Constructive feedback from the users

Hand drawn cartography required a great deal of practical skill and was regarded as being creative; an art form even. I also regard GIS as an art form. It requires a mind able to analyze a problem and solve it in a sequence of creative, often brilliant, logical steps taken through an ever changing complex, technical environment.

I am humbled by the brilliant people that I have met at this conference and I thank you for listening to my story.

Tom Sohier

GIS Coordinator

Regional District of Nanaimo

Nanaimo, BC Canada V9T 6N2

Phone: 250 390 6538,

COPYRIGHT 2006 Urban and Regional Information Systems Association (URISA)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2006 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Urban and Regional Information Systems Association, geographic information system
Author:Sohier, Tom
Publication:Urban and Regional Information Systems Association Annual Conference Proceedings
Article Type:Report
Geographic Code:1CANA
Date:Jan 1, 2006
Previous Article:Spatially enabling the municipal enterprise.
Next Article:Using GIS for landslide susceptibility analysis and monitoring in urban environments.

Related Articles
NASA Geographic Information Tools To Help Cities.
Minnesota MetroGIS geospatial data collaborative Minneapolis-St. Paul metropolitan area (2002--Enterprise System).
The history of the GISCI certification program.
GIS as an enterprise municipal system.
Mapping the future success of public education.
Institutional and organizational barriers to effective use of GIS by community-based organizations.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters