Hawaii Statewide GIS Digital Data Standards and Guidelines (First Revision)

State of Hawaii, Office of State Planning and Information and Communication Services Division, Department of Budget and Finance, March, 1993

Maile

I. Introduction

II. Data Automation

III. Quality Control Measures

IV. Documentation

V. Directory/File Structure

VI. AML Standards

VII. Data Output Specifications

VII. Appendixes

I. Introduction

The purpose of these standards and guidelines is to promote the compatibility and interchange of digital spatial data among the users of GIS in the State of Hawaii. Digital spatial data standards are important to promote the development of a high quality, well documented GIS database. These standards and procedures will provide guidelines for State agencies in acquiring, developing and processing data. They will also ensure a higher confidence level to managers making decisions based on GIS data.

The following "general" standards are not specifically addressed in this document, however, they should be followed.

II. Data Automation
1. Source Data

Source maps should meet the minimum mapping requirements as set forth by the USGS in the National Map Accuracy Standards (NMAS).

The National Map Accuracy Standard states ... "for maps at publication scales larger than 1:20,000, not more than 10 percent of the points tested shall be in error by more than 1/30 inch, measured on the publication scale; for maps on publication scales of 1:20,000 or smaller, 1/50 inch. These limits of accuracy shall apply in all cases to positions of well defined points only. Well defined points are those that are easily visible or recoverable on the ground, such as the following: monuments or markers, such as bench marks, corners of large buildings or structures (or center points of small buildings); etc." (For a complete description see Appendix 1.)

Maps produced by the USGS meeting the NMAS requirement can be identified by this statement in the legend: "This map complies with the National Map Accuracy Standard".

For regional land based analysis, the established base layer is the 7.5 minute quadrangles in the form of Digital Line Graphs (DLG). Therefore, scales at or near 1:24,000 shall be the primary base scale for input into the State GIS database. Agencies may use smaller scales if deemed appropriate for the project and its intended analysis. However, it should be noted that there will likely be discrepancies in the registration of layers as one deviates from the base layer. This data may be inserted into the State Library.

If possible, only source maps which meet the NMAS and those that are in good condition (preferably originals or archival copies) should be used. If a source map meeting these requirements cannot be obtained, it is recommended that source data be drafted onto base maps which meet these standards, or onto a transparent overlay which has been punch registered to an appropriate base map (Contact OSP or ICSD).

For local or municipal land based analysis, scales of 1:12,000 or larger shall be the primary base scale for input into the State GIS database. This data may be inserted into the Island libraries.

Large scale source maps should be in satisfactory condition and have an adequate number of tics (minimum 4) in order to achieve an accurate registration. Data automated at or close to a municipal (large scale) level is targeted for the "Island" libraries. There will be eight island libraries (Niihau, Kauai, Oahu, Maui, Molokai, Lanai, Kahoolawe and Hawaii) containing layers such as the parcels (TMK) and other detailed data sets. The standard projection for the Island - libraries shall be State Plane, zones 1 through 5.

For marine/ocean related analysis, a variety of base scales will be used, from large scales near shore, to smaller scales offshore. This data may be inserted into the Ocean library.

Source maps depicting ocean or marine related data may be of varying scales. Layers such as manganese nodules or seamounts may extend over hundreds of miles of longitude out to the 200 nautical mile Exclusive Economic Zone (EEZ), while detailed information for some layers exist near shore and between the islands. In general ocean/marine related data will be inserted into the "Ocean" library. These maps should also meet the NMAS, be in good condition and have an adequate number of registration tics (minimum 4).

If possible, the most scale-stable media should be used for digitizing/scanning purposes.

Most commonly used media, from most to least desirable:

1. Stable-base original (mylar, stabilene)

2. Contact reproduction from stable-base original

3. Non-stable base paper from stable-base original

4. Source data drafted onto stable-base

5. Non-stable base paper

Note: Maps composed on non-stable based paper, such as blue prints or Xerox, are inherently distorted due to the reproduction process. Non-rectified aerial photographs are also distorted, especially near the edges.

Source thematic data on maps not containing registration tics should be drafted onto base maps containing Latitude - Longitude tics, State Plane tics, or Universal Transverse Mercator grid marks whenever possible.

 

2. Data Capture

2.1 Registration

A minimum of 4 tics at the extremes of the data (i.e. map corners) should be used to register a map.

The Transformation Root Mean Square Error (RMSE) value should be less than or equal to .005 inches. If an approximate RMS cannot be obtained, contact GIS personnel before proceeding.

The registration RMSE value should be less than or equal to .002.

All RMSE values must be recorded in appropriate documentation forms and coverage log files.

Note: Use the appropriate master tic coverage residing on the system for transformation procedures whenever possible. A coverage should be pre-transformed to get an indication of the transformation Root Mean Square Error (RMSE) value prior to digitizing. A higher than normal transformation RMSE value (>.005) indicates a conversion problem which may stretch the output coverage. This may be because the old tics and the new tics do not match the same relative locations. The problem should be corrected before automation.

At some point, a map may need to be registered again to the same digital coverage for another session. Whenever a map is re-registered (try to avoid this by completing the map in one session), a registration RMSE is calculated, which indicates how accurate the tics were digitized relative to their original position. This re-registration RMSE value should be less than or equal to .002. Several attempts should be made to bring the RMSE down to its lowest attainable value because it represents the amount of error which new coordinates will be captured.

Where new tics are to be established, tic locations should be entered through keyboard entry of exact geographic coordinates (i.e. UTM or Longitude-Latitude coordinates). Addition of new tics should be evenly spaced. A tic match tolerance should be set in the tolerance file for a coverage

 

2.2 Digitizing

A map manuscript should initially be digitized in digitizer inches.

Features should be captured using a minimum number of coordinates needed to accurately represent the cartographic feature within 0.010 inches.

A map manuscript should be digitized in one session and or kept on the digitizer board until finished, if possible.

Discreet digitizing is highly recommended over "spaghetti" digitizing to ensure greater accuracy.

Note: In spaghetti digitizing, intersections are not explicitly identified as arcs. The set of arcs are digitized one over the other much like spaghetti. This method is typically used to define predominantly straight lines, such as outlines, grids and land use data. Since this style is usually not as accurate as discreet digitizing, spaghetti digitizing is not recommended. Explicitly marking each intersection with a node provides greater positional accuracy.

Points should be entered by geographic coordinates, if available. When manually digitizing points from a source map, enter the exact center of the point or map symbol.

 

2.3 Coincident Features

Digitizing coincident features must be avoided.

Many categories of data can be found in the base layer Digital Line Graphs (DLGs) and may be extracted and used in the creation of new coverages/layers. The coastline layer is an example of a common template for the island outlines which can be added to a new layer. To avoid conflation problems (sliver polygons), use all or part of the coastline template and other features from the DLGs, which are coincident to the features being created.

Note: A coding system has been devised to help identify arcs from different sources. An item FLAG (1,1, I) should be defined in the coverage arc attribute table (AAT). Arcs can be given numeric values in the FLAG column to identify their purpose or source. The codes are as follows:

digitized arcs = O

extracted arcs = 1

closure arcs = 2

coastline arcs = 3

other = 9

A scheme such as this may help to update maps if new source maps become available, or to create valid topology. For example, even though an arc may be missing from a source map, it must still be added to close a polygon. If it is coded with 2, this arc (and others) may easily be found and replaced when the missing data are resolved on the source map. Also, all but one set of coastline arcs can be suppressed when plotting many layers. This will prevent over-plotting.

 

3. Digital Tolerances

A tolerance file containing explicit values for fuzzy, dangle and tic match tolerances must be established for all coverages after automation.

The TOLERANCE command should be used to establish a maximum tolerance value (RMSE) for map registration and processing. The commands CLEAN, BUFFER, and all overlay commands require fuzzy and dangle length tolerances as inputs. If these values are preset in a tolerance (TOL) file, they will be used as defaults. Explicitly setting tolerances will help define the resolution of a coverage and ensure an accurate tic registration. The values are set in coverage units. (See Appendix 4. for suggested maximum allowable tic match tolerances.)

 

3.1 Fuzzy Tolerance

Fuzzy tolerance should be less than or equal to .002 digitizer inches at the scale of the map manuscript.

The effect of the fuzzy tolerance parameter when specified in the CLEAN command is to snap together two or more arc or node coordinates which fall within the specified distance.

The formula to calculate a fuzzy tolerance (F. T.) to .002 at a given scale is:

Example: To create topology for a coverage which has been input at 1:24,000 using ARC/INFO's CLEAN command with a specified fuzzy tolerance of .002 inches. (The coverage unit is in meters for which there are 39.37 inches per meter).

(24,000 / 39.37) * .002 = 1.219 fuzzy tolerance (meters)

In the CLEAN command, specify the fuzz_tolerance parameter to be 1.219 meters.

Note: The .002 inch tolerance is the resolution of the digitizer and the approximate line width of the finest pen.

Caution: Because the CLEAN command may shift arc coordinates (a situation known as fuzzy creep), it is recommended that the BUILD command be used instead to construct or reconstruct topology. The CLEAN command should not be used more than once. Never use a default fuzzy tolerance!

 

3.2 Dangle Length

When digitizing in inches, dangle lengths should be no longer than 0.10 inch.

Although dangles will vary, none of them should be longer than 0.10 inch when digitizing. In the CLEAN command, the dangle length is the minimum length allowed for dangling arcs in a polygon coverage. When specifying a dangle distance in the CLEAN command set the dangle_length parameter just slightly longer than your longest dangle, or 0.11 inches.

Note: It is recommended that CLEAN not be used due to the possibility of shifting arcs. An alternative method is to intersect arcs in ARCEDIT first, then select and delete unwanted dangles which are less than or equal to the longest dangling arc. (Make sure only unneeded arcs are in the selected set before deleting!)

 

3.3 Node Snap Distance

When digitizing at an input scale of 1:24,000, the snap distance should generally be no greater than 0.02 inch or the equivalent distance in coverage units.

The effect of specifying a node snap distance of 0.02 inches is to insure that a new node falling within this distance is snapped to an existing node. (When coverage units are in meters, this distance is equivalent to 12 meters; when units are feet, 40 feet.)

 

3.4 Weed Tolerance

Generally, the weed tolerance should be set to .002 digitizer inches to ensure accurate feature representation.

The effect of setting the weed tolerance distance at .002 is to prevent new vertices from being placed within .002 inches of an existing vertex. This relatively small distance allows for an accurate representation of curves. Adding too many vertices, however, will increase the size of the coordinate file and decrease disk space availability. Use your discretion. Only enter enough vertices to accurately represent the cartographic feature within the 0.010 inch accuracy limit, described below.

 
4. Cartographic Accuracy

Positional accuracy should be as follows:

The 0.010 inch interval is equivalent to a standard 0.010 plotter pen width. When a proof hardcopy plot of a digital map is overlaid on the original base map, discrepancies will be seen as an open space between the plotted feature and the original source map.

 

5. Attribute Coding

5.1 Item Definitions

The Hawaii State GIS Database Design should be consulted for item definitions in a new thematic layer. If a new layer is not identified in the Database Design document, or if there are questions relating to item definitions, please contact OSP/ICSD staff.

Items widths should be kept as "narrow" as possible in order to ensure efficient processing and storage. Layers containing a large amount of items may be utilized more efficiently by keeping them in separate related files. Use B (binary) or F (floating decimal) data type whenever possible. When devising a new item scheme, allow for as many foreseeable uses of the data as possible so that they may be used individually or aggregated as needed.

Item definitions must be consistent from coverage to coverage within a layer.

Item names should be unique from Iayer to Iayer.

 

5.2 Attribute Integrity

Attribute values must be 100'% correct when verified against source map attribute values, or compared with a list of source attribute values.

 

6. Map Coordinates

6.1 Universal Transverse Mercator

Universal Transverse Mercator (UTM), Zone 4, is the projection used in State library.

The units are meters. The projection parameters used when converting from Geographic coordinates (degrees, minutes, seconds) to UTM (meters), zone 4 are as follows:

 

6.2 Hawaii State Plane Coordinate System

The Hawaii State Plane Coordinate system will be the map projection of the Island libraries.

Units will be in feet. The following is an example of projection parameters (for Oahu) when converting from UTM to State Plane:

 

6.3 Albers Conic Equal-Area Projection

Data residing in the Ocean library will be in the Albers conic equal-area projection.

The units will be meters. (Albers parameters to be identified)

 

6.4 Coordinate Conversion

Newly automated coverages should be digitized in inches, verified, and then converted (transformed) into the target projection.

Conversion from one projection, or coordinate system, to another is performed using the PROJECT command in ARC/INFO with the appropriate projection parameters. Usually, parameters are input via projection files, which reside on the system. Currently, all the data on the system is using North American Datum, 1927 (NAD27). All data converted to the Universal Transverse Mercator projection is stored in Zone 4.

 

7. Edgematching

Coverages must be accurately edgematched to adjoining coverages.

Where an exact match cannot occur, arcs must be matched to within 0.010 inch, centerline to centerline.

Confine edgematching to a narrow band which is not more than 10% percent of the width or height of the map, whichever is less.

The joining of data sets should not degrade the quality of the data. Rubbersheeting which alters data into the interior of the map in a non-rigorous, non-algorithmic way must be avoided. Confine edgematching adjustments along a band at the edge of the map sheet in a rectangle. Use National Map Accuracy Standard (NMAS) of .02 inch for 1:20,000 scale or smaller as the maximum match tolerance for joining edge features. In cases where an adjustment cannot meet these conditions, no adjustment shall be made, rather, a straight line shall be added to join the appropriate end points along the edge. These closure lines should be coded as 2 in the AAT under the item FLAG.

 

8. Spatial Topology

Data submitted to the Hawaii Statewide GIS shall be topologically clean and free of error.

A topologically clean coverage will contain:

III. Quality Control Measures
1. Testing for accuracy

Transform an empty coverage to test positional accuracy of tics before digitizing features.

Positional accuracy of features must be tested with verification plots after automation.

Attribute values should also be plotted with features at a legible scale and verified against the source map, or printed and checked against the digital database.

A final plot of the digital map, or a legible verification plot, as well as a printout of its attributes should be kept on file as reference.

The accuracy of attribute values must also be tested by comparing them to source data.

An accuracy rating for each layer must be provided in the layer's documentation, as well as a description of the rating method used.

The type of accuracy test performed, a description of the method used, and the result of the test must be indicated in the Iayer's documentation.

The specification of accuracy and the extent to which that accuracy is assessed is subjective. Several factors will determine how accurate the data must be and the rigor of the tests performed. How the information will be used, the consequences of inaccuracies and project constraints, such as costs and time limitations, can all play a role in evaluating the degree of testing.

The cost of accuracy assessment must be weighed against the benefits of the accuracy information. The assessment method used to test a layer's accuracy should be based on its intended use. Where consequences of error are less critical, verification plots and an assignment of an accuracy level (rating) may suffice without any further testing. For other layers, it may be important to report an accuracy measurement which indicates the likely error for an individual point and also includes a level of confidence. An effective test to model the probability of error in spatial data is the normal distribution, as described below in 1.2.

 

1.1 Verification Plots

Positional accuracy of features must be tested by overlaying a plot of the digital data in inches with the source map from which it was digitized.

A proof hardcopy of the digital map must be plotted in inches prior to transforming the coverage into its final projection. When a proof plot is overlaid on the original base map, discrepancies will be seen as an open space between the plotted feature and the original source map. If more than 10 percent of the total features are found to be more than 0.010 inches from the centerline of the source map features, then they must be re-digitized. All features found to be more than 0.020 inch away from source map features must be corrected. A pen size of .25 mm or .010 inch must be used. A light table is recommended to facilitate verification

 

1.2 The Normal Distribution

Where consequences of error are critical, a more rigorous test, such as a normal distribution model, should be performed to indicate probability of error.

The normal distribution mathematical model has been shown to be a good predictor of error distribution for digital spatial data. To model the normal distribution, the average positional errors must be found for a set of test points. Test points should be easily verifiable (i.e. road intersections, corners of large buildings, etc.) and must be verified against an independent source of higher accuracy, such as field verifications. The variation of error values for those points must be determined using the standard deviation. The standard deviation is then incorporated into the normal distribution model.

To quote an accuracy measurement of a data set, a confidence level must be chosen. The higher the level of confidence is, the lower the accuracy will be. For example, at a confidence level of 80%, the predicted error of a data set might be 1.75 meters. But at 95%/0, the predicted error may be 2.15 meters. This last statement means that 95 percent of the time features will be within 2.15 meters of their true position and 5 percent of the time, features will be more than 2.15 meters away from their true position.

 

2. Other Quality Control Measures

2.1 Tic Registration

If a transformation RMSE value is higher than .005, additional measures should be performed to lower the RMSE before proceeding.

Several steps can be performed to lower this value and/or increase positional accuracy:

 

2.2 Digitizing

Additional quality control steps should be taken to ensure a high degree of accuracy during automation.

IV. Documentation
1. Lineage Report

The accuracy, processing history, and lineage of a layer must be recorded at the time of data capture, and must be available to other users in the form of a Lineage Report for evaluation of the data. This report will be attached to the database.

Existing data which were captured prior to establishment of these procedures for lineage reporting and data quality reporting, must be identified as such. In such cases, lineage and quality estimates should only be made when there is some degree of certainty and confidence in this information. Estimated lineage items should be identified as "estimated". Unknown lineage and quality parameters must be listed as "unknown". Any database merging data from more than one source should identify those sources by providing a lineage reference on each one used. (See Appendix 6. and 7. for Lineage Report terms and example.)

 

2. Layer Summary

Each layer of data collected shall have a Layer Summary file attached to the database.

Each user who collects one or more databases will develop and maintain a layer summary form for each layer collected to be attached to the database. This form will describe or provide a reference for the classification, attributes, and attribute coding scheme for each database. It will include item name, input width, output width, data type, number decimals (if appropriate), and other related information. (See Appendix 8. for an example of a Layer Summary form.)

 

3. Digitizing Log

A digitizing log should be maintained for each automation project.

A digitizing log book should be kept near the digitizer station and filled out during and after each "session". It should contain digitizing status, RMS error for each coverage, and any problems experienced during automation.

V. Directory/File Structure

Note: The following section is currently being reviewed by the System Migration sub-committee and is likely to change partially due to the conversion to the HP UNIX platform.

1. Map Libraries

There are 14 planned map libraries in the Hawaii State GIS database. The names of the libraries are: the Island libraries: Niihau, Kauai, Oahu , Maui, Molokai, Lanai Kahoolawe and Hawaii; the Census libraries: (tiled by county) Kaucen, Oahcen Maucen and Hawcen; and the State and Ocean libraries. Generally, within each library, layers have a similar resolution, map coordinate system, and coverage type. (There may be some exceptions to these rules.) Access to the libraries are read only. Layers under development, or those which are small in volume will not be inserted into a library.

Census Library

Each census library has the geographic extent of a county and is partitioned, or tiled, by the county boundary. Oahcen (City and County of Honolulu) includes the northwestern Hawaiian Islands. Maucen covers Maui, Molokai, Lanai and Kahoolawe, and Kaucen encompasses Kauai and Niihau. Hawcen includes the Big Island.

The map coordinate system of the Census Library is Universal Transverse Mercator (UTM). All the data are stored in zone 4. Units are meters. The datum is North American Datum, 1927 (NAD27). The Census layer is a composite of DIME/TIGER and DLG data developed by the US Census bureau and the USGS.

 

State Library

The geographic extent of the State Library covers all of the eight major islands east to west and north to south. The library is partitioned, or tiled, using the USGS quadrangle boundaries which are mostly 7.5 minutes latitude by 7.5 minutes longitude. The quad boundaries and quad corner tics are contained in an index or master tic coverage. The tic coverage is used to register the USGS 7.5 minute or 15 minute quadrangles and other USGS series maps with latitude/longitude grid tics. The map coordinate system is Universal Transverse Mercator (UTM). All the data is stored in zone 4. The datum is North American Datum, 1927 (NAD27). Units are meters. (See Appendix 3. for diagram).

The State library contains the USGS Digital Line Graph (DLG) data files. These were collected mostly at 1:24,000 scale and cover three main themes: transportation, hydrography and political/administrative boundaries. A geographic names (GNIS) layer is included. Also in the State library are the Landcover, Landuse, and Ownership (GIRAS) layers. They were also digitized by the USGS at an input scale of 1:100,000. There will be many other thematic layers inserted into this library. (See database listing for description of other layers.)

Note: When inputting or accessing an area, or point, using UTM coordinates from a USGS quad map, care must be taken to ensure that they are projected into Zone 4. Officially, Zone 4 ends at the meridian extending through 156 degrees west longitude, or the eastern edge of the 1:24,000 quadrangles Makalawena and Keahole Point (Hawaii). Coordinates taken from a point east of this line are zone 5 coordinates, however, in order to reference a location in the database, zone 5 coordinates must first be projected to zone 4. It was felt that all of the Island of

Hawaii could be stored in Zone 4 without suffering unacceptable distortion, therefore, the entire extent of the State Library database is kept in UTM, Zone 4. This avoids partitioning problems and repetitious conversion tasks.

Island libraries: Niihau, Kauai, Oahu, Maui, Molokai, Lanai, Kahoolawe, and Hawaii

The geographic extent of each Island Library will cover one island. These libraries shall be partitioned, or tiled in accordance with the USGS 7.5 minute quad boundaries and are further subdivided into four 3.5 minute by 3.5 minute quadrants of equal size. They may be even further subdivided into 3/4 minute areas in urban areas of high density. The eight Island libraries will use the projection of the Hawaii State Plane Coordinate system. Each island has its own State Plane zone number, except for Lanai, Molokai and Kahoolawe which share the same number as Maui. Units are in feet. (See Appendix 3. for diagram).

Island libraries

Island

Arc/Info Zone

State Plane Zone

Niihau

5976

Zone 5

Kauai

5951

Zone 4

Oahu

5926

Zone 3

Maui (includes Lanai, Molokai and Kahoolawe

5901

Zone 2

Hawaii

5876

Zone 1

Data automated at, or close to, a municipal (large scale) level, such as the TMK layer, will reside in the detailed Island map libraries.

 

Ocean Library

The geographic extent of this library will cover hundreds of miles from the shoreline out to the 200 nautical mile Exclusive Economic Zone (EEZ). It will be partitioned, or tiled, in 2 degree increments in the outer areas to accommodate layers with far reaching or sparse data. Nearshore and channel areas are further subdivided to reflect more detailed data. The smaller subdivisions are modeled after near shore fish catch statistical areas. Because of the wide range in longitude, the projection Albers Conic Equal Area is used. The coordinate system is meters. In general, layers that are ocean, or marine related, will be kept in this library. (See Appendix 3. for diagram).

 

2. Agency Workspace

Agency workspaces are limited in size, therefore, delete or archive temporary files or coverages on a frequent basis.

An agency needing extra disk space for large projects should contact the Information and Communications Services Division (ICSD) for the appropriate request form.

Clean up sub-directories thoroughly before archiving them.

Base layers, such as the coastline template or tile boundaries, should never be copied (extracted from the library), unless adding to a coverage under development.

Use relative path names to access working files or run AMLs. Work files should not be copied into a public data directory.

The structure of sub-directories within a workspace should be organized by project to facilitate file recognition.

 

3. Data Sub-directories/Files

Only layers which are under development, or those that are too small to be kept in a map library, should be kept in a sub-directory.

File naming conventions recommended by Environmental Systems Research Institute (ESRI) and those adopted by the Hawaii State GIS should be followed. (See Appendix 2. for list - subject to change after migration).

"Readme" files may contain informative or procedural aspects of a particular layer, or may warn against a particular usage. These should be read before working with the data.

The directories, DISCLAIMER, LEGEND, MACRO, and PROJECTION may be provided on the system to group commonly used files. They are for general use and should not be altered.

Only macros which meet AML standards, and have been approved by the Information and Communication Services Division (ICSD) may be inserted into the public MACRO directory.

 

4. Naming Conventions

Coverages under development should be named to identify their data content and be easily recognized by the user.

Initial and processed coverage names should conform to standardized naming conventions recommended by ESRI. (See Appendix 2. for list).

Intermediate coverages that are generated during processing should be named so they are clearly identified as the most current coverage.

The first letter of a file must be an alpha term. It is recommended that coverage names be limited to six to eight characters, and not contain any extensions.

VI. AML Standards
1. Macros

A header should be included at the top of an AML which describes its functionality, the called and or calling AMLs, the arguments being passed to the AML, the date, and the author. (An AML template is provided in the MACRO directory).

General programming concepts, such as the use of generic code and modularity, should be followed to provide easier maintenance, modification and reusability.

Other AML standards, such as error handling, passing arguments and global variables, should also be followed. (See AML standards in Appendix 5.)

2. Application Programming

If an application is deemed necessary, consult with ICSD for information on the availability of code, programming support, or general advice.

An application should follow both AML standards and application programming standards, such as those recommended by ESRI and the Hawaii State GIS.

VII. Data Output Specifications
1. Data Transfer Format

(to be determined)

2. Archive Format

(to be determined)

3. Map Output

A plotted map must have a textual clause, or disclaimer, which states the original intent of the data, or warns about the map's usage. It must also include the plot date, the agency which composed the map, the data sources, and the latest revision of the database.

Other map elements which may be included optionally, are:

Note: A LEGEND directory groups together coverages such as scalebars, north arrows and the State Seal and is for general use. The PROJECTION directory contains various projection parameter files to convert coverages from one projection to another. The DISCLAIMER directory contains common text clauses and other disclaimers used by various agencies.

VIII. APPENDIXES
Appendix 1: National Map Accuracy Standards

With a view to the utmost economy and expedition in producing maps which fulfill not only the broad needs for standard or principal maps, but also the reasonable particular needs of individual agencies, standards of accuracy for published maps are defined as follows:

1. Horizontal accuracy. For maps on publication scales larger than 1:20,000, not more than 10 percent of the points tested shall be in error by more than 1/30 inch, measured on the publication scale; for maps on publication scales of 1:20,000 or smaller, 1/50 inch. These limits of accuracy shall apply in all cases to positions of well-defined points only Well-defined points are those that are easily visible or recoverable on the ground, such as the following: monuments or markers, such as bench marks, property boundary monuments; intersections of roads, railroads, etc. ; corners of large buildings or structures (or center points of small buildings); etc. In general what is well defined will also be determined by what is plottable on the scale of the map within 1/100 inch. Thus while the intersection of two road or property lines meeting at right angles would come within a sensible interpretation, identification of the intersection of such lines meeting at an acute angle would obviously not be practicable within 1/100 inch. Similarly, features not identifiable upon the ground within close limits are not to be considered as test points within the limits quoted, even though their positions may be scaled closely upon the map. In this class would come timber lines, soil boundaries, etc.

2. Vertical accuracy, as applied to contour maps on all publication scales, shall be such that not more than 10 percent of the elevations tested shall be in error more than one-half the contour interval. In checking elevations taken from the map, the apparent vertical error may be decreased by assuming a horizontal displacement within the permissible horizontal error for a map of that scale.

3. The accuracy of any map may be tested by comparing the positions of points whose locations or elevations are shown upon it with corresponding positions as determined by surveys of a higher accuracy. Tests shall be made by the producing agency, which shall also determine which of its maps are to be tested, and the extent of such testing.

4. Published maps meeting these accuracy requirements shall note this fact on their legends, as follows: "This map complies with National Map Accuracy Standards"

5. Published maps whose errors exceed those previously stated shall omit from their legends all mention of standard accuracy.

6. When a published map is a considerable enlargement of a map drawing (manuscript) or of a published map, that fact shall be stated in the legend. For example, "This map is an enlargement of a 1:20,000-scale map drawing," or "This map is an enlargement of a 1:24,000-scale published map.

7. To facilitate ready interchange and use of basic information for map construction among all Federal map-making agencies, manuscript maps and published maps, wherever economically feasible and consistent with the uses to which the map is to be put, shall conform to latitude and longitude boundaries, being 15 minutes of latitude and longitude, or 7.5 minutes, or 3-3/4; minutes in size.

U.S. Bureau of the Budget - Issued June 10, 1941, Revised April 26, 1943, Revised June 17, 1947

Appendix 2: Naming Conventions recommended by ESRI

Layer Abbreviations

Abbreviations

Sequence Number

CB = Corporate Boundaries

AP = Append

00

CF = Cultrual Features

AR = Arcplot

to

CL = Course Lines

BF = Buffer

99

CT = Census Tracts

CN = Clean

EL = Elevation

CP = Clip

FL = Fault Lines

CY = Copy

FP = Flood Plains

CR = Create

GL = Geology

DG = Digitize

GP = General Plan

DL = Dropline

HD = Hydrology

DS = Dissolve

IN = Infrastructure

DT = Deletetic

LU = Land Use

ED = Edit

MB = Module Boundary

EL = Eliminate

OP = Ownership and Plans

GN = Generalize

OW = Ownership Only

GA = Gridarc

PL = Public Lands

ID = Identity

PP = Plans Only

IN = Intersect

RL = Ridge Lines

LM = Labelmap

SD = Service Districts

LT = Labeltable

SF = Special Features

LG = Linegrid

SL = Slope

MN = Matchnode

SO = Soils

PT = Pointgrid

SR = Sub Regions

PG = Polygrid

TD = Telephone Districts

PR = Project

TO = Topography

RS = Reselect

TU = Terrain Units

TR = Transform

TZ = Traffic Zones

UN = Union

VG = Vegetation

UP = Update

WS = Well Sites

DN = Densify

WT = Watersheds

ZN = Zoning

Naming Conventions: Normally 6 Digits

Example of File Naming Conventions Used at OSP:

FILE TYPE

EXTENSION

Composition

XXXX.cmp

Plot

XXXX.plt

Rotated PLT

XXXX-r.plt

Text

XXXX.txt

Document

XXXX.doc

AMLs

XXXX.aml

Watch

XXXX.wat

Como

XXXX.cmo

Menu

XXXX.menu

Data

XXXX.dat (unless files have specific extensions, such as DXT or DLG files)

Projection

From_To.prj

Line Key

XXXX.lkey

Shade Key

XXXX.skey

Marker Key

XXXX.mkey

Shadeset

XXXX.shd

Lineset

XXXX.lin

Markerset

XXXX.mrk

Textset

XXXX.txtst

Composition parameter files

XXXX.par

Other Coverage Naming Conventions:

Coverage Type

Name

(currently usable, development status pre-final)

pre-final: features not verified or needs editing

XXXX-pf1

pre-final: attributes not verified or need normalizing

XXXX-pf2

pre-final: low quality or doesn't meet standards

XXXX-ssd

(currently usable, development status final)

final: may be inserted in library if appropriate

(isl)XXXX

Appendix 3: Library Partition Diagrams

not available

Appendix 4: Suggested tic match tolerances (RMSE) for TOL files.

Initial map scale tic match values for Digitizing Metric units U.S. equivalent

Tic match values

Tic match values

Initial map scale for Digitizing

Metric units

U.S. equivalents

1:1,000,000

Millimeters = 0.127

Inches = 0.005

Meters = 127.000

Feet = 416.667

1:500,000

Millimeters = 0.127

Inches = 0.005

Meters = 63.500

Feet = 208.333

1:250,000

Millimeters = 0.127

Inches = 0.005

Meters = 31.750

Feet = 104.167

1:100,000

Millimeters = 0.127

Inches = 0.005

Meters = 12.700

Feet = 41.667

1:63,360

Millimeters = 0.127

Inches = 0.005

Meters = 8.047

Feet = 26.400

1:50,000

Millimeters = 0.127

Inches = 0.005

Meters = 6.350

Feet = 20.833

1:24,000

Millimeters = 0.127

Inches = 0.005

Meters = 3.048

Feet = 40.000

1:12,000

Millimeters = 0.2167

Inches = 0.0083

Meters = 2.6004

Feet = 8.333

1:6,000

Millimeters = 0.2167

Inches = 0.0083

Meters = 1.3002

Feet = 4.165

Suggested tolerance values are one fourth of the acceptable error described in the U.S. National Mapping Standards of the Office of Management and Budget. More information on National Mapping Standards can be obtained-from the USGS National Cartographic Information Centers. Dial I 800-USA-MAPS.

Appendix 5: AML Coding Standards

ESRI: Suggested AML Coding Standards

System Considerations:

Dependencies:

System dependencies such as path names to AML programs, menus and data sets, should be isolated and well documented, and they should be kept in the driver AML which controls the operation of the application system.

Limitations:

Programmers should be aware of the limitations of the Operating System as well as ARC/INFO.

In UNIX System V:

  • All names (files, directories, AMLs, menus, etc.) should be no longer than 14 characters.
  • Coverage names including extensions should be no longer then 13 characters

In ARC/INFO:

  • Map compositions and coverages are like directories, and their names should not have extensions.
  • File names should not contain non-alphanumeric characters except for '-' or '$'.
  • Pulldown menu columns should have no more than 22 choices, and be no wider than 32 characters.
  • Form menus should contain no more than 17 lines of text, including blank lines, to accommodate 24-line ASCII terminals.
  • All files should be 80 columns wide so that they can read by both Graphic and ASCII terminals.
  • Refer to Appendix B of the AML User's Guide for other menu limitations.

Modularity:

AMLs should be written as stand-alone modules.

Coverage names and feature types used throughout the application should be assigned once in the driver AML and be passed on to the other macros.

Graphic Environment:

All information needed to set the graphic environment should be written into a station file.

Applications that display graphics and use menus should state the &STATION directive in the driver AML. The station file to be used will then be specified as a required argument to the execute the driver AML.

File Names:

AML file names should include a .AML extension.

Menus should include a .MENU extension.

File names should describe the functionality of the AML or MENU.

Other Coding Considerations:

Functions that are going to be repeated more than once should be confined in a separate AML, or performed with &ROUTINE.

Do not leave an &DO, &SELECT, or &IF block with &GOTO. &RETURN or &CALL may be used to exit from these conditional blocks.

When exit from the application, users should be in the same workspace where they started the application.

All AMLs should end with &RETURN.

Internal Documentation:

Program Header: All programs should include a program header which identify the program, its purpose, program calls, and variable descriptions.

Comments:

All functional blocks of codes should have a comment briefly describe their functionalities.

In-line comments should describe each significant operation performed by the program, and identify all unusual procedures used.

Should leave one blank comment line between the comment and the block of code it is documenting.

Comments should be written in lowercase for readability.

In-line comments should follow the indentation of the code, and should be used to identify an &END in long sequences.

Comments should be specific to the program and its functions .

Comments can also be specified inside the IF/THEN/ELSE blocks to describe the different conditions .

Variables:

Variable names should be specific to the values they represent. For example, the variable setnum should not be set to a character.

Variable names should not be cryptic (e.g., &args cover more descriptive than &arg input).

Document all variables at the point of assignment.

Global variables should begin with common characters so that they can be easily deleted using the &DELVAR directive.

Coding (Blocking):

Coding (Indentation):

Coding (Case Conventions):

Coding (Error Handling):

Coding (Input Checks):

Menus and User Interface:

Prompts:

The wording of prompts should be clear and concise, and should indicate what type of response (a number, a letter, or a word) is expected from the user.

Don't mix prompts that require negative and affirmative responses to get the same results. (e.g. don't use Do you Want to continue? and Do you want to quit? interchangeably).

Carriage returns should be required either after all responses to system prompts, or else after none.

If [QUERY] or [RESPONSE] is used, always have a default value if <CR> is entered. If this is not possible, then be sure to trap for a [NULL] response.

Avoid using computer jargon (workspace, attach, directory, etc.) in prompts and other messages.

Avoid using unnecessary prompts. For example, ID codes or passwords that may need to be checked many times during a session should be accepted at the start of the session, and then stored in a variable that can be accessed later in the session.

When prompting a user for a new setting for a parameter, like a terminal type or a plotter queue, display what the current setting is, and interpret a null carriage return as 'Do not change'.

When a user chooses an option that could potentially cause a loss of work or data, verify that the user really wants to do what they have requested, and provide a way for them to 'bail out'.

When time-consuming processes are being executed, provide messages at appropriate points to let the user know what's going on.

Menu Design:

Menus should be designed and organized in a logical manner to produce an effective user interface.

Minimize the number of menus a user has to pass through to perform a typical task. Avoid having more than three nested menus; two is preferred maximum.

Avoid surprising users by returning them to a menu other than the one from which they came.

Menus should be neatly designed and programmed.

Options that are repeated on different menus should be position in the same location on all menus in which they appear.

Help screens should be available for each menu, and they should list the menu options available with a brief (one or two sentences) explanation of what each option does.

Menus and AMLs should be modularized so that in case there's problem with one of the system options, the option can be isolated while the rest of the system is operational.

Submenu titles should correspond to the options on the main menu.

Upper- and lowercase letters should be used in prompts and menu options.

Ellipses (...) should be used to indicate that a menu pick will invoke another.

Arrows should be used in sidebar menus to indicate that a menu pick will display a subset of choices.

Form Menus:

The first line of the menu should contain a description of the menu's purpose. This description should start with a verb, which is not third person singular (e.g. 'Intersect' rather than 'Intersects'; 'Draw' rather than 'Draws').

There should be a blank line between the description and the main body of the menu.

The main body of the menu should contain input fields, display fields, and buttons.

Input fields should be left justified and preceded by a brief description of what is to go into that field. The description should be right justified and is followed by a colon (:) to indicate that the field can take input from the user, it should also be in lowercase except for the first letter of the first word.

All input fields should provide a help message if an invalid input data type is entered.

Should provide instructions for input fields that provide a matrix menu of choices.

Buttons should be in uppercase. There are three standard buttons that should be included in most form menus: OK, HELP, and CANCEL, and they should appear at the bottom of the form menu, with one blank line between them and the main body of the menu, and two blanks between each button.

 

Matthew E. Gabriel, TGS Technology, Inc.: AML Coding Standards: A Tool For Quality

The following standards were written for AML in ARC/INFO version 5 and do not yet address AML in ARC/INFO version 6:

Program Header:

Program Commenting:

Blank Lines:

Case:

Abbreviations:

Indentation:

Command Line Verification:

Input Validation:

Input Processing:

Error Trapping:

Temporary File Naming Convention:

System Dependencies:

System Limitations:

Use of rare items such as large monitor screen sizes and screen dump printers should be offered as program options rather than default.

From Customizing ARC/INFO with AML - REV 6:

Program Structure:

Should avoid using &GOTO statement as a method to drop out of a loop or to transfer control of the program.

Calls to AML Routines:

Local routine accessed only by the current AML should be used when a substantial set of code is used more than once in an AML.

External routine should be used when a substantial set of code is used by other AMLs independently.

Avoid creating large numbers of small or fragmented external AML routines.

Variable Conventions:

Should be given descriptive names.

Should avoid the use of global variables.

Leave things the way they are found:

Return environmental parameters to their original state after performing a specific task.

AMLs and Batch:

AML must provide the option to be run in batch if it has a long execution time.

A COMO file (PRIME) or watch file must be specified so that the user can verify if the AML ran correctly.

Use of the date functions in AML at the beginning and end of the AML is suggested to allow the user to track the run time for the AML.

Appendix 6: Explanation of Lineage Report Terms

Coverage description and documentation (draft 2-25-93)

Data Description:

NAME: Name of layer or coverage

LIBRARY: Library name in which layer is located.

LOCATION: Path name to coverage not residing in a library.

DATA TYPE: Type of data found within the coverage/layer. Possible choices are:

CONTENT: Brief description of layer/coverage contents.

DATA EXTENT: Description of the total area data covers; i.e, all major Hawaiian islands, etc.

PROJECTION: Geographic projection of coverage/layer.

UNITS: Map units of the geographic projection used; i.e., meters, feet, etc.

ZONE: Zone, if any, of coverage/layer within particular projection.

NOTE: Virtually all of the data in the State library is stored in UTM, Zone 4 coordinates

SCALE: Scale at which coverage/layer was automated

LAST UPDATE: Date of last data update.

STATUS: Availability status of the data. Possible choices are:

RATING: Quality rating of coverage/layer.

Possible choices are:

LIMITATIONS: Limitations of data, regarding its use or interpretation.

DISCLAIMER: Some data may have standard disclaimers that must accompany its distribution.

CONTACT: Person or agency to contact if there are questions about the data or its use.

 

Source Information:

SOURCE DATA: Brief description of the data source; i.e., USGS 7.5 minute quadrangles, Blue line reproductions, etc.

S_QUALITY: Quality rating of source data.

Possible choices are:

PUBLISHED BY: Agency or persons which published source data.

S_YEAR: Year the source data was published.

S_MEDIUM: Medium on which the source data resides.

BASE_MAP: Brief description of the base map from which the source maps were produced.

NOTE: The BASE MAP category is only necessary if the source maps used for automation are reproductions of existing maps; i.e., if coverage data was digitized from blue line reproductions of an agencies original maps.

B.M._YEAR: Year the base maps were published.

B.M._SCALE: Scale of the base maps.

B.M._PROJ: Geographic projection of the base maps.

B.M._MEDIUM: Medium on which the base maps were published.

 

Automation Information:

PROCESSED BY: Agency and initials of person(s) responsible for data automation.

AUT_DATE: Date source data was automated.

METHOD: Method which source data was automated; i.e., digitized, scanned, etc.

SOFTWARE: Software used for data automation.

HARDWARE: Hardware used for data automation.

REVISIONS: Description of revisions made to coverage/layer after automation.

 

DIGITIZING

NODESNAP: NODESNAP tolerance used during digitizing.

WEED: WEEDTOLERANCE used during digitizing.

REG_RMS: Root Mean Square error (RMS) value achieved during registration.

 

TRANSFORM

FRM_PROJ: Projection data is transformed from (digitizer inches, State Plane, etc.)

TO_PROJ: Projection data is transformed into.

PROJ_FILE: The name of any standard projection file used during the transformation process.

TRANS RMS: Root Mean Square error values achieved during transformation process.

 

ADDITIONAL PROCESSING INFORMATION

EDGEMATCH: Method used in matching adjoining coverages, if applicable.

JOINING: Method used to join coverages, if applicable.

ADDITEM: Item description, including item name, input/output widths, and item type, of items added to existing INFO files during automation.

 

TOPOLOGY

# OF CLEANS: Total number of CLEANs run on coverage/layer during automation.

FUZZY TOL.: FUZZY TOLERANCE used with CLEAN during automation.

DANGLE.: DANGLE TOLERANCE used with CLEAN during automation.

 

POST EDITING

NODESNAP: NODESNAP distance used during editing.

WEED: WEEDTOLERANCE used during editing.

 

RELATED FILE INFORMATION

NAME: Name of relation table.

RELATED FILE: Name of related file.

RELATED ITEM: Name of related item.

 

QUALITY CONTROL INFORMATION

METHOD: Method used for quality control checks; i.e., visual, plot overlays, etc.

VERIFIED BY: Agency or persons verifying data after automation.

VER DATE: Date of data verification.

UPDT SCHD: Schedule of expected updates to data coverage/layer.

NOTES: Any additional information pertaining to the creation or use of the coverage/layer.

Appendix 7: Lineage Report Example

 

THREATENED AND ENDANGERED PLANT SPECIES

(draft 2/26/93)

Coverage description and documentation

Data Description

NAME: (ISL)TEPLNT

LIBRARY: N A

LOCATION: NATRES>FINAL>*VEG

DATA TYPE: Polygon.

CONTENT: Threatened and endangered species concentration boundaries.

DATA EXTENT: Complete coverage of all major Hawaiian islands except Kahoolawe and Niihau.

PROJECTION: UTM

UNITS: Meters

ZONE: 4

SCALE: All islands at 1:62,500 except Hawaii, 1:250,000.

LAST UPDATE: All islands: 3/92

STATUS: Complete.

RATING: O

LIMITATION: This data should be used only as a guideline based upon limited information and further refinement. It illustrates the concentrations of endemic plant taxa which are listed or under review for endangered or threatened status. It is based mainly upon historical collections with some recent observations. NOTE: Individual rare species sometimes grow only within areas that may have an overall low species concentration rating.

DISCLAIMER: All hard copy products which contain this threatened and endangered plant data, or information derived from this data, must contain the information listed above (LIMITATIONS). Such disclaimers are found in the (ISL)PLANT.TXT files in the VEG directory. These files may be added directly to a map composition or plot file by using the TEXTFILE command in ARCPLOT.

CONTACT: GIS staff, Office of State Planning

 

Source Information:

SOURCE DATA: Coverages were digitized off of the State of Hawaii's Department of Forestry and Wildlife's' mylar threatened and endangered (T&E) species maps. T&E data was hand drafted onto the base maps by DOFAW's Carolyn Corn.

PUBLISHED BY: State of Hawaii's Department of Forestry and Wildlife

S_YEAR: 1992.

S_MEDIUM: Mylar.

BASE_MAP: United States Geological Survey's standard map products.

B.M._ SCALE: All islands at 1:62,500 except Hawaii, which is at 1:250,000.

B.M._YEAR: Hawaii: 1944

Maui: 1957

Molokai: 1952

Lanai: 1963

Oahu: 1970

Kauai: Unknown

B.M._PROJ: Polyconic, based on Old Hawaiian datum (see attached).

B.M._MEDIUM: Mylar.

 

Automation Information:

PROCESSED BY: Office of State Planning, SV

AUT_DATE: 2/92

METHOD: Manually digitized.

SOFTWARE: ARC/Info 5.01

HARDWARE: PRIME 4150

REVISIONS: Standard editing revisions only

 

DIGITIZING

NODESNAP: .02

WEED TOL: .002

REG RMS: Unknown.

TRANSFORM

FRM PROJ: Digitizer inches

TO PROJ: UTM

PROJ FILE: PRJ FILE

TRANS RMS:

Hawaii:.002

Maui: .002

Molokai: .003

Lanai: .012

Oahu: .002

Kauai: .013

ADDITIONAL PROCESSING INFORMATION

EDGEMATCH: N A

JOINING: N A

ADDITEM: PAT: CONCEN 2, 2, C Species concentration value:

VH (Very High concentration of T&E species)

H (High concentration of T&E species)

M (Medium concentration of T&E species)

L (Low concentration of T&E species)

O (Little or no T&E species)

AAT: FLAG 1,1, I

TOPOLOGY

# OF CLEANS:

Hawaii: 2

Maui: 2

Molokai:

Lanai:

Oahu: 1

Kauai: 3

FUZZY_TOL.: 1.219

DANGLE.: .02

POST EDITING

NODESNAP: .02

WEED: .002

RELATED FILE INFORMATION

NAME: None.

RELATED FILE: N A

RELATED ITEM: N A

QUALITY CONTROL

METHOD: Visual inspection, overlaying digitized coverages onto originals.

VERIFIED BY: SV (Office of State Planning), and Carolyn Corn (Department of Forestry and Wildlife)

VER DATE: 2/92

UPDT SCHD: No further updates are planned as of 3/92.

NOTES: Source maps provided by DLNR/DOFAW were manually digitized using the ADS program in ARC/Info. Attributes were added interactively.

Information contained on the source maps was reviewed, and maps were visually inspected for obvious errors. Intersections and doughnut polygons were noted.

Each island was digitized in its entirety, one island at a time. Each source map was taped to the digitizing board, and digitized using the ADS program in ARC/Info. A node was placed at the intersection of all arcs, as well as along long arcs to facilitate future editing. All coverages were digitized initially in inches, then plotted to verify digitizing accuracy. After coverages were verified to satisfaction, each island was transformed into UTM coordinates. Coastlines were appended using the GET command in ARCEDIT, and all coastline arcs were coded FLAG = 3. While labels were added interactively at the time of digitizing, concentration values were added only after the coverages had been transformed and topology had been satisfactorily built.

Digitized coverages were plotted out (in inches, at a scale of 1:1). These plots were overlain with the mylar source maps. Digitizing accuracy was visually verified by digitizer (SV) and DLNR's Carolyn Corn (of DOFAW). Non-digitizing discrepancies were noted ands corrected according to DOFAW's instructions.

Coverage topology was built using the CLEAN command in ARC/Info. Every time a CLEAN was run, the 'cleaned' coverage was verified against the 'uncleaned' coverage for any shifting before processing continued.

Transformed coverages containing final attribute data was also plotted out at the source map scale and visually inspected for errors. In addition, attribute values were repeatedly checked in ARCEDIT using the FORMS command. Final coverages were checked with the LABELERRORS command, as well as interactively selecting for all possible coverage values in ARCEDIT (for example, all arcs coded FLAG = 3 were selected and colored, then all arcs coded FLAG = O were selected, colored, etc.).

The Kauai source map had no real world coordinates to use as registration references. Registration tics were created using the existing GIS coastline coverage. An easily identifiable point on the coast was selected in ARCEDIT, for which UTM coordinates were found (using the MEASURE WHERE command). The corresponding points were located on the source maps, and tics were generated at these points.

Appendix 8: Layer Summary Example

HAWAII GIS DATABASE DICTIONARY THREATENED AND ENDANGERED PLANT SPECIES

LAYER SUMMARY

COVERAGE: (ISL)TEPLNT

LIBRARY: N A

LOCATION: NATRES>FINAL>VEG

TYPE: POLYGON

PROJECTION: UTM

EXTENT: All major Hawaiian islands, except Kahoolawe and Niihau.

STATUS: Complete.

DATA SOURCE: All island coverages were digitized from Division of Forestry and Wildlife's mylar threatened and endangered (T&E) plant species maps. The maps were all at a scale of 1:62,500 except Hawaii, which was at a scale 1:250,000.

DATE: March, 1992.

RATING: O

AGENCY: Office of State Planning.

SUMMARY DESCRIPTION: There is one T&E coverage for each island. Each island is divided into distinct zones of T&E species concentration, ranging from 'low' concentration to 'very high' concentrations of T&E plant species. It should be noted, however, that for these particular coverages, concentration does not necessarily reflect the rareness of a particular plan species. In other words, an area designated as having a 'low' concentration of T&E species may include the last known occurrence of a particular plant species.

FEATURE ATTRIBUTE TABLE DESCRIPTION

(ISL)LUDB.PAT

COL.

ITEM NAME

DEFINITION

ALT NAME

DESCRIPTION

13

cover-ID

4,5,B

-

Internal Polygon ID

17

DENSITY

2,2,C

-

T&E Species Concentration Value

FEATURE CODE EXPLANATIONS

DENSITY

T & E SPECIES CONCENTRATION

O

Little or no threatened and endangered plant species.

L

Low concentration of T & E species.

M

Medium concentration of T & E species.

H

High concentration of T & E species.

VH

Very high concentration of T & E species.

OL

O in cane fields, L i gullies and coastal areas.

NOTES: Individual rare species may grow only within areas that have an overall low concentration rating.

Appendix 9: Glossary of Terms (to be inserted at a later date)
Appendix 10: Sources Cited

The University of Rhode Island, The Environmental Data Center, Dept. of Natural Resources Science. Digital Database Standards for the Rhode Island Geographic Information System.

State of Utah, Department of Administrative Services, Division of Information Technology, March, 1992. Utah State Geographic Information Database User's Guide (SGID) The Automated Geographic Reference Center (AGRC).

Division of Information Services, Department of General Services, August, 1991. Standards Guidelines for Geographic Information Systems in New Mexico.

Executive Office of the Governor of Florida, Office of Planning and Budget, Final Report, December, 1990. A Model Geographic Information System for Coastal Zone Management.

Khagendra Thapa, John Bossler, June, 1992. Accuracy of Spatial Data Used in Geographic Information Systems, Photogrammetric Engineering and Remote Sensing, v58, No. 6.

Krogulecki, Mathew, April 1990. A Prototype Decision Guide and Audit Log for Preparation of Spatial Databases, Photogrammetric Engineering and Remote Sensing, V.56, No. 4.

Maki, Bob, June, 1992. Quality Control of Arc/Info Databases Overhead notes from the 1992 A/I User's Conference.

Stadelmann, Mirjam, June, 1992. Implementation of Quality Assurance Procedures for Large Spatial Databases, Overhead notes from 1992 Arc/Info User's Conference.

Environmental Systems Research Institute, Inc., 1990. Understanding GIS. The ARC/INFO Method, 380 New York Street.

Environmental Systems Research Institute, Inc.,1992. Customizing ARC/INFO with AML ESRI Course Workbook.

Environmental Systems Research Institute, Inc., 1992. ARCTOOLS, 12th Proceedings of the 1992 ESRI User Conference, ArcTools Development Team, Environmental Systems Research Institute, Overhead notes.

Environmental Systems Research Institute, Inc., 1992. Application Programming Master Workshop-The ESRI Method, Overhead Notes, 1991 ESRI User Conference.

Environmental Systems Research Institute, Inc., 1988. Digitizer's Handbook, Arc/Info Technical Handouts, 1988 ESRI User Conference.

Environmental Systems Research Institute, Inc., 1988. Coordinate Management, Arc/Info Technical Handouts, 1988 E5RI User Conference.

Environmental Systems Research Institute, Inc., 1988. The Production Process, Arc/Info Technical Handouts, 1988 ESRI User Conference.

Environmental Systems Research Institute, Inc., Jan., 1989. Arc/Info Users Guide, Volume 1, Rev. 5.1.

Environmental Systems Research Institute, Inc., August, 1989. Arc/Info Training Course, Section 5: Spatial Data Automation.

Environmental Systems Research Institute, Inc., May 18,1990. Technical Session notes of the Tenth Annual ESRI User Conference.

United States Geological Survey, Dept. of Interior, May, 1988. "United States National Map Accuracy Standards", USGS Standards for Digital Line Graphs, National Mapping Program Technical Instructions.

United States Geological Survey, Dept. of Interior, 1984. USGS Digital Cartographic Data Standards, Digital Line Graphs From 1:24000-Scale Maps, National Mapping Program, Circular 895-C.

United States Geological Survey, Dept. of Interior, 1987. Digital Elevation Models, Data User's Guide", National Mapping Program Technical Instructions, Data User's Guide 5.

Guptill, Stephan C., 1991. Federal Geographic Data Committee-Working Group, 1991 GIS/LIS Proceedings, vol. 1, p. 381.

The National Committee for Digital Cartographic Spatial Data Standards, draft March, 1992. Spatial Data Transfer Standards, Part 1, Logical Specifications, ver. 3/92.

The National Committee for Digital Cartographic Spatial Data Standards, draft March, 1992. Spatial Data Transfer Standards, Part 2, Spatial Features, ver 3/92.

United States Geological Survey, Dept. of Interior, Oct., 1991. USGS Standards for Digital Line Graphs, Part 3, Attribute Coding, National Mapping Program Technical Instructions, 10/91.

United States Geological Survey, Dept. of Interior, May, 1988. USGS Standards for Digital Line Graphs, National Mapping Program Technical Instructions, 5/88.

United States Geological Survey, Dept. of Interior, May, 1988. USGS Standards for Digital Elevation Models, Open file report 86-004, National Mapping Program Technical Instructions, 5/88.

Federal Geographic Data Committee, June 16-18,1992. Information Exchange Forum on Spatial Metadata, (hosted by USGS).

Marble, Lauzon and McGranaghan, 1990. "Development of a Conceptual Model of Digitizing", Introductory Readings in Geographic Information Systems, ed. Peuquet and Marble, Taylor and Francis, State University of New York at Buffalo.

Strand, Eric J., 1991. A Profile of GIS Standards, 1991-92 International GIS Sourcebook, p. 417.

Strand, Eric J., Sept., 1991. The Missing Link: Data Interchange Services, GIS World, p. 60.

Keating, Robt., June, 1992. Building Accuracy Into GIS, GIS World, p. 32.

George, Randy, 1991. The Spatial Data Transfer Standard Faces Challenges, 1991-92 International GIS Sourcebook, p. 425.

Tom, Henry, 1991. Spatial Information and Technology Standards Evolving, 1991-92 International Sourcebook, p. 422.

Kiernan, Brian D., November, 1991. Quality Control Dictates Conversion Success, GIS World, p. 90.

Fain, Mickey A., 1991. Quality Through Conversion Process Management, (Smartscan, Inc., Colorado) GIS/LIS Proceedings, Atlanta, Georgia, Oct.28 Nov. 1,1991, vol. 1,p. 137.

Garza, Robert; Foresman, Timothy, 1991. Embedding Quality Into County-Wide Data Conversion, (Clark County GIS Management Office), GIS/LIS Proceedings, Atlanta, Georgia, Oct. 28-Nov. 1,1991, vol. 1,p. 130.

Angwin, George T., 1991. Quality Control of Digital Map Generation,, (Etak, 715.

Henefeld, Lou (Bureau of Indian Affairs, Colorado), 1992. Putting Topology to Work: Automated Spatial Data Quality Control Techniques Proceedings of the Twelfth Annual ESRI User Conference, p. 417.

The Oregon State Map Advisory Council, GIS Committee and GIS Plan Working Group, February 15,1990. Geographic Information System Plan,.

Environmental Systems Research Institute, Inc., 1990. Data Standards for Maine Geographic Information Systems, Proceedings of the 10th Annual ESRI User Conference.

Federal Interagency Coordinating Committee on Digital Cartography, Fall 1990. A Summary of GIS use in the Federal Government, Reports Working Group, Fall 1990.

Vermont Geographic Information System (VGIS), Updated April 8,1991.

Policies. Standards Guidelines and Procedures Handbook.

Aranof, Stanley, 1989. Geographic Information Systems: A Management Perspective. WDL Publications, Ottawa, Canada.