GIS for Municipal Infrastructure Management; A Case Study

The TreeViewer is a Visual Basic / MapObjects GIS browser which was developed for the City of Richmond, British Columbia. The purpose of the TreeViewer is to aid city staff in managing civic infrastructure. This paper discusses the process behind developing the application, and will follow the development cycle from the initial selection of technologies to the current daily use of the tool by Richmond staff. The project was completed in four stages which included (a) application development, (b) an update of private utilities data, (c) a GPS point collection of infrastructure assets as well as (d) the creation of hardcopy maps. Each stage in this project will be addressed below.

The City of Richmond can be found in south western British Columbia, Canada. It is located on the delta of the Fraser River just south of Vancouver.

Figure 1. Location of the City of Richmond (www.city.richmond.bc.ca)

Approximately six years ago the City of Richmond decided that it needed a simple tool to view municipal infrastructure. At that time, the city had a digital version of its assets contained in a CAD program. Consequently, accessing the data was slow and time-consuming. Hardcopy maps of the data were produced for use by field crews, but these often proved to be out of date and cumbersome to carry.

The decision was made to build a GIS browser which would be accessible to city workers on their networked PCs. There were a number of software packages which were considered to provide this functionality. At this time, PC Arc/Info was limited and expensive, ArcView was in its infancy and MapObjects was but a mere glimmer in Jack Dangermond’s eye. The best and most appropriate technology at the time was MapInfo and thus this technology was chosen to develop the first version of the TreeViewer. The MapInfo based browser served its purpose for a period of time but soon it’s short-comings became evident.

Four years after the original MapInfo application was developed, it was time to revisit the project. With the rapid growth and development of the city, the data sets originally provided by the utility companies were frequently found to be antiquated. It was time to get the latest datasets from the utility companies which served customers in Richmond. The city also wanted to include its own infrastructure data in the application. A majority of this data was already digitally maintained by the municipality in CAD format. Managing this data was not easy, and much of it was seriously out of date. The city faced two choices: either to convert the CAD data to GIS format and live with its inconsistencies and inaccuracies, or; spend a significant amount of money to collect and store the data precisely and accurately in GIS format using GPS technology. It was decided that the most efficient choice would be to gather all city infrastructure with GPS.

While the datasets for the TreeViewer were being reevaluated it was an opportune time to reevaluate the application itself. Half a decade after the initial development the City had become increasingly invested in Esri technologies. Esri products had themselves come a long way to address the weaknesses they had presented in the PC market in comparison to their competitors. MapInfo was no longer the only solution for developing a GIS browser on the Windows desktop. Richmond could now compare MapInfo to such Esri products as ArcView and MapObjects.

The cost-per-seat of the original application proved to be a critical factor in deciding to switch to MapObjects technology. Expanding the data sets accessed by the TreeViewer meant that the product would become of increasing usefulness to a broader group of potential users at the city. When the city decided that they wanted to put the application in front of a greater number of employees, in a wider range of departments, it became clear that MapInfo would become prohibitively expensive.

The data sets used by the TreeViewer will be periodically updated to ensure that they remain accurate and reliable. With each of these successive data updates, the application and its technology will also likely be reevaluated. Such a reevaluation took place during the first data update. MapObjects was clearly less expensive on a per-seat basis than MapInfo, allowed for greater customizability, was simpler to work with and thus it was selected as the technology to build the new version of the TreeViewer application.

Once the decision was made to select MapObjects technology, a companion technology had to be selected. Since MapObjects can be plugged into many standard Windows development environments, including Visual Basic, Visual C++, Delphi, and PowerBuilder, one of these had to be selected. Visual Basic was selected because it was the easiest to work with. As MapObjects was yet in its infancy it was a new technology for everyone involved with the project. MapObjects users worked primarily with Visual Basic and thus all of the textbooks and help files gave examples of VB code. Since so much knowledge and experience was already invested in operating MapObjects with VB, Richmond decided to commit to Visual Basic.

Building the Application

MapObjects and Visual Basic proved to be an appropriate choice. With these technologies Richmond faced the challenge of reproducing an existing application. There were some challenges in reproducing all of the features available to the user in the first version of the Treeviewer; however, we were able to recreate the original as well as add some exciting new features.

Figure 2. Screen Capture of the Treeviewer’s main screen

There were two main stumbling blocks in recreating the MapInfo application. The first was with duplicating the Graphic Text capability of the MapInfo version. Drawing text on the screen was easy enough but we could not easily make it as dynamic as MapInfo’s Graphic Text. The second challenge was having Visual Basic print out a rough equivalent of a layout. Users familiar with MapInfo or ArcView know how easy it is to create a layout for a map. Without simply performing a screen dump, printing a layout with MapObjects and Visual Basic can be a real challenge.

Figure 3. Screen Capture of the Query Tool

All other functionalities of the MapInfo product were duplicated successfully. A couple of the original features of the application were improved upon, particularly the query tool and the information tool. The original application had limited query functionality and could only query based on street address. Using Visual Basic, a powerful and dynamic query tool was built so that the user could query any visible piece of information.

With the information tool, a useful component of Visual Basic was utilized, the treeview. When a user clicks on the map using the Info Tool, the screen shown below appears. The treeview in this screen is filled with one entry for every item that was within at least fifty meters of the user’s selection.

Figure 4. Screen Capture of the Info Tool

As mentioned earlier, the original MapInfo application was built approximately six years earlier and contained only private utility data. The data gathered at the time included cable, telephone, gas, electric and jet fuel. During the four year period between updates, the amount of infrastructure in the City of Richmond grew significantly. Due to this rapid growth, the city committed itself to maintaining and updating the private utility data on a regular basis.

In late 1998, it was time to revisit the private utility data. Each major utility company was approached separately. Naturally, each utility company had an interest in maintaining the privacy and the ownership of their data. In every case, a meeting was held between the City of Richmond, the application developer and the utility company during which it was explained how and why the City required their data. The utility companies agreed to provide the data in return for "future considerations" or an exchange of data.

The City of Richmond maintains two sets of data for their own infrastructure assets. In the past, these were stored and maintained in a CAD program. Due to the complexities of maintaining and accessing CAD data, a series of map books were produced. These books became the defacto interface through which employees accessed data regarding city infrastructure on a daily basis. Unfortunately, the map books proved to be an extremely inefficient method of viewing city infrastructure. Another problem was that the CAD data had become out of sync with the hand drawn updates performed in the map books. This situation was not acceptable.

The TreeViewer gave the city the perfect opportunity to get their data right. They chose to collect this data by employing GPS to pinpoint the location of each asset to within a couple of feet of its real-world location. The entire city was divided into three zones, which were then divided between the three contractors retained to perform the work.

Aside from capturing the physical location of each asset, the city also wanted to capture data regarding that asset. The data that was collected depended on the type of asset being captured. This can be seen in the table below:

The contractors were provided with standard templates for each asset type to ensure consistency from one file to another and between data sets. The standardizing of templates for delivered data made the job of amalgamating all of it far more efficient.

The City then had to ensure that this data met with their standards both of accuracy and of format. A series of QA checks were performed on the data until it met the City requirements.

The final stage of the Treeviewer project was to produce map books of the newly collected GPS data. While the Treeviewer application would remain the primary interface by which city employees would locate city infrastructure assets, it was necessary to provide an alternative method to access the data. In cases of emergency or computer problems during which the tree viewer application may not be accessible the hardcopy map books will be available as a backup.

The cartographic quality of these map books became an issue. The users at the city were familiar with map outputs of CAD programs, which lead them to have high expectations for the map book production. A lack of time and funding prevented the development of advanced plotting routines which would have been capable of duplicating maps produced from CAD programs. Consequently, Richmond had to make due with the cartographically limited output capabilities of ArcView for which the city already owned a license.

There are a number of steps which will be taken in the future with the TreeViewer application. The first of these is to continue to roll-out the application to a broader range of departments at the City. To date, the TreeViewer has been operated only on desktop PCs from within the operations yard. As already mentioned, the City has also committed to updating the datasets utilised by the application on a regular basis. Both the private utility infrastructure, as well as the city’s own data, will be collected regularly to ensure the precision and reliability of the system. Also, providing the TreeViewer to field crews via laptop computers has been an objective of the project from the very beginning. Plans are in the works to take this next step at some point in the future.

A potential step for the future which would be of great benefit to the user community, would be to tighten the integration of the application with both the Hansen Infrastructure Management System as well as other GIS applications at the City. Having a single, simple interface for the viewing, look-up and querying of spatial data at the City would bring simplicity and peace of mind to its employees.

The City of Richmond, in cooperation with GDS & Associates Systems Ltd., built a GIS browser application using Esri’s MapObjects and Visual Basic. The browser was built to replace a MapInfo application which performed similar functions. Despite challenges faced during development of the product, in each of the four stages the application has been successfully implemented. The system is currently helping staff to manage the infrastructure assets of the City of Richmond.

The authors of this paper would like to thank all of those that helped make this paper possible. Special thanks goes to the members of the City of Richmond Advance Research and Technologies Team (including Paul Sung, Neyton Lum and Wendy Mah). As well as the staff at GDS & Associates Systems Ltd. (including John Samulski, Cam Trent and Sonja Wieland).