Stan Gerber
Abstract:
Quality assurance of attributes is one of the most daunting tasks that confronts agencies involved in map conversion. Paper checkplots, while very useful for content checking, often become unworkable as a means to verify complex attribute coding because of the volume needed for proper QA and/or the interpretation of intricate symbolization. This paper describes an on-line system that Pierce County has developed to facilitate the QA process in its assessor map conversion project. The system exploits Arcplot commands in Arcedit to provide map checkers with easy-to-understand, rapid views of label and arc attribute values. Through a simplified symbology, map checkers can readily identify discrepancies--and make immediate corrections. The system reduces the interpretation, training time, and lag-time between error detection and correction that is often inherent in a paper QA process.
One of the most complex tasks that accompanies the receipt of data from a conversion vendor is Quality Assurance (QA). While the conversion vendor may require hundreds of hours and/or days to input data from paper maps, the burden of checking the data usually falls to the agency that receives it. As such, an efficient and effective system for verifying the accuracy of the attribute data is critical for the success of a GIS conversion project, which essentially means the future useability of the data.
While one could take many approaches to QA, several requirements are paramount to both project manager and map checker alike for any QA system:
This paper describes a straightforward and simple on-line technique that Pierce County has developed to help support the QA of attributes on approximately 270,000 parcels on 7000 Assessor quarter-section map tiles (ten layers each) that have been contracted to be delivered over the next two years.
An initial content check of map data is probably best performed with a large- scale checkplot. A map checker can readily verify that the contractor captured all lines and annotations by comparing the checkplot with the source map. Likewise, line and annotation positioning and readability are easily checked on a paper plot of the same scale as production copies.
A map checker could also produce multiple checkplots with the Arcplot dropline function for label attributes, and highlight arc attributes with still more checkplots. This approach might work well when only a few attributes for each feature are coded and a plotter is dedicated to the task.
When a checker must verify complex attributes, however, the checkplot approach quickly becomes unworkable for a number of reasons. For one, a checker would be forced to produce so many checkplots that he/she would be quickly overwhelmed with the sheer volume of paper to deal with. Additionally, each time changes are made, a checker might have to produce a new series of checkplots to verify the changes. This becomes an inefficient approach in terms of both plotter supplies and time--time which may not be available because of resource down-time, scheduling conflicts, or simply the lag time between edit changes and their verification.
A checker could, of course, combine multiple attributes on a plot and significantly reduce the amount of plotter resources needed. This approach, however, has an inherent pitfall: overly complex symbology. For example, to verify attributes of multiple levels of land division, a checker would have to interpret numerous shades and line symbols. If features are coincident--which is most always true--certain symbols would obscure or at least confuse other symbols, and perhaps even create new ones. For this effort, a checker could spend an inordinate amount of time developing and learning a complex symbology. As a result, much time would be lost interpreting symbology instead of actually verifying the attributes that the symbols represent.
Because of the limitations of checkplots for attribute verification, Pierce County developed an on-line QA system to support the conversion of its Assessor maps. The on-line system takes advantage of the ever-increasing processing power of workstations, while eliminating the mounds of paper and dedicated plotter resources that would traditionally be needed for attribute checking.
At the heart of attribute verification is a relatively simple concept that allows a map checker to view the attributes in a straightforward and meaningful way: use Arcplot commands in Arcedit. These commands allow checkers to take advantage of Arcplot's many display tools within a robust edit environment.
One very useful and probably greatly underutilized tool introduced with Version 5.0 was the ability to incorporate Arcplot commands inside of Arcedit by redrawing the coverage with an AP file toggled on. In order to produce a readable display, however, the draw- and backenvironments needed to be toggled off before each redraw, and on again after viewing. Additionally, these Arcplot commands had to be stored in a separate file, and could only be executed by issuing the Arcedit "draw" command. The procedure was as follows:
Arcedit: &setvar drawenv := [show
drawenvironment]
Arcedit: &setvar backenv := [show backenvironment]
Arcedit: drawenvironment all off
Arcedit: backenvironment all off
Arcedit: ap %pathname%/dropline.ap
Arcedit: draw
Arcedit: ap none
Arcedit: drawenvironment %drawenv%
Arcedit: backenvironment %backenv%
The dropline AP file might contain the following:
/* DROPLINE.AP ---- Pierce County WA, ISD/GIS
linecolor blue
/* Draw all
arcs in blue
arcs %.ae$layer%
/* for
orientation
textsize 0.1
/* Text in
white (default)
linecolor red
/* Dropline
boundary arcs
dropline %.ae$layer% %.dropline$item%
/* in
red
(Note: In AP files variables could not be passed using the &args directive, and and no &return was necessary to end the file.)
At Version 7.0 Arcplot commands can be executed at any time by using the Arcedit "arcplot" command with Arcplot syntax. This eliminates the having to issue the "draw" command to execute the commands and toggling the draw- and backenvironments. Additionally, it allows much greater flexibility in programming because the commands can be subroutines instead of separate files, thus reducing file management problems. The same result as above can be obtained at Version 7.0 by running the following:
/* DROPLINE.AML ---- Pierce County WA,
ISD/GIS clear
/* Clear
display
arcplot
linecolor blue
/* Draw all
arcs in blue
arcs %.ae$layer%
/* for
orientation
textsize 0.1
/* Text in
white (default)
linecolor red
/* Dropline
boundary arcs
dropline %.ae$layer% %.dropline$item%
/* in red
quit
/* Execute
the commands
The 7.0 method simplifies the coding and execution of the Arcplot commands. More important than the particular method chosen, however, is that the Arcplot commands make powerful tools for graphic verification of attributes.
A critical aspect to QA is that a map checker gets a quick and accurate view of the attribute data stored in a coverage. To do this, the dropline.aml shown above displays arcs in only two colors: blue for all the arcs (often useful for orientation), and red for the resultant dropline boundary arcs. With this uncomplicated two-color symbology, a map checker can make immediate decisions on the stored attribute values: either the boundaries formed by the attribute values are correct, or they are not. If they are not, the polygons with the errors are clearly identified, and their labels can be readily selected and edited. Figure 1 shows the view that a checker would see when the Arcplot "dropline" command is issued on the plat number label attribute.
For arc attributes the view is similar to the dropline, except that because this particular attribute is coded either Yes/No, the values need not appear. In this case, the arcs are simply reselected where the value is "Y", and highlighted in red.
/* HIGHLIGHT.AML ---- Pierce County WA,
ISD/GIS
clear
arcplot
linecolor blue
/* Draw
all arcs in blue
arcs %.ae$layer%
/* for
orientation
reselect %.ae$layer% arcs %.highlight$item% = 'Y'
linecolor red
arcs %.ae$layer%
/* Highlight
arcs in red
quit
Figure 2 shows the view the highlight.aml produces for the plat line arc attribute.
Often plat areas extend into adjoining mapsheets, and this should be reflected in the attribute coding as is the case here. Compare plat 680300 in the lower left area of Figure 1 with the corresponding arcs coded as plat lines in Figure 2 to see how the discrepancy is quickly identified for editing.
Naturally, the Arcplot commands can accommodate more complex attribute checking. A checker may, for instance, want to view the arc plat lines along with corresponding label plat number dropline boundaries. This is easily accommodated by combining the dropline.aml and highlight.aml commands and using different colors and "mapshift"ing to differentiate the features. As such, Arcplot commands allow great flexibility in viewing the attribute data from multiple features simultaneously in an Arcedit session.
The on-line QA system utilizes Arcplot commands to simplify and expedite the onerous task of attribute checking. By taking advantage of the processing power of modern workstations, the system eliminates the need for multiple paper checkplots to verify attribute values. It provides a straightforward, reliable, and easy to implement technique that permits map checkers to rapidly identify omissions and/or errors without extensive training, or interpretation of often complex and confusing symbolization and concomitant legends. Positive user comments along with rapid turnaround time confirm that these easy-to-implement tools have become major assets in Pierce County's Assessor Map Conversion project.
The author acknowledges several Pierce County staff members whose valuable suggestions have helped refine and improve the design and useability of the QA system: Janice Rogich and Tony DePaul of the Pierce County Assessors Cartography Office, and Joyce Clifford, Art Seeley, and Stan Grochowski of the ISD/GIS Division.