Using ArcView GIS as a project management tool

This paper discusses the use of ArcView GIS for managing GIS projects. It includes pre-project planning and estimating, status tracking, use as a communications and reporting mechanism, and as a way to measure work effort against plan.

Data base structures are used to track scanning, tic measurements, georeferencing, scan conversion/digitizing, attributing, and QA/QC processes, depending on project requirements. Dates, operator, and notes are entered, and are processed to set flags in the pat.dbf file. The methods used, while generalized, require some modification to fit specific project needs.

Data structures are used to link project elements to support automation of key processing steps. ArcView is used to graphically highlight issues and illustrate project status versus requirements. Specific examples will be presented.

The use of project management software is frequently confined to tools like Microsoft Project or other CPM/Gantt chart creation software. The primary purpose of such tools, of course, is to produce enormous wall-size diagrams intended to bamboozle management - our own or the clients - into presuming we have a handle on things. Since these charts are difficult to read and impossible to interpret, they do this very well.

Too often, we are guilty of ignoring a really useful management tool that we all know and love - ArcView GIS. We all promote ArcView as a panacea for every known ill, a veritable Swiss Army knife of GIS capabilities, but we don�t always recognize its utility for helping to manage projects. This does not mean we exclude other tools; we use spreadsheets and extensive Visual FoxPro programming as well.

If your project involves work associated with a spatial area, especially if that area can be subdivided, you should consider ArcView as a project management tool. This is particularly true if each of the spatial sub-units must be tracked through several progressive states. These sub-units might be political or administrative subdivisions such as counties or provinces, or they may be grid tiles used to georeference the project to a coordinates system.

2. Regular control grids

Many of us work on GIS projects that are characterized by the use of a grid to divide the project area into smaller tiled elements. In the U.S., these are frequently elements of the Public Land Survey System, such as townships, sections, or quarter-sections, but they may be any local grid as well. These grids are an excellent way to subdivide a GIS project into smaller spatial units for project management purposes.

Let us look first at the task of estimating the scope of a potential project. Whether you are the organization seeking suppliers for this work, or a supplier preparing a cost and timing estimate, ArcView is an excellent way to get familiar with the scope and complexity of the proposed work. Frequently, we can classify individual tiles by level of complexity. Usually, a simple three-level scheme such as sparse, moderate, complex will suffice. By defining the grid as a set of corner points with associated polygons and entering these assessments as attributes, it is easy to develop work estimates, and to get a sense of how the work is distributed spatially.

3. Estimating effort

In this example, we can see that the most complex and time-consuming effort will be encountered in the central part of the view. This may suggest different approaches for different areas of the project, such as automated scan conversion in the less dense areas, with heads-up digitizing in the center. In any event, the ability to view the project in this way contributes to our understanding of it�s unique characteristics.

During the execution phase of the project, there are many tasks which can be addressed using ArcView. These tasks include automation of repetitive procedures and status tracking. We will examine two examples from a current project

Once you have defined the grid, and sized the project, ArcView can be used to help with executing the project as well. Most projects require that several steps, possibly involving several map types, be performed for each cell in the grid. We have found that many of these processing steps require small programs - in Autolisp, AML, or other language - that can be automatically generated from the tables supporting the ArcView project. One common example is georeferencing.

Often, the existing information is not positioned correctly, either because individual maps are not referenced to a coordinate system, or because newer, more accurate geodetic control has been acquired and is to be used. It is necessary to rubbersheet control corners in the individual tiled data (in this example, raster scans of the mylar drawings) to corresponding corners in the grid which have been measured using the new geodetic control.

4. Georeferencing to a grid tile

Let�s examine the architecture of a typical project to see how all of these elements are related. The project in question is the conversion of mylar maps to a coverage for the Tucson Water Department. There are five kinds of maps involved, each covering four sections, or one-ninth of a township. The Department calls this areal extent a System Planning Unit Grid (SPUG). For each map type, there are several sequential steps that must be completed (not all steps for all maps).

The data structure for this project consists of four files:

1) The grid's PAT (called GRIDPAT herein). At the minimum, it includes (after the standard PAT fields):

• a grid identifier (called GRID_ID herein)
• a cell identifier (called CELL_ID herein)

These two ARE different; the CELL_ID must be 7 characters long (or less) while the GRID_ID can be of any length that is convenient or appropriate to the application; note that they MAY BE COMBINED into one field IF the id can never be longer than 7 characters!! The length restriction is due to its use as a file name basis. For Tucson Water, the CELL_ID is a SPUG cell identifier (TTRRP); the GRID_ID and the CELL_ID are NOT identical! The GRID_ID is the full County identifier (e.g., ETTRRP).

Other fields are added as convenient or required by the application and QA/QC needs.

2) A file info dbf (called QAFILE). It establishes the relationship of each raster image, drawing file, or other georeferenced data set with its corresponding grid cell. While there may be only one file associated with a grid cell, typically there are several. For Tucson Water, we have several and these are at different resolutions. For example, we have 5 (Water System, Water Planning Area, Node, Base [Parcel], and Trib maps) for each cell of the System Planning Unit Grid (SPUG). We also have four different grids.

At minimum, necessary fields include:

It should include appropriate other QA/QC information.

3) A tic dbf (called QATIC). It establishes the relationship of each tic point with the corresponding raster image. At minimum, it includes:

CELL_ID (may be identical to grid_id)

FILE_ID,

TIC_ID a tic identifier; also establishes processing order of tics

POINT_ID a unique point identifier

CORNER4 an identifier (1�4) which says if the tic is used in the four-point-only rubber sheet (up to 25 points can be rubbersheeted at a time by Tracer)

X_INCH to record the abscissa of the tic

Y_INCH to record the ordinate of the tic (both of these MAY be in inches, or they may be in some other units, such as a local grid feet).

TICS are assigned starting in the southwest corner and proceeding clockwise.

Other QA/QC information is added as desired.

4) The point's PAT (called POINTPAT herein). At the minimum, it includes (after the standard PAT fields):

POINT_ID a unique point identifier

X_COORD the abscissa of the real-world's point

Y_COORD the ordinate of the real-world's point

Other fields are added as convenient or required by the application and QA/QC needs.

Each grid cell (of GRIDPAT) has a single entry. It has a 0+:Many relation to QAFILE (i.e., a cell may have no, one or many files associated with it); either GRID_ID or CELL_ID is the KEY field (or both).

Each associated file (image, drawing) has a single entry in QAFILE. There is a 1:Many relation to QATIC (i.e., a file entry will always have at least 4 tic entries); CELL_ID + FILE_ID are the KEY fields.

Each file (image, drawing) has multiple tics and each will have a single entry in QATIC which has a Many:0+ relation to POINTPAT (i.e., any one point may serve as a tic for multiple images, but some points may not be tics at all); POINT_ID is the KEY field. However, CELL_ID + FILE_ID + TIC_ID is the Primary Key for this table even though it is not used to directly relate to anything else (this is what is unique and how the table must be indexed so that tics are processed in the proper order).

Finally, every corner point of the grid has a single entry in POINTPAT. Its Primary Key is POINT_ID; this is used to relate to QATIC.

This table structure, while somewhat complicated, is fully normalized and offers the most flexibility with no redundant data storage. It is written to support TRACER v2.0 (or later) which allows for up to 25 rubber sheet points; the format of the call to the RRUBSHT routine has changed. This new structure allows each grid cell to have multiple corner georeferencing points (up to the limit of 25 for each cell). Whether these are used or not depends on the number of tic marks shown on each mylar (scan) and practical concerns for georeferencing. In this example, we will only use 4 point processing (IMAGERUBSHT4).

The environment is set first. After opening various files, setting default memory variable values, and establishing file relationships, the user is asked to enter the

TILE_NAME identifier (grid_id, which is the same as the cell_id in this project),

file type, operator's initials and measurement date. The relevant cell information in PQAFILE.DBF (aliased as QAFILE), its associated tic information file TPQATIC.DBF

(aliased as QATIC), and the master point information file QS3P_H1\PAT.DBF (aliased as POINTPAT) are used to initialize the OUT\TIC.DBF and OUT\BND.DBF. The master grid cell data table SPUG_H1\PAT.DBF (aliased as GRIDPAT) is referenced as necessary for relevant cell information.

TWTRAN2 then prompts the user to enter the coordinates, in inches of each of the corner tics and stores this information in successive records in QATIC. These are also written to the IN\TIC.DBF. The PC ARC/INFO TRANSform program is then called to calculate the RMS error and scaling factors (x and y) as if the actual transformation was being done from inches directly to the specified real-world tics.

The results of the TRANSform program are stored in a file whose name is based on the original CAL files' name (but with extension .TRN). This file is then opened and the x and y scale factors and RMS error are extracted and stored in the QAFILE table.

* Open up <name>.LSP as alternate file.

*** !!! We only create one LISP file, standard four corner rubbersheet

*** starting at lower left (southwest) corner.

a_file = m_cellid + m_fileid + ".LSP"

m_scale = ALLTRIM( STR( QAFILE.SCALE_FACT, 14, 4))

SET ALTERNATE TO (a_file)

SET ALTERNATE ON

SET CONSOLE OFF

?? ';; Lisp program for Tracer v4.1+ to automate georeferencing of raw ' + (m_filein) + '.'

? '(setq fname ' + '"S:\\DATA\\SCAN\\RAW\\' + (m_filein) + '")'

? '(setq fname1 ' + '"S:\\DATA\\SCAN\\GEOREF\\' + (m_fileout) + '")'

? '(setq posfname ' + '"S:\\DATA\\SCAN\\GEOREF\\' + (m_filerat) + '")'

? '(setq posfname2 ' + '"S:\\DATA\\SCAN\\GEOREF\\' + (m_filetfw) + '")'

? '(setq imagename "' + (m_file) + '")'

? "(setq inspoint '( 0 0))"

? "(setq bottomleft '(" + STR( m_xmove, 10, 4) + " " + STR( m_ymove, 10, 4) + "))"

? '(setq scalefactor "' + m_scale + '")'

? "(setq lowerleft '( " + STR( QATIC.X_TRANS, 10, 1) + " " + ;

STR( QATIC.Y_TRANS, 10, 1) + "))"

5. FoxPro code fragment � writing Autolisp programs

An AutoCAD LISP program file, <cell_id><file_id>.LSP is generated. It has the proper AutoLisp code to convert the raw scan <file_id><cell_id>_1.CAL file into the corresponding georeferenced CAL file with name <file_id><cell_id>_2.CAL; This automates the entire conversion (transformation or rubber sheeting) process.

NOTE that in this context ONLY, the cell_id has the leading "E" removed; for example, the township scan file is P13142_1.CAL georeferenced to P13142_2.CAL and The AutoLisp file is called 13142P.LSP.

IMAGERUBSHT4 allows only 4 rubber sheet points. Input coordinates (x,y) are given in pairs, with the original coordinate first, followed by the output coordinates (x,y).

QATIC records all georeferencing coordinates that pertain to a particular cell (section). Thus, the same point may be entered numerous times. A particular field in QATIC is CORNER4 [Char 1] is set to "1" to "4" if the point is to be used in generating <cell_id><file_id>.LSP coordinates, " " if not.

For further details on grid_id and cell_id actual values, see below.

The cell_id (field TILE_NAME) has the structure:

DTTRRSSQ (or DTTRRP)

where

D is the range direction (always "E" for our area of interest)

TT is the township identifier (with leading zero if necessary)

RR is the range identifier (with leading zero if necessary)

SS is the section identifier (with leading zero if necessary)

P is the SPUG cell identifier

Q is the quarter section identifier

TILE_NAME is the basis for BOTH the GRID_ID AND the CELL_ID. The CELL_ID simply drops the leading "E" from the TILE_NAME entry.

5. Data base schema for Tucson Water project

* If map exists, and no scan yet made, then status is "N".

REPLACE ALL GRIDPAT.WAT_SYS_ST WITH "N" FOR EMPTY( QAFILE.SCAN_DATE)

* Set scan status.

REPLACE ALL GRIDPAT.WAT_SYS_ST WITH "S" FOR !EMPTY( QAFILE.SCAN_DATE)

* Set tic measure status.

REPLACE ALL GRIDPAT.WAT_SYS_ST WITH "M" FOR !EMPTY( QAFILE.TIC_DATE)

* Set georeference status.

REPLACE ALL GRIDPAT.WAT_SYS_ST WITH "G" FOR !EMPTY( QAFILE.GEOREFDATE)

* Set vectorization status.

REPLACE ALL GRIDPAT.WAT_SYS_ST WITH "V" FOR !EMPTY( QAFILE.VECTORDATE)

7. FoxPro code fragment - updating status

One of the most challenging aspects of project management is that of tracking status and sharing this information with management. ArcView provides a powerful mechanism for communicating how much has been completed, where slippage is occurring, and what areas of he project are complete.

8. Tucson Water Status

During the QA/QC process, problems requiring intervention or correction are identified. These can be managed using a simple data base or spreadsheet, but it is more powerful to build a point coverage to highlight spatial relationships. In some cases, this facilitates assigning neighboring problems to the same person for resolution.

This step is often skipped in the press to move on to new work. Nonetheless, a few hours spent digesting the lessons learned from a project can pay large dividends in estimating future projects. If you have preserved your original estimates in the database, and have entered the actual effort/expense, you can quite easily classify each tile using the difference. This will help show any patterns. Were certain tiles more difficult than anticipated? Does the sequence of work indicate a substantial learning curve effect? Should your labor standards be adjusted for this kind of project?

This approach to project management using ArcView and standard data base tools has evolved over several projects. We expect to grow it further, responding to the unique requirements of future projects. This may include more automated reporting, and the use of ArcIMS to publish project status over an intranet to all interested parties.

I hope this talk has sparked some new ideas for using ArcView in your future projects. Other tools, including spreadsheets and statistical analysis, are also important, as are the mind-numbing CPM/Gantt billboard things. I hope you will consider using the power of ArcView GIS to manage your next project. After all, if it�s good enough for solving client problems, it should be part of our arsenal as well.