GIS Library Rules and Conventions

General

• We have no way to restrict any or all of the GIS library data from being made available to others. It may end up on any of our products such as Internet maps, our FTP server, or other data products. If there is anything that you don't want the public to have, then it's best to strip out the sensitive part before contributing the data to the library. (We do have some layers that are not for general use, but they are generally for special projects and are kept separate from our main GIS library.)
• Library information may only be stored in predefined subdirectories established for that purpose as defined by Where's the data? Users should not create ad hoc subdirectories. The directory structure is not freeform. If you feel that a new type of data or some other new situation calls for one or more new subdirectories, contact Steve Whitney who will determine the necessity, add the directory, and update the Where's the data? library documentation.

Library Content

• The projection for all library vector layers (that is all except imagery) should be NAD83 HARN.
• Extraneous content should not be stored in the library. That is, the library should only contain files specifically intended for library storage. Historical copies that aren't official layers, working files, intermediate files, backups, and "save copies", and other copies should be stored someplace else. These things are OK and often needed, but not in the library.
• Only files of the proper, predefined type should be stored in their respective place in the library. Files such as text files, Excel spreadsheets, or any file not specifically designated for storage in a given subdirectory may not be stored where they don't belong. It's possible that some of these files may be accommodated by the metadata system.
• Do not store one format of a layer in more than one area. That is, do not store the source format (coverage or shapefile) in more than one path or directory, such as on Mars and the Pygmyowl server library areas. (Do not confuse this with the library's storage of most layers in different formats by design.)
• Do not use a library subdirectory as the working directory when running ArcInfo. This can leave trash in the library and cause other problems.
• All library GIS data layers should have metadata.

Layer Names

• Each GIS data layer must have a file name that is unique across the entire library. While the file system allows storing files of the same name in different subdirectories, this is not allowed by the library design.
• The descriptive layer name in the metadata should be unique for each layer. It doesn't make sense to have two layers with the same descriptive name. There has to be something key that makes the layers different and this should be reflected in the descriptive name.
• GIS data layer names must be no more than 8 characters long. This was chosen as the lowest common denominator across various software. The 8 character limit is driven by the DBF database format used by shapefiles that limits field names to 10 characters.

  When coverages are converted to shapefile format, fields are created that consist of the layer name and up to two additional characters. Therefore, we meet the 10 character field name limit with 8 characters in the data layer name and up to 2 more added by coverage to shape conversion. For instance, converting a layer called zonepima from coverage to shapefile results in fields in the DBF file of ZONEPIMA_ and ZONEPIMA_I. If the layer name was longer than 8 characters, then the added field names from conversion from coverage to shapefile would result in truncated field names that are no longer unique. For instance, if the layer name was CITYAREAS, then coverage to shapefile conversion would generate fields of CITYAREAS_ and CITYAREAS_I which after truncation to 10 characters would give the duplicate names of CITYAREAS_ and CITYAREAS_ causing the conversion to fail.

• GIS data layer names must be entirely lower case. Unlike Windows systems, UNIX is case sensitive. Lower case was chosen as the standard to avoid problems for UNIX users and UNIX software. Technically, references to GIS layer names in other text such as metadata should be lower case.
• GIS data layer names must not contain blanks or special characters other than underscore. Since the data is used by various operating systems and software, the only known safe special character is underscore. In other words, layer names may consist of lower case letters (a-z), numbers (0-9) and the underscore character. Underscore is not permitted as the first character and adjacent or trailing underscores are discouraged.
• GIS data layer names must start with an alphabetic character, not a number or underscore to avoid any potential conflict with software that doesn't allow names to start with these characters.
• Changing a layer's 8 character name is strongly discouraged. Layer names propagate to many places: maintenance software, metadata, FTP server, MapGuide, etc. If a layer name is changed, then all these other things need to be tracked and changed manually. Usually the benefit is not worth the time and inconvenience to many people. See Deleting or Renaming GIS Library Data Layers.
• Layers that are stored in more than one format must have the same name. That is, a coverage and its corresponding shapefile should have the same name.

Attribute Field Names

• It is recommended, but not required, that attribute field names should be upper case.

  Upper case only is recommended due to the field name case sensistivity differences in the various tools and languages we use as shown here.

  Tool	Case sensitive?	Notes
  SQL Server	NO
  ArcINFO Workstation	NO	Forces upper case
  ArcGIS (ArcMap etc.)	See notes	Mirrors underlying data storage mechanism
  AutoCAD	NO	Forces upper case
  dBASE	NO	Forces upper case

   

  Programming language	Case sensitive?	Notes
  AML	NO	Uses INFO where all field names are upper case.
  ColdFusion	NO
  JavaScript	YES
  VB	NO
  VBS	NO
  Python	YES
  .NET (C#)	YES
  Access	NO
  AutoLisp	NO
  Flex	YES
  Silverlight	See notes	Depends on language used. I.E. VB or C#

  
  
• Attribute field names should be unique within the first 10 characters. This enables coverages to be converted to shapefiles without error. Shapefile field names are 10 characters maximum. (Note that we're talking about field names, not values, which can be most any length.)
• Attribute field names cannot contain blanks. Punctuation and special characters other than underscore should generally be avoided as well. While some other special characters may work, we haven't tested them in all cases so it's better to simply not use them.
• Attribute field names should start with an alphabetic character, not a number or special character. Field names that start with numbers prevent the layer from being converted to coverage format.
• Field (attribute) names cannot be names that are reserved by the coverage model, Shapefile conventions, the Geodatabase, or the Oracle database. It is also good practice to avoid Microsoft SQL Server reserved words. See the complete list of Reserved Data Layer Field Names.

  Some commonly used field names that had to be changed in our GIS layers include:

    ACCESS    MINUS
    CHECK     MODE
    COMMENT   NUMBER
    DATE      ORDER
    DESC      ROW
    FROM      START
    GROUP     TO
    INDEX     UPDATE
    LONG
  

Attribute Field Content

• Layer attribute field text values may be mixed case or all upper case. Case standards should be implemented by layer developers on a field-by-field basis depending on the planned use and display of field contents. In any event, each field's case should be consistent for all records. That is, don't mix all upper-case and mixed-case in different records for the same field.

  The GIS Library standard used to be all upper case field content and was driven by ArcINFO Workstation. With the advent of newer GIS software, case-insensitive SQL Server searching, and the need for mixed case to improve appearance and readability, mixed case is now acceptable as well.

• Numeric attribute field types should be considered carefully including how the field will be used and the implications of using an inappropriate type. Many "numbers" should be stored as character fields when there is no potential for doing arithmetic calculations on the field contents. Examples of inappropriate field types include using floating point to store integer values, or numeric values that are identifiers or with no chance of being used for arithmetic operations being stored as numeric field types, rather than character. In some cases, software may use or require inappropriate field types.

This list of rules may be expanded as the need arises.