The Water Resources NSDI Node is an online centralized repository of digital metadata that conforms to the Federal Geographic Data Committee (FGDC) standards.

Checklist for Reviewing GIS Data Sets

This is an example checklist for GIS data sets to be used for review purposes. This list is by no means all-inclusive, and some of the directions may not apply in all cases. Additional steps may be used, or some steps omitted, according to reviewer's discretion. We hope to present other example checklists in the future.

Have a printed or on-screen copy of the metadata handy so you can verify as you go through this checklist that the metadata match the data.

1. Each data set (data archive) should contain a metadata file (xml):
   1. ARCGIS data sets
      1. The ARC version number (e.g. the version of arc or arcmap you used) should be stated in the metadata.
      2. The type of compression (gzip, UNIX compress, winZip, etc.) used should be clearly stated in the metadata file.
      3. The operating system format (DOS, UNIX, XP, Win7, WinServer, Linux, etc.) should be stated in the metadata file.
      4. If you are using the arc interchange format (.e00) file, we recommend you also provide a (.shp) file and if possible a geodatabase file. This is to help maintain compatibility with newer releases of ARCMAP.
      5. Check the abstract and purpose in the metadata file.
         1. Check precision.
         2. Check types of features, attributes, and topology. Do they make sense and agree with the metadata?
         3. Check bounding coordinates. Are they reasonable?
         4. Check edit status. There should be no edit masks.
         5. Check projection, datum, units, and parameters. They should be defined, and should match metadata.
      6. Check items/attributes of all attribute tables:
         1. Check item names and definitions (input width, output width, type, number of decimal places, alternate names) to see if they match the metadata. Redefined items should be documented too, if present.
         2. LIST each attribute table unless impossibly long. Look for missing or nonsensical data values.
         3. Do FREQUENCY for all attributes having discrete values, and/or STATISTICS for attributes having floating-point values or a very large number of discrete values. Ensure all values that occur are valid according to the original source, and the metadata. Use RESELECT to verify that the values are in reasonable ranges and the number of records in each range of values is reasonable.
      7. For polygon coverages:
         1. Check that the universe polygon is record number 1, cover-id 0, and cover# 1.
         2. In TABLES reselect cover# ne cover-id + 1 Should get 0 records selected.
         3. From Arc:, check LABELERRORS covname . The only error listed should be that Polygon 1 has no label points.
         4. From ARCPLOT (nodeerrors dangle) or ARCEDIT (drawenvironment node dangle), check to see that there are no dangling nodes.
      8. For point coverages:
         1. Use DESCRIBE to make sure no polygons exist. If they do, the coverage is corrupted.
         2. In TABLES reselect cover# ne cover-id Should get 0 records selected.
         3. In TABLES reselect area ne 0 Should get 0 records selected.
         4. In TABLES reselect perimeter ne 0 Should get 0 records selected.
      9. For line/arc coverages:
         1. In TABLES reselect cover# ne cover-id Should get 0 records selected.
         2. In TABLES reselect length eq 0 Should get 0 records selected. Zero- length arcs are errors.
      10. In ARCEDIT (on a copy of the coverage!) carefully select all arcs having each important unique combination of arc attributes, then do UNSPLIT. This will get rid of unneeded pseudo nodes. Check number of arcs with DESCRIBE. If much lower than before, the coverage could be cleaned up and will take less space by doing UNSPLITs.
      11. In ARCPLOT, ARCEDIT, or ARCVIEW, do a contextual review. Bring up other coverages having the same or similar features to see how they align. MAPPROJECTION might be needed to plot the coverages together. Also, if any of the same or similar data are published in some other form, e.g. well locations in GWSI or a data report, do some random spot checking to verify they plot correctly. Also, do some reselects based on important attribute values (as in 7c above) and look at the features spatially. Are the features all showing up where they should be? Look for details that you might miss in looking at checkplots.
      12. Scan covname/log file. Make sure no edits have been done after last document update. Make sure renode is done after last edit and before arcdlg. Check that any previous cleans used the same tolerances as the last.
   2. Public-domain format (DLG) files:
      1. The format used should be clearly stated. DLG Version 3, Optional is most common.
      2. The type of compression (gzip, UNIX compress, etc.) used (if any) should be clearly stated in the README file. The original (uncompressed) file name and size should be stated. Uncompress the file and rename to original name, if needed.
      3. These data sets should be converted from DLG to another format (ARC/ INFO or another GIS if possible) and checked to insure no data were lost in the translation process. The following procedures use ARC/INFO.
         1. Use dlgarc optional filename.dlg covname to get data into ARC. Build topology (polygon, line, point) as necessary. Clean should not be necessary.
         2. Any applicable ACODE or PCODE files should be joined to the .aat or .pat tables using JOINITEM.
         3. If attribute files are provided for character-type items in separate ASCII files, get these into INFO using GET COPY ASCII filename or TABLES ADD FROM filename. Use JOINITEM to join this file with the feature attribute table. Be aware that ARCDLG stores the cover# as the DLG feature number in the DLG file, while DLGARC reads the DLG feature number into the cover-id. For polygon coverages you should be very careful in doing the JOINITEM. Generally, you should use cover# as the relate item to prevent attributes getting off by one record. The metadata should clearly identify the numbers in the ASCII attribute file as the DLG feature number. Non ARC users would have no idea what a cover# is.
      4. Compare output of DESCRIBE with that of the original ARC/INFO data set. Some things that may be different, but not necessarily in error are: the number of attribute data bytes; the number of tics; tolerances; and the coverage boundary.
      5. Do several of the checks from above for ARC/INFO-format data sets and compare the results to before. Bring the DLG-derived coverage and the original ARC coverage up together in ARCPLOT, ARCEDIT, or ARCVIEW and verify that they represent the same data. Be sure to zoom in enough to make sure the DLG version didn't loose detail or coordinate precision. RESELECT some features based on a sampling of attribute values in both the DLG-derived coverage and the original ARC coverage. Display the features from both coverages and verify that they coincide exactly.
2. Each data set should contain metadata.
   1. These files should include information on:
      1. Originator (author)
      2. Publication date (year)
      3. Title Edition or version
      4. Geospatial Data Presentation Form (map)
      5. Series name (Open-File Report)
      6. Issue identification number (OFR number)
      7. Publication place
      8. Publisher
      9. Currentness reference (publication date of source material)
      10. Maintenance and update frequency (if any)
      11. Access constraints (if any)
      12. Data set credits (co-operators)
      13. Completeness report (geographic extent of data)
      14. Horizontal and vertical positional accuracy report (if any)
   2. The files should also include complete and appropriate:
      1. Description of data
      2. Abstract
      3. Purpose
      4. Narration of procedures used to create or automate data
      5. List of revisions made to data (if applicable)
      6. Reviews and responses to reviews applied to data
      7. List of related data sets
      8. List of references cited
      9. Notes (disclaimers)
      10. Spatial domain (bounding coordinates)
      11. List of keywords
      12. Use constraints (scale constraints, data quality constraints, etc.)
      13. Contact information
      14. Logical consistency report (topology)
      15. Lineage description (log file)
          1. Check for RENODE right before ARCDLG
          2. Check for last BUILD/CLEAN and make sure there is no mention of ARCEDIT afterwards--This may not be an error, but it will alert you to possible problems with the coverages.
      16. Entity/attribute information
          1. Entity and attribute overview (if applicable, discussion of all important attributes)
          2. Entity type labels, definitions, and definition sources for all attribute tables
          3. Attribute labels, definitions, definition sources, domain values, enumerated domain values, measurement frequencies (if applicable)
      17. Metadata information
          1. Metadata date, contact, standard name, version, security

    The Water Resources NSDI Node is an online centralized repository of digital metadata that conforms to the Federal Geographic Data Committee (FGDC) standards.