arc-info binary coverage files format.htm

ArcInfo Binary Coverage Files Format

<H2><A name=INFO_FILES>3 - THE ATTRIBUTE FILES</A></H2>
<P>Each type of coverage has a different way to store attribute information: 
<P>
<UL>
  <LI><B>V7.x Coverages</B> maintain a "../info" directory with the attribute 
  files for all the coverages that are located in the same parent directory. 
  <P></P>
  <LI><B>PC Coverages V1 and V2</B> store their attribute information in regular 
  DBF files inside the coverage directory. 
  <P></P>
  <LI><B>Weird Coverages</B> also use a "../info" directory shared by a number 
  of coverages, but the organization of that info directory differs a little 
  from what we find in V7.x Coverages. </LI></UL>
<P>
<H3><A name=INFO_V7>3.1 INFO FILES IN V7.x COVERAGES</A></H3>
<P>
<UL>The INFO files are tables with the attribute information attached to an 
  Arc/Info coverage. The data files themselves are stored in the coverage 
  directory, but the definition of the table fields are stored in the "../info" 
  directory. 
  <P>The ../info directory is shared by all the coverages stored in its parent 
  directory, and contains the following files: 
  <P><PRE>        arc.dir
        arc0000.dat
        arc0000.nit
        arc0001.dat
        arc0001.nit
        ...
        ...
        ...
</PRE></UL>
<P>
<H3><A name=ARC.DIR>3.1.1 INFO/ARC.DIR</A></H3>
<P>
<UL>Contains one record for each attribute table (arc*.*) in this info 
  directory. The file has no header, and each record has a fixed size of 380 
  bytes. 
  <P><PRE>	Bytes	Type	Description

	0-31	char	Table name (as shown by Arc/Info) padded with spaces
	32-39	char	Internal Name ("ARC#### " file name)
	40-41	int16	Number of fields in table (valid fields... see below)
	42-43	int16	Table Record size (rounded up to a multiple of 2 bytes)
	44-59	char	 ??? 16 spaces
	60-61	int16	 ??? Always 132
	62-63	int16	 ??? Always 0
	64-67	int32	Number of records  (may also be only an int16???)
	68-77		 ??? All zeros
	78-79	char	External flag ("  " or "XX", see note below)
	80-317		 ??? All zeros
	318-325	char	 ??? 8 spaces
	326-379		 ??? All zeros
</PRE>
  <P>Note that the Arc/Info table name (first field above) is always the 
  coverage name followed by an extension (ex: TEST.AAT, TEST.TIC, TEST.BND, 
  TEST.PAT, TEST.PATCOUNTRY, etc.). So this name can be used to search the 
  arc.dir for all tables related to a given coverage. 
  <P>The arc.dir entry contains the number of valid fields in the table, but the 
  arc####.NIT file can contain deleted field definitions (and these deleted 
  field definitions are even exported in the E00 table headers produced by 
  Arc/Info). In this case the number of field entries in the arc####.nit file 
  will be bigger than the number of fields found here. Unfortunately there does 
  not appear to be anything in the arc.dir that would allow us to tell if the 
  table has deleted fields (or not) until we go and read the arc####.nit file. 
  <P>In some cases, the "number of records" field for a table in the arc.dir 
  does not correspond to the real number of records in the data file. In this 
  kind of situation, the number of records returned by Arc/Info in the 
  corresponding E00 file will be based on the real data file size (obtained with 
  stat()), and not on the value from the arc.dir. (i.e. use num_records = 
  physical_data_file_size/record_size) 
  <P>The external flag tells where the data file is located. 
  <P>
  <UL>
    <LI>A value of " " indicates an internal table, i.e. the data is stored 
    directly in the info/arc####.dat file. 
    <P></P>
    <LI>A value of "XX" indicates an external table, i.e. the data is stored in 
    a file outside of the info directory. In this case the arc####.dat file 
    contains one 80 chars string with the path to this external data file 
    relative to the info directory (padded with spaces). </LI></UL>
  <P>When the value for "number of records" in the arc.dir is 0, then the data 
  file for this table may not exist yet. 
  <P>The value for "number of records" in the arc.dir is the real size used by 
  each record in the data file, and thus must be a multiple of 2 since data 
  records are padded at the end to be aligned with a 2 bytes boundary. 
  <P>There does not appear to be any difference between single and double 
  precision table entries. </P></UL>
<P>
<H3><A name=ARC.DAT>3.1.2 INFO/ARC*.DAT</A></H3>
<P>
<UL>For internal tables (see external flag in the arc.dir entry), this file 
  contains the table data. 
  <P>For external tables, it is an 80 characters ASCII file that contains the 
  relative path of the file that contains the table data. The end of the path is 
  padded to 80 chars with spaces. 
  <P><PRE>Ex: 
../test/tic.adf
</PRE></UL>
<P>
<H3><A name=ARC.NIT>3.1.3 INFO/ARC*.NIT</A></H3>
<P>
<UL>Contains the table fields definition. The file has no header, and each 
  field definition record has a fixed size of 144 bytes. 
  <P>The meaning of the items marked with a question mark is unknown, but they 
  could be recognized in the following E00 IFO table header. 
  <P><PRE>  ----------------------------------------------------------------------
  FNODE#            4-1   14-1   5-1 50-1  -1  -1-1                   1
  ----------------------------------------------------------------------

	Bytes	Type	Description

	0-15	char	(FNODE#) Field name padded with spaces
	16-17	int16	(4)	 Storage size in bytes
	18-19	int16	(-1)	 ?
	20-21	int16	(1)	 1-based offset of the field in a record
	22-23	int16	(4)	 ? (always 4 !!!)
	24-25	int16	(-1)	 ?
	26-27	int16	(5)	 Display format: width
	28-29	int16	(-1)	 Display format: number of decimals or -1
						 if not applicable.
	30-31	int16	(5)	 First digit of field type
	32-33	int16	(0)	 2nd digit of field type (always 0)
	34-35	int16	(-1)	 ?
	36-37	int16	(-1)	 ?
	38-39	int16	(-1)	 ?
	40-41	int16	(-1)	 ?
	42-57	char		 ? Alternate Name (always blank!) ?
	...
	114-115	int16	(1)	 1-based field index (-1 if field is deleted)
	116-144			 ? All zeros
</PRE>
  <P>The field type is specified by the following codes: 
  <P><PRE>	10 (D) Date (stored as 8 bytes, display width must be either
	       8 chars (12/31/99) or 10 chars (12/31/1999) )
	20 (C) Character string
	30 (I) Integer with fixed number of digits (1 byte storage per digit)
	40 (N) Numeric value with decimals and fixed number of digits 
	       (1 byte storage per digit, value is right-justified)
	50 (B) Binary integer (2 or 4 bytes)
	60 (F) Binary float (4 or 8 bytes, depends on coverage precision)
</PRE><I>Ref: Understanding GIS... p.6-5, 6-6</I> 
  <P>When exported to E00, here is the form that each type takes: 
  <P><PRE>	10 (D) 8 characters
	20 (C) Nbr of chars = field storage size.
	30 (I) Nbr of chars = field storage size, value is right-justified
	40 (N) stored as single prec. floats = 14 chars, ex: "-1.7735416E+00"
               (Uses 1 byte storage per digit internally, but always stored
                as single precision floats in both single and double 
                precision E00 tables.)
	50 (B) 32 bits integer use 11 chars, right-justified
	       16 bits integer????? Never saw an E00 that contained any!
		    but it would probably be 6 chars since the biggest 
		    value to store would be "-32767"
	60 (F) single prec. = 14 chars total, ex: "-1.7735416E+00"
	       double prec. = 24 chars total, ex: "-2.60358875000000000E+05"
</PRE></UL>
<P>
<H3><A name=INFO_DATA>3.1.4 TABLE DATA files (.adf, ...)</A></H3>
<P>
<UL>The table data itself is stored in binary files inside the coverage 
  directory. They usually have a .adf extension in simple coverages, (ex: 
  tic.adf, bnd.adf, aat.adf, pat.adf, ...) but it may not always be the case for 
  coverages with regions, etc. 
  <P>These files do not have any header, and they have fixed size records of the 
  size specified in the corresponding ../info/arc####.dat and 
  ../info/arc####.nit files. 
  <P></P></UL>
<P>
<H3><A name=TABLE_NAME>3.1.5 Name and location of TABLE DATA files</A></H3>
<P>
<UL>When reading a coverage, the information found in the arc.dir (and in the 
  arc####.dat for external tables) is sufficient to establish the location of 
  the actual data file. 
  <P>However, when time comes to create a new coverage, one needs to know how to 
  name and where to place the data files. 
  <P>For internal tables, the data file goes directly in the info directory, 
  inside the arc####.dat so there is not much to worry about. 
  <P>For external tables, the table name (first field in the arc.dir, and in and 
  E00 table header) is composed of 3 parts: <PRE>         [COVERNAME].[EXT][SUBCLASSNAME]
</PRE>
  <UL>
    <LI><B>[COVERNAME]</B>:<BR>The first part of the table name (before the '.') 
    is the name of the coverage to which the table belongs, and the data file 
    will be created in this coverage's directory... so it is assumed that the 
    directory "../[covername]" already exists and is writable. 
    <LI><B>[EXT]</B>:<BR>The coverage name is followed by a 3 chars extension 
    that will be used to build the name of the external table to create. 
    <LI><B>[SUBCLASSNAME]</B>:<BR>For some table types, the extension is 
    followed by a subclass name. </LI></UL>
  <P>When [SUBCLASSNAME] is present, then the data file name will be: <PRE>            "../[covername]/[subclassname].[ext]"
</PRE>e.g. The table named "TEST.PATCOUNTY" would be stored in the file 
  "../test/county.pat" (this path is realtive to the info directory) 
  <P>When the [SUBCLASSNAME] is not present, then the name of the data file will 
  be: <PRE>            "../[covername]/[ext].adf"
</PRE>
  <P>e.g. The table named "TEST.PAT" would be stored in the file 
  "../test/pat.adf" 
  <P>Of course, it would be too easy if there were no exceptions to these rules! 
  Single precision ".TIC" and ".BND" follow the above rules and will be named 
  "tic.adf" and "bnd.adf" but in double precision coverages, they will be named 
  "dbltic.adf" and "dblbnd.adf". 
  <P></P></UL>
<P>
<H3><A name=INFO_WEIRD>3.2 INFO FILES IN "WEIRD" COVERAGES</A></H3>
<P>
<UL>Weird coverages use the same method to store their INFO tables as V7.x 
  Coverages except for the file names used. 
  <P><PRE>      V7 Filename        Corresponding Weird Filename

      info/arc.dir	   info/arcdr9
      info/arc0000.dat	   info/arc000dat
      info/arc0000.nit     info/arc000nit
      covername/aat.adf    covername/aat
</PRE>
  <P>Weird coverage filenames and directory names are often in upper case. We've 
  also observed some coverages in which the DAT/NIT filenames were truncated to 
  8 characters, e.g. "ARC000DA", "ARC000NI", ... 
  <P>Another difference that was noted is that the "ARCDR9" file can contain 
  multiple entries for the same table name, and the only way to tell which one 
  is valid is by looking for the corresponding DAT and NIT files. 
  <P>V7 coverages will overwrite old tables in the arc.dir, but weird coverages 
  seem to always append to the end of the index. </P></UL>
<P>
<H3><A name=DBF_PC>3.3 DBF FILES IN PC COVERAGES V1 and V2</A></H3>
<P>
<UL>PC Coverages store their attribute information in regular DBF files inside 
  the coverage directory. 
  <P><B>File names:</B> 
  <P>There is no equivalent to the arc.dir with the list of table for each 
  coverage. You have to look for "???.DBF" in the coverage directory to get the 
  list of tables. 
  <P>Here are the most common .DBF table filenames we can find: 
  <P>
  <UL>
    <LI>AAT.DBF 
    <LI>PAT.DBF 
    <LI>TIC.DBF 
    <LI>BND.DBF 
    <LI>LUT.DBF </LI></UL>
  <P>Double precision PC Coverages V2 may contain: 
  <P>
  <UL>
    <LI>AAT.DBF 
    <LI>PAT.DBF 
    <LI>DBLTIC.DBF 
    <LI>DBLBND.DBF 
    <LI>LANDUSE.DBF </LI></UL>
  <P><B>Field Names:</B> 
  <P>Because of restrictions in the DBF specs for attribute names, some special 
  attribute names have to be repaired when they are read from a DBF file. For 
  instance, in a coverage named "TEST", the following DBF field names will 
  contain "_" characters in place of some characters that are not permitted in 
  DBF field names: <PRE>    .DBF Attribute Name    Arc/Info Name
	
	TEST_                 TEST#
	TEST_ID		      TEST-ID
	FNODE_                FNODE#
	TNODE_                TNODE#
	LPOLY_                LPOLY#
	RPOLY_                RPOLY#
</PRE>
  <P>It is also important to note that DBF field names are limited to 10 
  characters while Arc/Info field names can have up to 15 characters. 
  <P><B>Field Data Types:</B> 
  <P>DBF and INFO files do not use the same code for field data types. The DBF 
  data types have to be mapped to Arc/Info data types: 
  <P><PRE>    Arc/Info Data Type            DBF Field Data Type

	10 (D) Date                ??? Never seen any... probably 'D' (date)
	20 (C) Char		   'C' - char
	30 (I) Integer		   'N' - Numeric, decimals=0
	40 (N) Numeric		   ??? Never seen any... probably 'N'
	50 (B) Binary int.	   'N' - Numeric, decimals=0
	60 (F) Binary float	   'N' - Numeric, see not below
</PRE>
  <P>Note: Floating point values (type 60) are stored inside the DBF file using 
  exponent notation in 13 characters numeric ('N') fields with 0 significant 
  digits before the point. (e.g. -110.333300 is stored as -.1103333E+03, and 
  65.277460 is stored as 0.6527746E+02) 
  <P>Note2: What is the difference between types 30 and 50 when stored in DBF 
  files? It seems that all system attributes (TEST#, TEST-ID, FNODE#, etc...) 
  are always stored as type 50, and all user-defined integer fields would always 
  be stored as type 30. 
  <P></P></UL><!-- $Id: v7_bin_cover.html,v 1.11 2006/06/14 17:50:46 daniel Exp $ --></BODY></HTML>