Home > GIS/CAMA Integration
9.0. GIS/CAMA Integration and Implementation
Assessment databases and the information they hold are fundamental to the effective operation of many government tasks. A GIS linked with a Computer Assisted Mass Appraisal (CAMA) system provides an effective tool for identifying properties and for analyzing location factors, improvement characteristics and the data that commonly affect property values (IAAO & URISA 1992).
This chapter will discuss the basics of CAMA and GIS systems, and how tax assessment records can be connected with attribute parcel mapping. Relating other types of attribute data will also be incorporated because there are distinct similarities in the processes of connecting various types of attribute data to a GIS. To some degree, the tax assessment relation can serve as a blanket example.
| 9.1. | |
| 9.2. | |
| 9.3. | |
| 9.3.1. | |
| 9.3.2. | |
| 9.3.3. | |
| 9.4. | |
| 9.5. | |
| 9.6. | |
| 9.6.1. | |
| 9.6.2. | |
| 9.6.3. | |
| 9.6.3.1.1. | |
| 9.6.3.1.2. | |
| 9.6.4. | |
| 9.6.4.1. | |
| 9.6.4.2. | |
| 9.7. | |
| 9.8. |
There are no short cuts to successful integration of GIS and CAMA. There is no one blanket prescription that can detail what all Massachusetts communities should do to arrange a GIS/CAMA collaboration. Basically, there are too many site-specific variables; too many issues existing to make things simple. There are, however, commonalities within GIS and within the CAMA systems. These include the use of common databases and data structures, operating systems, scripting languages, and networks. The key is for local officials and assessors to understand their technology and environment (such as available software and hardware, cost, stakeholders, network, predicted applications and integration with the GIS enterprise) and look for other communities who have similar issues and who have had success with their integration.
Seeking out the big picture is a great way to
begin. For members of the GIS enterprise not of the assessor's office, this
task demands comprehension of CAMA and GIS basics. For the assessor, it
involves understanding existing and available software and hardware, and the
typical structure of assessment databases and their relationship to a GIS.
Assessors need "an efficient way to relate tabular data (such as that from
CAMA systems) to maps of the properties that the data represent" (IAAO and
URISA 1992, 8).
Administratively, the ideal situation of a GIS-CAMA link allows assessors to spend less time maintaining records and collecting data and more time to evaluate information and apply skills to real problem solving. Technologically, an effective link enables a seamless integration environment and automatic data changes are reflected on either side of the link.
The State of Massachusetts defines a CAMA as "an automated system for maintaining property data, property, notifying owners, and ensuring tax equity through uniform valuations" (Guidelines 1999). CAMA is comprised of four subsystems: valuation, performance analysis, data management, and administration. When all four subsystems are properly configured, they can perform in a sufficient, user-friendly manner and interchange data freely with each of the other features.
Briefly, the significance of each subsystem is as follows:
· The valuation process involves three approaches of automated applications: income, sales comparison, and cost.
· Performance analysis incorporates the concepts of "level" (ratio of appraised to market values) and "equity" (consistency) into making sure that values can be supported and meet required standards.
· A data management system must provide for the efficient collection, storage, maintenance and security of data.
· The administration function includes functions relating to the organization and execution of the assessment roll and various administrative activities (Guidelines 1999).
Typically, a CAMA has a structure of a relational database, one that allows descriptive information to be entered in the same database as geographic information (Hensley 1993, 23). Because extremely large data files can be cumbersome to maintain and slow to access, it is often beneficial to keep data divided into various files. In a relational database, information is typically stored and maintained in several digital files. One file may contain information about property owners such as name and mailing address. Still another might hold parcel classification information such as land use. A third may have parcel characteristic information such as number of rooms. A fourth might contain land values. "The key to a relational database is that each data file contains at least one element that serves as a link to one or more of the other files." This "linking" function is often referred to as a "relate". (Hensley 1993, 23)
A GIS, on the other hand, is "an information management tool that combines graphical features with tabular data." (Rehmann 1999, 2) Each of the graphical features has corresponding attribute data organized into a field and record structure. This table structure is commonly referred to as a "feature attribute table" (FAT). Common FATs include the polygon, arc, and point attributes that define the individual geographic elements of a coverage. The FATs facilitate common GIS applications. For example, a user can graphically select an element or geographic feature in order to call up its corresponding FAT, or data record. FATs in and of themselves are limited in the amount of data they can provide. Thus it becomes necessary to link other attribute information to FATs. Tax assessment data is one such type of attribute information that can be linked.
In order to create a
link between CAMA and GIS, it is necessary to establish a relate. Linking or
joining CAMA databases to the GIS merely requires the identification of a
unique attribute identifier that is common to both databases (See Figure 9.1).
While the intent of each GIS application is case-specific, the method of
incorporating the data is essentially the same. The goal of the process is to
produce a "relationship" between the parcel features and the line
items in the tax assessment data. (Rehmann 1999, 3) This unique identifier
field is useful not only to match two databases, but also to evaluate the success
of the matching process. It is important to realize that in most relational
databases several files can be related to the selected file, but only one file
can serve as the selected file. Additionally, linking other types of attribute
data requires the same "relate" procedure.
Figure 9.1: Unique parcel number linkage to graphics
Assessment databases can contain upwards of 100 data elements. Examples of these elements include the tax I.D. number, the year of assessment and the street address. The tax I.D. number is a unique number assigned to each parcel of land. There are two common identifier options in linking tax assessment data to parcel data. These include: (1) the previously mentioned tax identification number, and (2) a newly constructed character field that combines the numbers of the parcel block and the lot number or the State Plane Coordinates of the parcel's centroid (See Section 6.3.7. Parcel I.D. Numbers). The intended use of the data and the availability of existing data often determine which method is chosen. Typically, block and lot information are used and understood widely throughout a municipality. This familiarity in addition to common usage in the digital mapping process of the parcels, may make choosing this method the best option. In the end, it is best to choose that which is most efficient and useful for each municipality.
Let's assume that the tax I.D. number field will serve as the unique identifier. In relational database terms, the tax I.D. number in FAT is called the "primary key," and the tax I.D. number in the CAMA datafile is the "foreign key." The primary key and the foreign key must be defined the same in both the FAT and the related table. They must also be of the same parameters such as character, numeric, integer, floating point, etc. and the same field width. If the keys are numeric or floating point, they must have the same number of positions to the right of the decimal point. It is often useful to sort the related table on the foreign key in ascending order. (Hensley 1993, 24)
9.3. GIS/CAMA Integration: Crucial Features
9.3.1. Crucial
Features of the CAMA System
There are general features of a CAMA system which are important to have for
successful integration with GIS. The following section outlines the suggestions
of several different entities of both the public and private sectors. The
following list is derived from a mixed public/private sector group who used a
GIS-CAMA link to develop market models. Their work demonstrated how GIS
properly linked with CAMA systems could contribute to accurate determinations
of property values.
· The CAMA system must be capable of creating new data fields or adapting "open" fields for use by incoming data from the GIS. These data elements could be used in later modeling efforts.
· The CAMA system must be able to produce an ASCII file from data stored in its files. Given the specifications of this ASCII file, this capability will require special programming by the system developer.
· In order to store incoming data rapidly in
the appropriate records, the CAMA system must be able to create and use an
index built on parcel identifiers. The user must have built such an index
before data are imported.
Source: Curry 1990.
A binary search procedure can be used to do this. In a binary search the first and last records of the related file are compared to the value of the primary key. If there is not match, the program compares the value of the primary key to the middle record. If there is no match with the middle record, the program then assesses whether the value of the primary key is lower or higher than the middle record. If, for example, the value is lower, then the record halfway between the first and middle records is found and the comparison is performed again. Bisection continues until, either a match is made between the primary and foreign keys, or the table is exhausted. Once a record has been processed the system goes on to the next record and the search begins again, until all records in the polygon attribute table are processed (Hensley 1993, 25).
9.3.2. Crucial
Features of the GIS System
This list is also derived from the Curry study. It details items that are
important for the GIS system's role in integration.
· Either the GIS must have a user programming language enabling users to access an incoming ASCII file and attach data from it to specific polygons, or it must have a module expressly designed to read such a file (with key parameters set by users) and place the data appropriately.
· The GIS must be able to associate key descriptors with its polygons and, in turn, associate other data elements with those descriptors.
· The GIS must be able to create new,
synthetic variables derived from its analysis, associate these with particular
polygons, and then translate them into ASCII format for transmission to the
CAMA system.
Source: Curry 1990.
9.3.3. Characteristics
of CAMA-GIS Integration
There are three possible levels of integration: parcel number exchange,
periodic data downloads, and live integration between GIS and CAMA. Within
these levels, there are various technical standards that should be addressed to
insure successful integration. The following list is derived from the Curry
project:
· Flexibility: A CAMA-GIS link should allow any CAMA program to exchange data with any GIS.
· Data transfer: Rather than one program reading the internal files of the other, data should be transferred by means of ASCII files to allow for complete flexibility in choosing the GIS/CAMA system.
· Naming: The ASCII transfer files should possess names that represent common naming conventions.
· File structure: Preferably, the ASCII files should be structured in sequential format so that they will be automatically rewritten during each use. The CAMA and GIS programs must include information on the number, types and names of fields being transferred into the data stream.
· Choice of data elements
No assumptions should be made in the program as to what data elements (beyond the parcel ID) will be transferred, or where they will be placed. Users should be able to decide field arrangement per their needs. It should not be assumed that every data element received from one system would be used in another (Curry 1990).
The next table contains additional integration suggestions. These however were derived from a private sector corporation, The Sidwell Company. This information was presented at the 1998 Urban and Regional Information Systems Association (URISA) GIS/CAMA conference.
|
A Suggested Course
of Action by The Sidwell Company Let's say you are implementing a GIS utilizing ARC/INFO/ARCView, MGE, Microstation or AutoCAD. You are currently implementing a CAMA system that utilizes proprietary data formats, flat file data structures, or relational databases which are separate from your GIS data. According to Brent Mainzinger, Software Development Supervisor of Sidwell, there are a few things to consider: · Don't re-invent the wheel - research other communities that have comparable systems and have succeeded with integration. · Realize that no one specific software vendor is best at GIS and CAMA. · Work with knowns….acquire software tools that have successful track records. · Be persistent….understand that GIS/CAMA integration takes time and patience. · Use appropriate technologies that make integration easier….Window NT/'95, relational data structures, SQL compliance, 32-bit ODBC, TCP/IP, ethernet and speed. · Open systems…refrain from data structures from which you yourself cannot retrieve information. · Computer operating systems that can perform simultaneous multi-tasking, such as working with the map, GIS database and CAMA all at the same time (Windows NT does this!). · Computer operating systems that run on mainstream computers with interchangeable components (Windows NT also does this!). · Databases that can incorporate information from multiple tables and present it to the user as a single entity (Relational structures do this!). · Databases such as ODBC that can communicate with one another. · Databases such as SQL that communicate in the same language. · Networks such as TCP/IP that utilize a format understood by most other computers. · Networks such as Ethernet that utilize systems most computers can use, and do so very rapidly. In order to achieve a basic level of integration, the following tools are available for parcel transfer: · A dynamic data exchange (DDE) in which instructions are sent between programs. · Object linking and embedding (OLE) in which a function of one program can be used to access data from another program. · Text file exchanges where programs are able to retrieve information from non-local files. |
Utilizing the above-mentioned tools, a parcel transfer on one operating system might involve the following technology:
· GIS and appraisal software on NT/'95.
· Utilization of DDE and OLE to send function calls and parcel numbers between software programs (as long as the vendors are willing to modify their applications to allow this).
OR, a parcel transfer between multiple operating systems might involve the following technology:
· GIS on NT/'95
· Appraisal software on UNIX or AS/400
· An emulator such as Reflections with a 32-bit application, a robust scripting language, is Visual Basic-compatible, supports DDE and OLE and has a strong track record and a large user base.
· Utilization of DDE to perform the actual data transfer by screen-scraping the parcel number from CAMA and sending it to the GIS, or sending key strokes from the GIS to the CAMA to perform a parcel search.
OR, a parcel transfer utilizing DOS appraisal software might involve the following technology:
· GIS and appraisal software on NT/'95, with appraisal software running in a DOS window.
· GIS updates a text file with parcel number of interest.
· Appraisal software sees modification date/time stamp and knows to read the file and find the parcel.
Figure 9.2: Suggestions from Sidwell (Source: Mainzinger 1998, 1.130)
9.4. Applications of GIS/CAMA Collaboration
The basic use of a GIS is in the appraisal process. Assessors tackling their daily tasks can utilize the GIS-CAMA link to answer the following questions:
· Where is the property in question located?
· How much acreage is there?
· What is the composition of the soil?
· In which tax district is the property in question located?
· What percentage of the property is wooded?
· How much road frontage exists?
· In which neighborhood is the property located?
· In which township is the property located?
Source: ESRI 1998, 1.103
Electronic data analysis, such as a GIS/CAMA collaboration, can be highly complex. Many potential applications have been identified to make use of this analysis. These functions are used to answer the above-mentioned questions. They include valuation models construction and model process performance analysis, graphic data analysis, and visual desktop review to perform on-the-spot inquiries.
Valuation models are used to estimate accurate
property values. Use of the GIS/CAMA collaboration to construct and analyze
these models is extremely useful for making more efficient and productive use
of an assessor's time.
Graphic data analyses incorporate appraisal analysis and thematic map
production. Standard (base map), neighborhood, sales ratio, land-to-building
ratio, value per square foot/acre, and small-scale are some of the types of
thematic maps which can be produced to assist with analysis tasks, examples of
which are listed in Figure 9.3.
|
Appraisal Analyses · Comparisons among properties |
Figure 9.3: Appraisal analyses
Desktop review previously required a fieldtrip to the site in question. With GIS/CAMA integration, the assessor can access digital, visual information at-hand to assist property owners. This function can be enhanced with the addition of the following utilities:
· Sales selection and reporting to find comparable properties
· Links to area maps, digital photos and sketches
· Links to other maps such as zoning, neighborhood, utility and soils maps
· Links to the model generator application
As an additional benefit, the ability to perform functions such as these, and to be able to do so repeatedly, can save time and money and assist in deferring expenses of the GIS/CAMA integration (Ireland 1998, 1.20).
In addition to the various applications and analyses utilizing GIS/CAMA connections, the maintenance process of the assessor's maps can also be eased and more automated. The following maintenance processes can be performed with integration into the GIS enterprise: map updates due to splits, combinations and new plat filings, lot sizing, acreage and dimension recalculations, area and frontage calculations, and dimension annotation.
Management of a GIS/CAMA collaboration is not limited to the assessor's office, but extends to the entire GIS enterprise. Because one goal of enterprise GIS is openly accessible and available data, stewardship of that data from all departments using the information should be encouraged. Departments involved in general GIS enterprise management may include Fire, Police, Environmental Services, Public Works, Planning, Utilities, Buildings, Parks & Recreation, Economic Development, Licenses, Finance and Assessor. Issues these departments would need to address include: data backup and archiving, security and access, information integration, geometry integrity, business rules, usage, currency, history and ownership (Holmes 1998, 2.38).
One way in which to handle these issues is to institute a relational database management system (RDBMS). Within this system the goal is to minimize data redundancy while maintaining department control. The RDBMS manages data and enforces the "business rules" established by the GIS enterprise. Examples of these rules include detecting data discrepancies, valid data entry, correct linework and managing workflow tasking, among others. For example, the assessor's department would retain control of the CAMA data while the mapping department controls the parcel/land base graphics. With RDBMS, any attribute changes made by members of various departments (having permission or authority to make changes) could be reflected to other departments via update messages. For example, User A may be making a change to a parcel which happens to be in the same area to which User B has connected. User B would see the changes each time the connection to the database is refreshed. If User B were to make a change to the same parcel after User A, a "warning" window might pop up indicating the discrepancy, and offer a view of User A's changes.
Another tool useful for GIS/CAMA integration management is the Macro Routine. Macro routines, or case-specific programs, can be written, for example within ARC/INFO, to simplify map production. Routines written in ARC/INFO use ARC Macro Language (AML). Other programs, such as ArcView, would utilize the programming language used specifically by their software, like Avenue. Macros perform repetitive functions and operations. Extremely complex sets of commands can be executed automatically while user interaction is kept to a minimum. Macros require conditional logic. This is necessary when program variables are subject to constant change. An example is subdivision of a neighborhood contingent upon fluctuating local development over an extended period of time. Conditional logic applies, for example, to the selection of the household numbering within the neighborhood. The numbering scheme must account for the possibility of future development.
9.6. What's the Current Situation?
9.6.1. The Industry
Across the United States, there are many, many GIS sites that have not
integrated their appraisal and mapping systems. Even though the mapping process
is now automated, it is a very powerful tool that is significantly
underutilized. Of those regions in the U.S. that have connected GIS and CAMA,
there are many levels at which the integrations are functioning. One such level
entails one-way connections that use file transfer processes to either, provide
data for visualization of appraisal data for GIS users or, to generate data on
the GIS side and use it to update the appraisal database. A small number of
communities have established bi-directional integration. These communities have
been able to overcome technical and organizational factors, in addition to
under-developed GIS databases, to make the best use of GIS functionality. At
this pinnacle of success, users are able to use GIS to create new data and
eliminate redundant data entry.
What are the technical and organizational factors making it difficult for communities to effectively and efficiently integrate GIS and CAMA? (ESRI 1998, 1.110)
|
Technical Factors: · Different platforms for CAMA & GIS |
Figure 9.4 Technical and organizational factors
Fortunately, in the future these problems may be curtailed (See Section 9.7. The Future: Emerging Trends).
9.6.2. Evolution of
the Assessor's Role
Previously, as of the mid-to-late 1980s, the primary role of the assessor's
office was to accurately and efficiently ascertain property values. With the
broad acceptance of GIS by assessors in the 1990s as a subsystem of CAMA, the
role of the assessor has broadened to include that of information manager of
the CAMA system for use in GIS. The role has evolved from CAMA tax account data
manager, to CAMA data facilitator, to GIS data organizer. GIS should be a hub
of CAMA and not merely a subsystem. Additionally, this evolution of an
assessor's role should not be downplayed by communities lagging behind in the
process, because the integration of GIS and CAMA is not a question of IF, but
rather, WHEN and HOW (Ireland 1998, 1.18).
9.6.3. Massachusetts
The percentage of communities in Massachusetts integrating their CAMA and GIS
systems is presently not known. Through interviews with various assessors'
offices, and communications with attendees at the 1999 New England Urban and
Regional Information Systems Association (URISA) GIS conference, it is clear,
however, that a large majority are either interested in migrating towards a GIS
enterprise, or are in the midst of a needs assessment or partial implementation
(Scheid 1999).
There are many types of CAMA systems available. In Massachusetts, there are essentially three alternatives for municipalities: in-house development, a commercially available system, or generic software tailored by a consultant to the needs of the assessors department. In-house development is customized, yet expensive and time-consuming. Commercial systems are practical, yet create dependency upon a vendor. Adaptable generic software is highly functional, user-friendly and easily modified. A fourth alternative would be a combination of the three mentioned above such as supplementing a vendor-supplied system with generic software (See Section 10.0. Outsourcing).
To assist Massachusetts' communities with automation and CAMA acquisition, and to enable compliance with a legislated mandate for the establishment of local CAMA systems, the Department of Revenue created CAMA and Tax Administration software. This represents an example of the fourth alternative: a combination of state-developed software, commercial software, and vendor-supplied enhancements. The most current upgrade, constructed with assistance from SIGMA Corporation, uses Oracle database software as its core, can run on a stand-alone PC or a large multi-processor server, works with a variety of operating systems such as Win95, NT Server and SCO Unix with Windows clients, and uses 32 bit technology. This is in addition, but not limited to, enhancements such as user-defined fields and public access programming (Davies 1997, 1). Approximately 87 communities out of 351 in the state use the DOR software (Hyde 1999). For those communities not using the State system, the two most commonly used commercial CAMA systems include Patriot, and Vision by Vision Solutions ( www.visionsolutions.com ). The Patriot system is built on SQL Server and Vision is built on Microsoft Access (For further information on the Patriot system, contact the assessor for Townsend, Massachusetts.) The Town of Amherst uses Vision CAMA Software. By the end of 1998, Vision released a new version of their CAMA software that is Oracle-based and runs on Windows 95, 98 and NT. In order to link Amhert's Vision CAMA software to the GIS, the map-lot numbers within the GIS will be linked to the map-lot numbers stored in Vision's REALMAST file. With this link intact, the GIS will be able to read data from all of Vision's files such as the Land, Parcel, Building, Permits and Construction databases. The link will enable Amherst to query Vision data from within the parcel GIS and also query the parcel GIS to retrieve Vision data. Several New England communities utilize a "custom" VISION/GIS link developed by Camp, Dresser and McKee of CHAS. H. SELLS, Inc. Information on this custom link can be obtained by contacting SELLS, Inc. directly (CHAS 1998, 36).
To further assist communities, the Massachusetts DOR's Division of Local Services has established a CAMA Software Consortium (CSC). The Consortium "was formed to provide a flexible, responsive means for communities using the DOR CAMA and Tax Administration software to fund, specify, and contract for future enhancements to the system as well as to migrate to new technologies as appropriate" (Davies 1999). The goal of the State CAMA program is to increase local self-sufficiency and professionalism. While the DOR maintains the base CAMA system and continues to train assessors and collectors, the CSC is actually run by regional representatives elected to a Board of Directors. Administration and purchasing for the organization is handled by the Franklin Regional Council of Governments.
9.6.3.1. Massachusetts' Case Studies
9.6.3.1.1 Townsend,
Ashby and Lunenburg
In 1997 the north-central Massachusetts towns of Ashby, Lunenburg, and
Townsend, under the direction of Regional Tax Assessor Harald Scheid, sought to
undertake the development of a Geographic Information System. From the
beginning it was clear that selling the town fathers and citizenry on funding a
GIS program required that: a) all town departments have access to the system,
and b) the GIS not be a "fancy mapping system", but a powerful
analytical tool enhanced by its integration with the towns tabular data
resources.
This case summary, written by Harald Scheid, highlights the development of a "Core Municipal Database" (CMD) developed for the towns of Ashby, Lunenburg, and Townsend. Many communities have acquired GIS technology and benefited from the new perspectives a spatial view of their community provides. While much planning usually precedes development of the graphical components of a GIS, communities are often at a loss about how to develop the equally important tabular database component. Ashby, Lunenburg, and Townsend have developed a comprehensive municipal database that pools data from the various departmental systems and databases.
The goals in developing a CMD are as follows:
a) to bring real estate data held by the
various town departments together
into a uniform, centrally accessed and maintained data reservoir
without requiring departments to abandon their current computer
applications;
b) to define, create, and maintain new data
elements not currently stored
in existing databases, and provide a depository for data currently stored
in manual form;
c) to insure a uniform database standard,
minimize data redundancy,
and maintain data currency;
d) to allow for a dynamic database that can grow as new data needs emerge;
e) to maintain a database definitions document
describing CMD tables
and data elements;
f) to provide for easy integration with ESRI
ArcInfo/ArcView, thereby
enhancing the value of GIS; and,
g) to make data available to the public and
other institutional users via the
Internet.
Database Description
The common key linking CMD tables to the GIS is a 22 character "Parcel Identification Number" (PID). PID numbers follow the following format:
State - Community Number - Map Number - Lot Number - SubLot Number
example: MA299-0034-000123-0001
Four tiers of database tables make up the CMD. They are described as follows:
Primary Tables
These tables make up the core data elements
that can be accessed by GIS users
Tables and Descriptions (examples)
Dbmaster.dbf location, ownership, addresses,
and use
Dbbounds.dbf political and other jurisdictions
Dbmsland.dbf land characteristics and measures
Dbownhst.dbf ownership history and recording info
Dbcensus.dbf occupant profiles
Dbphotos.dbf digital photographs
Dbresbld.dbf residential building characteristics
Dbcondos.dbf condominium building characteristics
Dbmultis.dbf multi-unit residential building characteristics
Dbcombld.dbf commercial/industrial building data
Dbstructs.dbf other detached buildings and structures
Dbpermit.dbf building permit data
Dbsales.dbf complete sales record showing transaction
data and primary property characteristics at
time of sale
Secondary Tables
These tables are generally available to all GIS users but may have limited or specific value to only one department.
Tables and Descriptions (examples)
Dbinspct.dbf property inspection log
Dbordcnd.dbf land use orders and conditions
Dbasland.dbf assessors land assessment breakdown
Dbchpmst.dbf detail about chapter 61, 61a and 61b lands
Dbvalhst.dbf history of tax assessments
Dbvalrec.dbf current valuation data
Tertiary Tables
Adhoc tables, usually of a temporary nature, defined by individual users
Tables and Descriptions (examples)
Dbslstmp.dbf listing of recent sales
transactions for
which registry deed copies have not yet
been received
Dbgrowth.dbf table of newly constructed and improved properties qualifying for
exemption from Proposition 2 ½.
Lookup Tables
Series of lookup tables underlying primary and
secondary
databases that provide for uniform data entry
Tables and Descriptions (examples)
Luusecod.dbf Massachusetts standard property
use
codes
Lubstyle.dbf building types and styles
Lustruct.dbf table of miscellaneous detached structures
Luheattp.dbf heating systems
Luphsdpr.dbf types of physical depreciation/deterioration
Populating the Database
Once the shell CMD and documentation describing its tables and field attributes had been established, a conversion utility was developed that extracts data from departmental databases. Extracted data is reformatted and deposited in each of the CMD's tables. Once source and destination directories have been defined, the conversion utility requires little human interaction. Options are available to selectively update primary tables, or erase and rebuild individual tables. To fully convert available data takes about 3 seconds per parcel running on a Pentium 233Mhz microcomputer.
An important feature of the CMD is the use of "long labels". Most databases and computer applications use abbreviated field values that are unintelligible to the untrained user. For example, a code describing clapboard siding might in one assessment database be labeled 'FB' (meaning frame construction with board siding). In still another assessment system the same clapboard siding might be signified by a numeric code such as the digit '6'. These short labels are of no value to a user unfamiliar with the codes. The CMD uses unabbreviated, long labels. In the example above, a property with clapboard siding would carry a field value "FRAME-CLAPBOARD" in the building characteristic field for exterior construction.
Updating the CMD is performed on a monthly basis, or more frequently when departmental data has been updated. The process is usually run over-night.
Other CMD Uses
The dBase formatted tables making up the CMD can be readily queried and imported into other desktop computer applications with no further conversion necessary. MS Excel is especially adept at accepting CMD data. Mail merges utilizing current ownership data found in the CMD are easily processed.
Hopefully, the CMD data will soon be available over the Internet. The "front-end" application to manage web-data browsing is currently in the planning process. It is anticipated that most real estate professionals, investors, developers, and citizens will welcome the easy access to public records. State and regional governmental agencies will likewise have access to both GIS and CMD resources.
The Commonwealth of Massachusetts and its constituent communities may see the value in adopting a uniform database standard that does not require the abandonment of existing municipal applications. Inquiries about this project should be addressed to Harald Scheid, Regional Tax Assessor for Ashby, Lunenburg, and Townsend (PO Box 135, Lunenburg, MA 01462, (978)597-1706 (M&Th), (978)582-4145 (Tu&F), or (978) 582-2427 (W)).
9.6.3.1.2. Newton, MA
Newton's CAMA serves as the main attribute database attached to the parcel
layer, containing hundreds of columns of attribute data. Their system, like
most others, is responsible for storing data on parcels for creating the
property tax bills for the city.
Traditionally a COBOL application, Newton uses a CAMA system written by SIGMA (not the Department of Revenue's SIGMA system) which is based on an ORACLE relational database management system (RDMS). SIGMA decided to port its CAMA application to ORACLE based on local communities' interest. Even before the SIGMA CAMA application became available, Newton agreed to purchase the ORACLE software, knowing that scripts would have to be written in the interim to take the COBOL data and load it into ORACLE. Prior to final development of the new SIGMA system, ORACLE table structures were available, so the extraction scripts were written and run on a weekly basis. They provided the Newton GIS community with fairly up-to-date, comprehensive parcel attributes such as owner, property values, structure values, last sale date, parcel details and structure details.
The ARC/INFO parcel coverages were linked via relational database interface to the ORACLE tables, which stored the CAMA data. The only attribute stored in INFO was the parcel number. Previously, the casual GIS user was offered a user interface that facilitated access and query of the CAMA database. When SIGMA's fully ORACLE CAMA system became operational, the GIS coverages were linked into the transaction database in a read-only fashion (Terner 1995, 6).
9.6.4. Software and Hardware Case Studies: Beyond Massachusetts
9.6.4.1. James City
County, Virginia
Currently, all assessor's information, the CAMA database, exists in ProVAL, a
windows-based software. The CAMA database is in an R-based programming language
that is difficult to translate into Arc/Info and ArcView. In order to
accommodate for this, the information is translated into a structured query
language (SQL) platform and then put into Microsoft Access for formatting. Once
formatted, the information is saved as a Dbase file format (.dbf) file and
placed on the server for enterprise users. Users must copy the information from
the server onto their own systems, using their own previously designated
project names to maintain consistency and avoid re-linking or re-building
existing projects. The county's goal is to also convert the tax billing system
into SQL platform, and then use ArcView's "SQL Connect" function to
create links and views for enterprise users. This system allows constant access
to daily-updated data, while preventing manipulation of data. As it currently
exists, users must download the data on a regular basis to account for all
updating (Daniels 1999).
9.6.4.2. Johnson
County, Kansas:
In the 1980s, local officials in the Kansas City metropolitan region observed
rapid growth taking place and recognized the need for a reliable, dynamic and
multipurpose automated mapping system. A five million-dollar GIS project was
initiated in 1985 and, despite delays and poor performance from the conversion
contractor, it was completed in 1992. The Automated Information/Mapping System
(AIMS) that was developed contained lot lines, plat boundaries, property
boundaries and unique parcel identifiers, in addition to the Public Land Survey
System (PLSS) and other cadastral features.
The tax appraisal staff utilizes the system via customized map products and formats to assist with their daily procedures of identifying, listing and valuing properties. Graphic data analysis of the tax assessor's database information is performed by associating the CAMA with AIMS, the geographic database. No "live" link exists between AIMS and CAMA. CAMA data used in the GIS must first be downloaded as ASCII data from the county's IBM 3090 mainframe to a PC station to a UNIX station where the ARC/INFO software resides. On the workstation, the raw ASCII data are imported into a predefined INFO table. The process is slow but effective. In the future, the appraisal office would like to have a direct, interactive link between AIMS and CAMA so that all analysis will be as current as the data (Hensley 1993, 19).
9.7. The Future: Emerging Trends
The future holds much promise and sophistication for GIS and CAMA integration, in addition to continued ease of use for assessors and the GIS enterprise. The following is a list of innovations being addressed at the time of publication of this document:
· Maturing GIS databases;
· Sophisticated use of GIS;
· Pressure on vendors to integrate with GIS;
· Improved network connectivity;
· Improved database capabilities such as ODBC, or Open Database Connectivity;
· Open system linkages (bi-directional);
· Combining attribute demographics with population demographics by linking CAMA and Census data;
· Correlation of purchasing power to property attributes instead of to social and economic factors;
Source: ESRI 1998, 1.114 and Ireland 1998, 1.21.
9.8. Final Thoughts on CAMA/GIS Integration
GIS is quickly becoming an important mapping tool in many assessment jurisdictions. Properly used, a GIS can provide assessment administrators with a powerful means for analyzing information in the form of "intelligent" maps, using relational database management software to link descriptive data with graphic data. In observing the tactics of various communities for connecting their GIS and CAMA systems, it can be seen that connection methods are case-specific to the needs of each community and its local government. Some standards can be recommended, but ultimately, it is crucial to ascertain what is most important for the local GIS enterprise.
| Next Section: Outsourcing | Home |