STATEMAP digital products should, to the extent feasible, adhere to the following Guidelines. Please note that the Guidelines (formally adopted by the Association of American State Geologists in 2002) address the general format of digital maps submitted to STATEMAP, and are not strict requirements. However, STATEMAP participants are encouraged to use them, for the following reasons:
1. CONFORMANCE TO EXISTING REQUIREMENTS - Digital STATEMAP products (referred to as "products" below) will conform to the respective agency's policies and guidelines for approval and publication of products. For example, USGS map products contributed to the NGMDB will conform to Discipline and Bureau policies, including the requirements of Executive Order 12906, USGS Manual chapter 504.1, and Geologic Discipline Policy Manual chapter 6.1.3.
2. SCOPE AND RESPONSIBILITIES - These requirements apply to products intended for release to the public in both formal and open-file series. Each agency is responsible for promoting conformance of their products to these guidelines
3. DATA FORMATS - A specific data format is not required, because of the variety of data systems employed by all cooperators in the National Cooperative Geologic Mapping Program. Agencies are, however, urged to provide their map products in one or more commonly used data formats (for example, Arc/Info export and Shape format [or Shape format alone], AutoCAD Map export and DXF format [or DXF format alone]). If the map data are expressed in a non-proprietary format that is not supported by published documentation, the format should be fully and clearly documented in the product.
4. ASSOCIATED FILES - All associated files critical to the understanding of the map product should accompany the map data files. These may include tabular and text files containing attribute data, and lookup tables and color-and-line palettes (e.g., Arc/Info symbolsets and shadesets) to permit users to display the map data interactively to a monitor.
5. FILE NAMING CONVENTION - For the widest possible usage, agencies may choose to use file names that conform to the "8.3" convention. This convention specifies that file names be limited to 8 characters or less, followed, if needed, by a period and a 3-character extension. Although this is becoming an outdated convention, it is a conservative approach to file naming that may help minimize user problems with the map files. An example would be the file name "readme" or "readme.txt." The name and extension should be composed entirely of lower-case (not mixed-case) letters, numerals, underscore, and hyphen. The name should begin with a letter.
6. COORDINATE SYSTEMS - Map data provided in geographic coordinates (latitude and longitude) is most generally useable. The author may choose to provide the map data in geographic coordinates and/or in coordinates in the map projection and ground units typically used for maps of that scale and location (e.g., the UTM projection for 30-minute by 60-minute, 1:100,000-scale quadrangle maps, with ground units in meters). In the metadata and readme files, the horizontal geodetic datum (e.g., NAD27) should be specified. To avoid loss of data quality due to resampling during projection, raster thematic (e.g., maps showing spatial variation of a single phenomenon, such as geophysical data) should at least be provided in the original, unprojected form. If the GIS software does not create a file containing essential information about the projection, the author should create a file.
7. BASE MAP - Wherever possible, map products should be georeferenced to a digital base, preferably the one on which the map was compiled. As a service to users, the author(s) may elect to include the base map with the product. This is highly recommended if the base is not published or is not commonly available. If a digital base was used, and was revised to correct for spatial or attribution errors, it should be supplied (in vector or raster format) with the product or made publicly available at a specified web site. Revisions to published base maps should be supported with metadata that describes the data processing. However, not all geologic maps are compiled on a digital base, generally because one is not available. In such cases, it is suggested that: a) the base be scanned and georeferenced, b) the geologic map be geoferenced to the base, and c) the base be provided, in vector or raster format, with the product.
8. METADATA - All geologic- and base-map data should be documented with metadata. If possible, this metadata should conform to the Content Standard for Digital Geospatial Metadata (CSDGM) of the Federal Geographic Data Committee (FGDC). Conformance of the metadata to the structure defined in the CSDGM can be determined using the USGS metadata parser "mp." This parser verifies the specific indented-text format compatible with the Geospatial Data Clearinghouse. This specification should not, however, preclude each agency from exploring other options for managing metadata, including relational databases.
9. README FILE - A brief, overall introduction and guide to the product should be included in a plain-text file named "readme" or "readme.txt." This file should include, but is not limited to, the identity of the product, a brief product description, introductory instructions on how to extract information from the product file(s), a table of contents describing how the product's directories and files are organized, and the location of the detailed metadata.
10. BROWSE GRAPHIC - A low-resolution "browse" graphics file that represents the finished map product should be provided in GIF, JPEG, TIFF, EPS or PDF format. This file is intended to be a relatively simple depiction of the data that enables the user to quickly visualize the map from the author's perspective. Typically, this graphics file is not a fully detailed depiction of the map data; in such cases the graphic should contain, next to the map image, the following disclaimer: "NOTE: This image is not an authoritative representation of the data."
11. PLOT FILE - The author also is encouraged to include a "plot file" (preferably PDF or EPS), intended to provide the user with the author's full interpretation of the map data. Commonly, these plot files are as detailed as published geologic maps. The decision to include a plot file might be based on the map content and complexity, and the size of the file (Will it, with the map product, fit on the intended media?). If a plot file is included, the author should note, in the metadata or readme file, the plotter and the RIP (raster-image processor) software with which the map has been plotted successfully, and the dimensions of the plot image.
12. PRODUCT FILE - The product should be packaged in one or more files, and the file(s) should be compressed using one of the commonly used data-compression formats (e.g, zip, gzip, tar). The decision whether to use one product file or more should be based on the content and size of the product. Generally, one product file is preferred because product integrity is more easily maintained. However, if the product is relatively large and contains an extensive base map and/or a large plot file, the author may choose to package the plot file or base map in a product file separate from the geologic data. In that case, both product files would contain the readme file. The author should provide in the readme file the information needed to unpack the product file. This may include providing URLs where the file-decompression software may be obtained. The product file is intended to provide users with a simple means for copying the product to a local disk, which is especially helpful for products with many data files.
13. SUPPORTING DOCUMENTATION - Potential users of the data may want a brief overview of the product before deciding whether to acquire it. Therefore, authors should provide the following separate files to accompany the single-archive file containing the product (these are duplicates of files contained in the product): the readme file, the browse graphic, and the metadata file in plain-text and, optionally, in HTML and/or XML format.
Return to the NGMDB project 