How the City of Rock Hill has Enterprised GIS

This paper summarizes the development of an enterprised GIS solution in Rock Hill. From the conception of a GIS in 1989 with the upcoming decade aerial photography to the every day operations of data management, query and output. A step-by-step time format presents the data collection effort, connection to MIS, data base development and connectivity, application implementation, reproceduring operations, reorganization, data sharing policies, etc. This paper is a time line of GIS in Rock Hill but can be a guide to an organization that is just beginning the GIS experience.


Year 1989

Engineering is completing the RFP for the 1990 orthophoto work. With the recent purchase of AutoCad (ver. 10), the City Engineer has decided to receive the topographic\planimetric data in digital format (DXF).

The Inspections Division is reviewing a new permitting system. This new system requires a physical address along with the associated parcel identification number. The relationship between address and parcel does not exist.

Utility Billing is needing a new billing system. However, the City has three address systems and inaccurate physical address-to-meter relationship.

Introduction

In 1989, the City was planning to undertake some major projects. The topographic/planimetric data was heading the right direction by acquiring it in a digital format instead of on mylar. The other two projects involved the address system, all three of them, along with parcel information.

This paper will provide history on how the City of Rock Hill tackled these projects which eventually lead to using GIS as a solution to the data requirements. In addition, notes and tips will be provided to aid someone who is considering enterprising GIS.

A Preliminary Concept

MIS realized that the three address systems had to be consolidated into one. The address systems were in Utility Billing, Planning, and Police. This new "one" address system had to managed by one group of people and shared throughout the City. In addition, a relationship to the parcel data had to be established. By relational database practices, a key field could be created in each data set to allow for this relationship. This relational concept was sound but the amount of data management was going to be enormous. There had to be another way to relate addresses to parcels.

During a site visit to another county in 1990, the MIS Director and the Senior Planner were discussing the issue of addresses and parcels. The Senior Planner mentioned the use of GIS. The planner’s thoughts were that addresses lie on parcels when referenced by geography. The question was "Could GIS be used to establish this relationship?"

Remember, in 1990, GIS was not what it is today. Most organizations viewed GIS as a one time project based solution not a every day operational solution. With parcels and addresses changing every day, the solution to this type of data had to be continuous. Still today, some organizations still view GIS as a project based mapping software solution. It is not. We did not fully understand this in 1990 but as this paper details, GIS allowed for the management and relationships of geo-based data to be more easily and efficiently performed than in other computer based solution.

Task Force

A small task force was created to discuss and plan a project to develop an uniform address system and parcel base. The members of this task force were division supervisors and staff from MIS, Engineering, Inspections, Utility Billing, and Utilities. These members were selected for one main reason: They were users or administrators of the address system and/or parcel base. Of course, some members had additional interest since their new systems would involve the data that was planned to be created.

The name of the task force became Utility Billing Information Systems (UBIS). This name was chosen to enhance support of the project. The City of Rock Hill is utility based with electric, water, and sewer customers. It was felt that the name of the task force be associated with Utility Billing to ensure management and council financial support. Utility Billing was the largest user of the address system and had more to gain from this project. The task force was unaware that as the project progressed so would the emergence of a GIS focus.

The first major topic of the task force was to discuss the use of GIS in aiding the development of the data bases and their relationships. Several of the members had already been to seminars that focused on the uses of GIS, and these members relayed this information to the task force. Still, no one existed inside of the City that was quote "a GIS expert." However, through internal and external education, the fundamentals of the data base concepts and relationships were learned well enough to be become an integral part in database development. The members of the task force agreed that GIS was the future and all data developed should have GIS as the underlying base.

The task force’s first step was to perform site visits of existing GIS government entities. The site visits became very beneficial in the areas of planning, cost, organization, operation, and benefits of developing a working GIS. This paper will not go into these site visits, but below is a list of the information gathered.

Develop a plan - Most of the sites visited did very little planning. As a result, GIS was still floundering around inside of the organization without direction thus, funding became scarce. The successful sites visited were moving into new areas that needed GIS with funding to back it.

Milestones - Short attainable milestones were an important part of expressing the progress and success of GIS. Developing a working GIS for an organization takes years to complete. These milestones aided in keeping the focus alive.

Funding versus Technology - The initial costs of GIS can be high. In starting a new system, the funding may not be available until some progress can be demonstrated. Several sites that were visited spent enormous amounts of money on equipment and software but did not have the data built. These sites became stagnant in their progress. The steps learned was to use existing technology and software to build as much data as possible, invest in the new technology, convert the existing data, and then develop the applications for display and query. These steps shortened the time between the technology costs and the seeable results (applications).

Pilot - A pilot project is useful in selling the product and developing the long range plan. A pilot allowed management to see the benefits of a GIS before they make a long term financial commitment. By the information learned by the task force during the development of the pilot, changes could be made to the overall plan.

People - This was found to be the most important part of any project. The sites visits taught the task force that the persons involved in the GIS project had to be educated and motivated towards GIS. These persons had to be willingly to work together and respect each other’s position to ensure a successful product. Several sites were in disarray because various departments would work together, the supposed members of the GIS effort were not well informed about the use of GIS, and as in some government organizations, employees were not motivated.

Perform sites visits, go to GIS seminars, talk to the experts, and research the possible ways to plan a GIS. Remember, an effective GIS takes a effective plan. Look at the facts of the information that you gather. Separate the good and bad aspects of what others have experienced. By following this information gathering phase, you will reduce the chances of failing.

A Preliminary Plan

The first task of UBIS was to develop a plan or direction that would create the data needed to support the applications that were needed. The address system was at the top of the list. Addresses affected every member’s area in the task force along with several other areas in the City. MIS proposed the following for the data base design.

use Utility Billing’s address system as the base since it was the most complete

each address in the new system should have a unique identifier

each address record should have all data parsed into separate fields

With the new planimetrics being delivered in 1991, meter readers were to take hard copies of these planimetrics into the field and record the unique identifier on each structure that was serviced. These readers had to also indicate other addresses that were missing from the original data being used. The start of GIS was included into the next step of this data collection effort.

Even though the City did not possess GIS software, data had to be collected with GIS in mind. With the planimetric maps being received by the Engineering Division, the address information was inserted digitally by BLOCKS using the planimetrics as the background. What resulted was data being manage in AutoCad that was georeferenced.

The actual address system resided on an AS400 along with most of the applications that used it. Modifications were planned to the address system to allow for the storing of XY coordinates. Finally, the BLOCKS were to be exported to ASCII text files to be imported into the address system.

The initial plan also included parcels. The County tax parcels were digitally "rubber sheeted" over the planimetrics with BLOCKS inserted inside each parcel polygon to hold the tax map ID. With the addresses and parcels created, the plan would be furthered to include more data since the base for most layers would now exist.

Do not expect that the first plan you develop will be a complete enterprised solution. Plan small for the short term and visualize the long term. In the first plan, consider the data that will be the base for all other data. For the City, these data were physical addresses and parcels. Focus in on the data structures and key fields. You do not want to alter data structures late in the game since this would cause you to lose valuable time. Your first plan will evolve and change over the years. Your plan will become a "living document."

Pilot Project

The task force knew that they had to sale this GIS concept to management. One way to do this was to develop a pilot project to use in presentation. The pilot would show the benefits of GIS, allow for estimated costs, and provide tuning information for the overall project. But where should the pilot project take place? Downtown!

As with most towns and cities, the redevelopment of the downtown area is of upmost importance with the politicians. The leaders want to recapture the old downtown feel by restoring businesses and resident dwellings. The City of Rock Hill Economic Development Corporation was in the process of doing this redevelopment of downtown. The opportunity to show how GIS would aid in this effort was enormous. The downtown area became the pilot area.

Using AutoCad, the following spatial data were created for the downtown area:

parcels, addresses, sewer lines, sewer manholes, street center lines, water lines, valves, water meters, hydrants, electric poles, electric lines, transformers, electric meters, zoning districts, historic districts

Then tabular information, such as tax records and utility account information, was linked to the respected features. This pilot creation was not a true GIS but the information that it provided, both spatially and tabularly, was the selling point.

The pilot project presentation took place in late 1992. The major attendees were the Mayor, City Manager, Finance Director, and Economic Development Coordinator. These four individuals could see the vast amount of information that could be displayed in a matter of seconds. This was highly different from the existing paper sources that were maintained at different scales and displayed very limited information. The time savings of information gathering was the main benefit that sold the project.

From late 1992 to present, a capitol expenditure, for just GIS development, of $80k to $200k has been approved every year. This small but effective pilot project made the difference.

Select one or several pilot projects during the development of GIS that are of interest to the people who write the checks. Allow the management staff and the end user to visualize their data in the way the want or need to see it. Be prepared to discuss the costs versus the benefits. These pilots are the stepping stones to getting GIS established inside of your organization.

Converting to GIS

MIS had been investigating and comparing various GIS software. ArcInfo was the prime candidate mainly due the flexibility of the software. ArcInfo would take time to learn but the development capabilities were infinite. However, the cost to implement the software was not so flexible. In 1993, the professional version of ArcInfo ran on an UNIX workstation. Add the cost of the software and hardware, the cost was in the $75K range.

What was decided in the interim was to use ArcCad. Of course, ArcCad ran on top of AutoCad (v 12) and the cost was small. This option had several other advantages. The conversion of AutoCad data to a coverage structure resided inside of ArcCad and was relatively easy. The persons in charge of creating and maintaining the spatial data were efficient AutoCad technicians. The learning of ArcCad appeared simpler with AutoCad as the base. ArcCad was used to convert and maintain the spatial information through 1993.

During this time, plans were taking place to purchase a workstation and ArcInfo in early 1994. ArcInfo was purchased in the first quarter of 1994. As predicted, the learning curve was not over night. Several Engineering staff were sent to the Esri regional office in Charlotte, NC to receive training in ArcInfo. Once trained, the physical use of ArcInfo in-house still took some months to learn. The management of data in ArcCad remained until late 1994 when most data management operations were converted to ArcInfo.

The one area where data conversion did not take place was in utilities. AutoCad was still being used since management applications could not be written in ArcInfo and the field inventory work was still in progress. With the gaining experience of the users of ArcInfo and inventory complete, the plan was to eventually replace the LISP editing programs with AML editing programs.

Evaluate the funding available versus the GIS experience that your organization can provide. Do not get the cart to far ahead of the horse. GIS hardware and software are expensive pieces of technology. You would prefer to have a short turn around on your investment. If possible, evaluate your current data sources and ask yourself: Can we go any further using what we have and not lose valuable data? Just remember, when this technology is purchased, show the results of this investment quickly.

The Creation of CIS

After the conversion process, the task force realized that a select group of staff were needed to manage the GIS. A lot of areas inside of GIS take extended education and training. One cannot afford to provide these options to every staff member. These select staff would have the responsibility of advancing GIS from technology to applications and educate other staff in the use of GIS as related to their jobs.

In 1995, the three Engineering staff that were already using ArcInfo were selected to become the City Information Systems Division (CIS). These staff were relieved of their engineering duties and reclassified to focus only on GIS related tasks. These tasks included the development of applications, staff training, investigate areas for GIS potential, and special analysis projects.

The title of the UBIS Task Force was changed to CIS Task Force during this same year. The task force scope had now changed to include all areas of the City, the primary focus had move towards the development of a city-wide GIS, and the reference to utility billing was no longer needed with full management and council support of GIS.

As for any type of project or organization, a special group of individuals needs to be gathered to handle certain detailed tasks. A group of GIS staff can concentrate on the practices and development of GIS. Then this group reports back to the larger group with their findings based on sound GIS practices. Not everyone can become a GIS expert. Funding, time, and existing duties will not allow for this type of solution. In an organization there will be three types of GIS users: professional, advanced, and common. Create a GIS staff body that can focus on GIS and provide services to the entire organization.

Data Maintenance

The task force had seen sites where data had been created then became outdated because little forethought had been given to the management of the data. The task force decided that the CIS Division would be the area where geodata maintenance issues should reside. The CIS Division had the knowledge to maintain the data and/or develop applications to perform this task.

After the GIS conversion, most data was in coverage format except for utility type data. Maintenance practices were to continue as normal for the utility data. The remaining information (coverages) was the focus for maintenance.

The first step was to evaluate the manual data editing procedures of each data layer. The results of this step revealed many questionable procedures. Manual systems tend to led to unsound data practices. For example, as with the early address system, numerous hands in different departments were involved in editing information. The problem arose that the left hand did not know what the right hand was editing or responsible for. The first action was to limit data editing to one person or closed group of people. This action would allow for accurate and responsible data management.

Some data sources were GIS based but the update information being received was in written form without any georeference. Many processes of data sharing had to be changed. Maps or georeferenced information (i.e., tax map ID or address) had to be provided on all incoming information.

In the early 1990's, not many editing applications existed and the GIS programming knowledge of the CIS Division was limited. ArcTools became the prime editor for all coverages. As experience and knowledge were obtained, special applications were added to ArcTools to aid in the editing.

Reserving time to plan for data maintenance is the most important part of creating a GIS. The result is only as good as the information queried. With the information changing every hour of every day, maintenance practices have to be established to perform these changes on a daily basis. Like we say about a hard-copy map, it is only good for the first second that it is printed because something on that map has already been changed in the system.

Data maintenance will cause the majority of policy and procedure changes inside of an organization. Many manual systems are without georeferences and sometimes illogical. GIS requires the location or boundaries of the updates and the computer requires the update to be logical in nature. The City of Rock Hill had to change policies, procedures, and some ordinances to allow for efficient and accurate data input. Do not expect that every existing process will stay the same, expect to change.

The First Applications

With all the data that had been created over the past several years, usage of this data had been limited to a select number of staff. The first applications had to be able to query and display this information in a useful and timely manner. The way chosen was to eliminate paper source information gathering and AutoCad map production.

Parcel Search

Most functions of City staff involved gathering information about a piece of land or parcel. These data were mainly on different paper maps that were of different scales. Founding information about one parcel could take as much as 30 minutes. The goal was to bring all these data together in a user friendly application where the user could query, display, and print the data in a manner that took less than several minutes. This application became known as Parcel Search.

Parcel Search was the first AML application written by CIS. It took about six months to development and the next two years to refine. Parcel Search resided on a customer terminal in the Planning Department.

Parcel Search allowed a user to locate a parcel by physical address, utility account number, tax map ID, utility customer name, parcel owner name, and picking graphically. The information displayed was parcels, streets, physical addresses, zoning, soils, planimetric, topographic, and historic districts. Tabular information was also displayed which included tax owner information and landfile information (see Landfile below). A map could be printed along with the tabular information.

Map Express

Internal and external customers depended greatly on hardcopy maps. Most of the maps were standard city-type maps: urban area, zoning, etc. And from time to time, maps had to be produced for specialized projects. Even though the long range vision was to eliminate the majority of hard-copies, the short term (10 years) had to allow for map production. After evaluating the time that was consumed by the CIS staff in making maps versus the time needed for data maintenance and GIS development, Map Express was programmed to allow City staff to make their our maps.

Map Express was structured into two levels: templates and design. The templates were predesigned maps of the standard every day products. Simply, pick the map needed and display or print. The design portion allowed for construction of a map using either predefined layer elements or user controlled elements. Any map could be printed on any device in the City or saved to a graphics file for insertion into another document.

Landfile

The Landfile is a physical address point coverage that has been overlayed with every existing data layer that would provide important information about a single address. The Landfile was initially created to provide the link between address and parcel, but evolved to include other data as they were created. The Landfile was created to run every night after the address, parcel and other layers were cleaned and built. When the next day came, the information queried from the Landfile (in Parcel Search) was 24-hours old. Even though the user was aware of the day old information, the user was overwhelmed by the vast amount of data that could be queried and displayed by selecting one address.

The applications are avenues where the user interfaces with GIS. Take time to review what the end user needs versus the data that is available. Marry these two bits of information together into a package that is user friendly and useful. Listen to the user’s comments regarding the applications. Use these comments to make the product more useable for the user. As mentioned earlier, Parcel Search took two and half years to develop for what is being used today. The majority of the alterations were due to the user not the programmer. Treat the user as a business client and watch the support of GIS blossom.

Utility Explosion

In 1996, the City’s Electrical Engineer located a third party work order application for a electric utility. The CIS Task Force took a site visit to review this application. The application was a electrical working maintenance, work order, and outage reporting system. The task force was highly impressed with this application that ran under ArcInfo and ArcView. This application did not address water and sewer, but the potential of water and sewer being migrated into it was possible. This application was a true utility work order system based on GIS.

This application was implemented in 1997 with all AutoCad electrical data being converted. This application was connected to the SCADA system and the inventory and customer records on the AS400. Laptops were purchased to handle field mapping and work order completion.

The process and functions of this system were:

Worker orders

generate a work order in-house using ArcView, which would acquire inventory

the Worker orders would be loaded onto the laptop before the crews went out

the crew foreman would pick up reserved inventory from the warehouse

the crew foreman would make the changes in ArcView while in the field

in the afternoon, the foreman would upload his completed work orders into the system

the whole electrical system was updated during the night

Outage Reporting

outage calls would be received and automatically be located on the system map

as more calls were received and located, the system would trace the possible problem

a crew was dispatched to the potential location

the crew defined the problem and generated a work order in the field

once the problem was resolved, a call to the dispatcher was made

the dispatcher had the telephone options to automatically call the customers back

This exact same system was never implemented for water and sewer but the ArcInfo in-house editing applications were used from this system to edit these two utilities. This took place in early 1998.

The Electrical System became the first truly enterprised solution in the City. GIS controlled every aspect of the work inside of this division.

This system was a third party solution. When looking for outside software solutions, ask yourself the following questions:

Does the solution meet our needs?

What data is needed and what existing data can be converted?

Can it be modified to better meet our needs?

Where can I see it in full operation?

What is the implementation time?

What training is provided and/or needed?

What hardware and software is needed?

What does is cost?

The Electric Division had been looking for a solution for almost seven years. They did not go out and buy the first one they saw. They waited until they could find a solution that provided the correct answers to the above questions.

The New CIS Task Force

With the emergence of the CIS Division and the Utility Department, the CIS Task Force was reduced to three participates in 1998: CIS Manager, City Electrical Engineer, and MIS Director. The CIS Manager is responsible for GIS efforts in every part of the City except for utilities. Of course, the Electrical Engineer was responsible for utilities. The MIS Director still handled the majority of the hardware and communication development. These three members were to represent their respective areas and staff.

Areas in the City were being exposed to GIS by either use or data practices. Most staff knew enough about GIS to start formulating GIS ideas of their own. They may not have the skills to make GIS happen but they knew how to ask the questions. The old task force had grew to a 20 member body due to the required involvement of other areas in the City. Because of number of member, GIS advancement became more difficult with so many minds involved in the decision making process. These are just some of the reasons that the CIS Task Force was reduced to three persons.

With the changing of the task force, the focus had to change. The task force responsibilities were now on data standards, hardware policies, software evaluation, and long range planning. The task force objective had become the advancement of GIS by uniform policy procedures and practices.

We are not indicating that other organizations that develop a team to focus on GIS will change its direction or members. However, we feel that as an organization develops, not everyone can have an individual say or vote on every issue. It will be the remaining members responsibility to represent their staff concerns and ideas. This change has worked well for the City.

Where Are We Now

Approximately 70 percent of all information gathered inside the City is either maintained by GIS or uses GIS in its maintenance process. The information either resides on the AS400, Novell network servers, or IBM RISC servers. The City has 15 licenses of ArcInfo that run on two IBM RISC 6000 workstations or NT. The applications written in ArcInfo are high end editing and utility-type applications (the Landfile, for example). 30 ArcView licenses are used for field mapping, work ordering, and advanced user in-house use. Seven applications or systems are using MapObjects as a link to GIS.

Here are some areas where GIS is being utilized.

Water and sewer along with storm water are now under a complete GIS based work order system

City Police and Fire dispatch have mapping screens that pin point the incoming call location and a plasma screen that monitors the locations of patrolling police vehicles.

Plan Review Tracking uses GIS to record location and special districting information for development projects.

The Zoning Administrator uses GIS to record, process, and research zoning changes.

The Fire Department uses GIS to locate hydrants and to administer required street name location exams.

The MapObjects’ Parcel Search is on every desktop for the users who need to query address and parcel information.

Is the City of Rock Hill "enterprised?" This questioned as been asked to us several times over the past year. The answer is "how much." The City will continue developing GIS solutions in areas that need GIS and the City will discover other areas where GIS can be utilized. The thought process of automation has changed in Rock Hill from looking at MIS based solutions to MIS-GIS based solutions. In some areas we are enterprised and in others we are moving forward to an enterprise solution. When we have enterprised all departments, will we be enterprised or will we be just taking another step forward?

In Summary

This paper was written to provide the reader a summarized history of how the City of Rock Hill developed its GIS. We do not promote that this same path or its parts will be effective in every organization but most pieces will be similar. We just hope the information presented here will be useful to other organizations who are planning an enterprised GIS.


Scott E. Davis, P.E.
CIS Project Manager
CIS Division, City of Rock Hill