Stan Gerber

ATTRIBUTE DATA QA: AN ON-LINE APPROACH

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.


INTRODUCTION

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:

  1. it must be able to quickly and efficiently handle the enormous volume of map data received;
  2. it must unequivocally verify the accuracy of the attributes, eliminating any guesswork; and
  3. the symbology employed must be easy to interpret so that any learning is negligible.

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.

Checkplots vs. On-Line QA

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.

Viewing the Feature Attributes

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:

  1. Save and toggle off the draw- and backenvironments to mask the current Arcedit symbology.

    Arcedit: &setvar drawenv := [show drawenvironment] Arcedit: &setvar backenv := [show backenvironment] Arcedit: drawenvironment all off Arcedit: backenvironment all off
  2. Toggle on an AP file of Arcplot commands (discussed in the next section) to view the arc boundaries formed by the attribute values.
    Arcedit: ap %pathname%/dropline.ap
  3. Draw the features per the AP file commands.
    Arcedit: draw
  4. When finished viewing, toggle off the AP file, and toggle on the previous draw- and backenvironments to re-establish the Arcedit symbology.
    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.

Developing the ARCPLOT Commands

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.

Dropline Boundary Image

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.

Highlight Image

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.

CONCLUSION

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.

Acknowledgements

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.


Stan Gerber
GIS Systems Analyst/Programmer
Pierce County Information Services Department, GIS Division
615 S. 9th Street, Suite 220
Tacoma, WA 98405
Telephone: (206)591-7496
Fax: (206)596-6622