arc-info binary coverage files format.htm

ArcInfo Binary Coverage Files Format

</PRE>
  <P>Note: The double precision file ("par.adf") header does not seem to follow 
  the general rule for the header... its precision field value is &gt; 0 while 
  this value is negative for all other double precision files(???). Also, the 
  third field has a value of 8, while it is 0 in all other headers. 
  <P>
  <H3><A name=TOL_PC>2.9.2 TOL file in PC Coverages V1</A></H3>
  <P>In PC Coverages, this file is called "TOL". 
  <P>Contrary to most other files, the TOL file in PC Coverages does not have 
  any header... it starts immediately with the tolerance entries like the 
  "tol.adf" in single precision V7.x coverages. 
  <P>Note that PC Coverages files are ALWAYS single precision. 
  <P>
  <H3><A name=TOL_WEIRD>2.9.3 TOL file in Weird Coverages</A></H3>
  <P>Same as "tol.adf" in single precision V7 Coverages except that the file is 
  called "TOL". </P></UL>
<P>
<H3><A name=TX6>2.10 TX6/TX7 - Annotations</A></H3>
<P>
<UL>
  <P>
  <H3><A name=TX6_V7>2.10.1 TX6/TX7 files in V7.x Coverages</A></H3>
  <P>TXT, TX6, and TX7 are 3 variations of text annotations that we find in E00 
  files. TX6 and TX7 annotations usually come with a .TAT info table, or a set 
  of .TAT tables. 
  <P>It seems that you can have several "subclasses" of annotations, in the E00 
  file they are sub-sections of the main TX6/TX7 section, and in a binary 
  coverage they are stored in separate files. 
  <P>There is no difference between the binary files for a TX6 and the files for 
  a TX7. However, in the E00 format, there is an additional value in the first 
  line of a TX7 entry (that is not present in a TX6), this value is very often 0 
  (or 1 in some cases), but even when it is set, it is not present in the binary 
  file... I have no idea where it comes from!?! 
  <P>For the subclass of annotations called TEST, you will find 3 files in the 
  coverage directory: 
  <P>
  <UL>
    <LI>test.txt - The actual annotations file 
    <LI>test.txx - <A 
    href="http://avce00.maptools.org/docs/v7_bin_cover.html#Index">Index 
    file</A> 
    <LI>test.tat - INFO table for this set of annotations </LI></UL>
  <P>The file "test.txt" has the usual 100 bytes header, followed by variable 
  length records for each piece of text. 
  <P>File Header: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	Signature - Always 9994
	4-7	int32	Precision - +67 for single precision, 
	                            and -67 for double precision.
	8-11	int32	Record size (always 0: variable length records)
	12-23		All zeros
	24-27	int32	File size (in 2 byte words), including header size 
	28-99		All zeros
</PRE>
  <P>Followed by records of data for each piece of text: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	System ID (TEST#)
	4-7	int32	Record Length, number of 2 byte words that follow
                        the current value.
	8-11	int32	User ID (TEST-ID)
	12-15	int32	??? LEVEL
	16-19	float	??? Defaults to -1e+02 but is sometimes different
	                    (this value is always a 4 bytes float value,
			     even for double-prec. coverages)
	20-23	int32	SYMBOL (Text font)
	24-27	int32	num_vertices1: for the line along which the text
                                       is drawn.
	28-31	int32	??? n28: Always 0 (Verified that it corresponds to the
	                                   6th value of 1st line in a TX7-E00)
	32-35	int32	Number of chars in text string
	36-39	int32	num_vertices2: for the text arrow.  If this value is
                                       negative then the arrow is reversed.

	40-41	int16	??? Always 1  - Corresponds to the second set of
	42-43	int16	??? Always 0    20 values in a E00 TX7 entry
	44-45	int16	??? Always 0
	...             ...
	78-79	int16	??? Always 0

	80-81	int16	Text justification  - Corresponds to the first set of
	82-83	int16	??? Always 0          20 values in a E00 TX7 entry
	84-85	int16	??? Always 0
	...             ...
	118-119	int16	??? Always 0
</PRE>
  <P>The rest of the record depends on the precision. For SINGLE PRECISION, we 
  have: 
  <P><PRE>	120-123	float	??? v1, Text Height ???
	124-127	float	??? v2 (always 0)
	128-131 float	??? v3 (always 0)
	132+    chars	Text String (padded with spaces to the 
	                             next 4 bytes boundary)

		float	x1 - Vertices list 
		float	y1   (num_vertices1+num_vertices2) vertice pairs
		float	x2
		float	y2
		float	... 

		int32	??? Unused ???  - The last 8 bytes look like junk
		int32	??? Unused ???  - See note below.
</PRE>
  <P>And for DOUBLE PRECISION, we would have: 
  <P><PRE>	120-127	double	??? v1, Text Height ???
	128-135	double	??? v2 (always 0)
	136-143 double	??? v3 (always 0)
	144+    chars	Text String (padded with spaces to the 
	                             next 4 bytes boundary)

		double	x1 - Vertices list 
		double	y1   (num_vertices1+num_vertices2) vertice pairs
		double	x2
		double	y2
		double	... 

		int32	??? Unused ???  - The last 8 bytes look like junk
		int32	??? Unused ???  - See note below.
</PRE>
  <P>Note: <BR>The last 8 bytes of junk appear to be always present in V7 
  coverages. However, they are sometimes present and sometimes not present in 
  Weird coverages. Thus, the only safe way to know whether there is junk to skip 
  at the end of a TX6 record is to use the record length value in bytes 4-7. 
  <P>
  <P>
  <H3><A name=TX6_PC>2.10.2 TX6/TX7 files in PC Coverages V1</A></H3>
  <P>PC Coverages probably can't have TX6/TX7 files but they can have TXT files 
  though... see below. 
  <P>
  <H3><A name=TX6_WEIRD>2.10.3 TX6/TX7 files in Weird Coverages</A></H3>
  <P>Weird coverages can have TX6/TX7 files, and they work the same way as for 
  V7 coverages, except that the name ends with "txt", instead of ".txt". (e.g. 
  we have "testtxt" instead of "test.txt") </P></UL>
<P>
<H3><A name=TXT>2.11 TXT - Annotations</A></H3>
<P>
<UL>
  <P>
  <H3><A name=TXT_V7>2.11.1 TXT.ADF file in V7.x Coverages</A></H3>
  <P>TXT type of annotations use the exact same file structure as TX6/TX7 above, 
  with the following differences: 
  <P>
  <UL>
    <LI>The file names will be "txt.adf" and "txx.adf" for the Index file 
    <LI>The values in bytes 40-119 of each entry look like junk... there appears 
    to be absolutely no correlation with what you find in the corresponding TXT 
    section of an E00 file. 
    <LI>When the binary TXT structure is converted to E00-TXT, the first vertex 
    of the vertices list for the text's polyline is always ignored (the first 
    and second vertices in the vertices list are always the same).<BR>For 
    instance, if num_vertices1==3 in the binary file, then we should ignore the 
    first vertex, and the corresponding E00-TXT entry would have num_vertices1=2 
    (corresponding to vertices 2 and 3 in the vertices list). </LI></UL>
  <P>
  <H3><A name=TXT_PC>2.11.2 TXT file in PC Coverages V1</A></H3>
  <P>In PC Coverages, the main file is called "TXT" and the index "TXX". 
  <P>They both start with the <A 
  href="http://avce00.maptools.org/docs/v7_bin_cover.html#Header_PC">256 bytes 
  header</A> specific to PC Coverages, followed by the 100 bytes header: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	Signature - Always 9994
	4-7	int32	Precision - Always 1 (always single precision)
	8-11	int32	Record size (always 0: variable length records)
	12-23		All zeros
	24-27	int32	File size (in 2 byte words), including header size 
	28-99		All zeros
</PRE>
  <P>However, contrary to what we find with most other file types, the data 
  records in the TXT file are different from what we find in V7.x TXT.ADF files. 

  <P>PC Coverage TXT entries are always single precision. For each piece of 
  text, we have: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	System ID (TEST#)
	4-7	int32	Record Length, number of 2 byte words that follow
                        the current value.
	8-11	int32	??? LEVEL (Corresponds to bytes 12-15 in a V7 TXT)
	12-15	int32	Number of vertice pairs that are valid ( [1..4] )
	16-19	float	x1 - (1st float value in a E00 TXT section)
	20-23	float	y1 - (5th float value in a E00 TXT section)
	24-27	float	x2 - (2nd float value in a E00 TXT section)
	28-31	float	y2 - (6th float value in a E00 TXT section)
	32-35	float   x3 
	36-39	float   y3
	40-43	float   x4
	44-47	float   y4
	48-75	float	Always 0 ??? Probably corresponds to the other
			float values in the E00 TXT section
	76-79	float	??? Text Height ???
	                Corresponds to the 15th float value in a E00 TXT
	80-83	float	??? Defaults to -1e+02 but is sometimes different
	84-87	int32	SYMBOL (Text font)
	88-91	int32	Number of chars in text string
	92+	chars	Text String (padded with spaces to the 
	                             next 4 bytes boundary... it was also
				     noted that strings that are a multiple
				     of 4 chars in length are also padded 
				     with 4 spaces)
</PRE>
  <P>
  <P>
  <H3><A name=TXT_WEIRD>2.11.3 TXT file in Weird Coverages</A></H3>
  <P>Weird coverages can have their TXT files stored using either the PC 
  structure or the V7 structure. In both cases the filenames are the same ("TXT" 
  and "TXX"). The only way to tell if the file is in PC TXT format or in V7 
  TXT/TX6/TX7 format is by looking at the precision field in the 100 bytes 
  header: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	Signature - Always 9994
	4-7	int32	Precision - +16 for single precision in PC TXT format,
                                    +67 for single precision in V7 format, 
	                            and -67 for double precision in V7 format.
	8-11	int32	Record size (always 0: variable length records)
	12-23		All zeros
	24-27	int32	File size (in 2 byte words), including header size 
	28-99		All zeros
</PRE>
  <P>When the V7 structure is used, the files are identical to the V7 
  TXT/TX6/TX7 files described above except for the filename. 
  <P>When the PC TXT structure is used, the files are similar to PC Coverage TXT 
  files, except for the byte ordering and the fact that there is no 256 byte 
  header in the Weird Coverage ones. Another minor difference: in Weird 
  Coverages, when a text string has a length that is a multiple of 4 chars, it 
  won't be padded with 4 spaces as it would have been in a PC Coverage file. 
  This is a minor detail, but it is interesting to notice that this bug has been 
  fixed between PC Arc/Info and the version of Arc/Info that produced the weird 
  coverages. 
  <P></P></UL>
<P>
<H3><A name=RXP>2.12 RXP - Specific to Regions</A></H3>
<P>
<UL>RXP sections contain define the list of polygons from the PAL section that 
  form each region, and they occur only in region coverages. There is one .rxp 
  file for each region in the coverage. 
  <P>RXP files were never encountered in PC Coverages and Weird Coverages. 
  <P>.rxp files have no header, and they contain fixed size records: 
  <P><PRE>	Bytes	Type	Description

	0-3	int32	Region Polygon ID
	4-7	int32	PAL Polygon ID
</PRE>
  <P>Regions that consist of multiple polygons will have several records with 
  the same Region Polygon Id and differing PAL Polygon Ids. 
  <P>
  <UL><PRE>RXP  2
OLD
         1       120
         2        11
         3        12
         4        13
         4       202
         5        16
         6        19
         7        14
         7        20
         7        21
         7       125
         8        22
...
...
</PRE></UL></UL>
<P>
<H3><A name=RPL>2.13 RPL - Specific to Regions</A></H3>
<P>
<UL>E00-RPL are also specific to region coverages. In the binary coverage, 
  they correspond to files with a ".pal" extension. There is one .pal file for 
  each region in the coverage and they use the exact same structure as "pal.adf" 
  files. Each .pal file probably contains the definition of the polygons that 
  belong to that region. 
  <P>RPL files come with an <A 
  href="http://avce00.maptools.org/docs/v7_bin_cover.html#Index">index file</A> 
  with a ".pax" extension. 
  <P>See the <A 
  href="http://avce00.maptools.org/docs/v7_bin_cover.html#PAL">"pal.adf" 
  description</A>... 
  <P>RPL files were never encountered in PC Coverages and Weird Coverages. 
</P></UL>
<P>
<HR width="50%">

<P>