Writer Directives

The suffixes shown are prefixed by the current <WriterKeyword> in a mapping file. By default, the <WriterKeyword> for the E00 writer is E00 or ARCINFO.

DATASET

Required/Optional: Required

Unlike the E00 reader, which reads a single E00 file, the writer may create several files. The DATASET keyword for the E00 writer is the folder into which the created E00 files (or coverages) will be written.

Workbench Parameter: Destination Esri ArcInfo Export (E00) File

DEF

Required/Optional

Required

Workbench Parameter

<WorkbenchParameter>

An E00 file or coverage must be completely defined before it may be written. The definition specifies the base name of the file and the names and types of all attributes on all info files within the E00 file. The syntax of an E00 DEF line is:

<ReaderKeyword>_DEF <baseName>	\
	[E00_FORCE_OUTPUT <subfileName>[,<subfileName>]+] \
	[<attrName> <attrType>[,INDEX]]+

The file name of the physical E00 file is constructed by appending the .e00 suffix to its baseName. Binary coverages are written as a folder named baseName. Coverage names are always truncated to contain thirteen or fewer characters, and converted to lowercase letters, when forming output folder names.

The E00_FORCE_OUTPUT keyword is used to force the named subfiles to appear in the output E00 file or binary coverage, even if no contents are specified for them. The value for subfileName can either be the name of a one of the standard subfiles LAB or TOL, or can be any info file. (The naming of info files follows the same pattern as in the <infoFile>:<attrName> notation discussed below.) The TOL and LAB files are normally generated by the E00 writer, but this behavior can be overridden by specifying an E00_FORCE_OUTPUT keyword that does not list the TOL or LAB subfile: if a list of files are forced to be output, and no TOL file is specified in the list, then a TOL file will be generated only if specific tolerances are defined as discussed in the section titled Tolerances; if the LAB subfile is not specified in the list, a LAB file will be generated only if features are written out to define the contents of the LAB file.

The attribute names for an E00 file must be uppercase, and must not exceed 16 characters in length. One should be aware that there are a few peculiar character sequences used by the E00 writer, for historical purposes. A trailing underscore character on an attribute name is replaced by a hash character (“#”), and a trailing sequence of “_ID” is replaced with “-ID”. Thus, attributes named JOES_ and JOES_ID on the E00_DEF line of a mapping file would be called JOES# and JOES-ID in the resulting info file.

One can work around this limitation by inserting single quotes around the underscore in the name of the attribute on the DEF line. For example, an attribute listed as JOES’_’ID on an E00_DEF line would result in an attribute named JOES_ID appearing in the info file, instead of an attribute named JOES-ID.

The following table shows the attribute types that are supported.

Attribute Type

Description

char(<width>)

Fixed-length character string. The width parameter controls the maximum number of characters that can be stored in the field. When a character field is written, it is right-padded with blanks, or truncated, to fit the width.

width must be between 1 and 320, inclusive.

char

Character string with a default maximum length (currently set to 320). This type should be used only for testing purposes, and not for production mapping files; for most cases, use the char(<width>) form above.

date

Character string representing a date. Attributes of type date must have exactly eight characters, and be of the form YYYYMMDD, where YYYY is the year, MM is the month (01-12), and DD is the day of the month (01-31).

int
int(<width>)

Integer field. The optional width parameter specifies the display width of the field within ArcInfo.

width must be between 1 and 16, inclusive. Representable numbers are those in the range of -999,999,999,999 to 9,999,999,999,999,998, inclusive.

number
(<width>,<dec>)

Numeric data displayed with a field width of width and dec decimal positions. The value of width must allow for any minus sign and decimal point in the number, and must be in the range of 1 to 16, inclusive. The value of dec must be between 0 and 14, inclusive.

binint

binint(<size>)

binint(<size>,<width>)

Integer value, to be stored in ArcInfo as a binary number instead of character data. If the optional size parameter is specified, it specifies the number of bytes of storage (2 or 4 bytes) ArcInfo will use to store the value. The optional width parameter specifies the display width for ArcInfo to use. The size will default to 4bytes, and the display width will default to 5 for a 4-byte integer, or 4 for a 2-byte integer.

size must be either 2 or four. width may be any integer between 1 and 6 when size is 2, or between 1 and 11 if size is 4.

float

float(<width>,<prec>)

Floating point number, to be stored in ArcInfo as a four-byte binary number instead of as character data. The width and prec parameters define the display width and number of decimals for ArcInfo to use.

A float field retains up to 9 digits of precision; only zero and numbers with a magnitude between 1.175494351e-38 and 3.402823466e+38 may be represented as float values.

double

double(<width>,<prec>)

Floating point number, to be stored in ArcInfo as an eight-byte binary number instead of as character data. The width and prec parameters define the display width and number of decimals for ArcInfo to use.

A double field retains up to 17 digits of precision; only zero and numbers with a magnitude between 2.225073858507201e-308 and 1.7975931348623158e+308 may be represented as double values.

redefined(<offset>, <length>, 
<fieldName>)

A redefined field specifies a subfield of another field within the same info file. The features written to an info file with redefined fields do not actually have attributes named for the redefined fields; the resulting E00 file defines the field in such a way that ArcInfo interprets the value of the redefined field as byte positions offset to (offset + length - 1) of the specified fieldName. Offsets are zero-relative, so an offset value of 1 actually refers to the second character of the named field.

An attribute’s type parameter may optionally be followed by the literal string ,INDEX, such as in:

E00_DEF ROADS  \
	NAME  char(16)	\
	.ARC:IDENT  binint,INDEX

This indicates that particular field is an index in the ArcInfo info file.

Normally, any attributes provided on the DEF line will be applied to all info files created with the exception of the .BND and .TIC files, which have a specific format. However, the DEF line supports an attribute naming convention which allows a particular attribute to be applied to a specific info file. If the attribute name in the DEF line is of the form <infoFile>:<attrName>, then the attribute attrName will be added only to the info file specified by infoFile. There are actually three ways to specify an infoFile, as outlined by the following table.

infoFile Specification

Application

<baseName>.<suffix>

Attribute belongs to the precise info file named, and no others, for example, HYDRO.TATANNO.

.<suffix>

Attribute belongs to all info files with the specified suffix, for example, .TATANNO, .PAT.

.TAT

Attribute applies to all info files with a suffix that starts with .TAT. This is a special case provided solely for text attributes. Since text attribute files have the suffix .TAT<annoLayer>, with the possibility of having several annoLayers in a single E00 file, this syntax allows the definition of attributes to be applied to the text attribute files for all annotation layers.

If an info file has specific attributes defined on it using the above <infoFile>:<attrName> syntax, then it will not have any of the attributes listed with the normal syntax, that is, <attrName> only.

Furthermore, the special info files .TIC and .BND always have the same predefined attributes, no matter what the contents of the DEF line for the E00 file are. Each of the special geometry-related attribute files (.AAT, .PAT, and .TAT) also has a default set of attributes which will always be present in the info file, but in these cases, the set of attributes will be supplemented with the appropriate attributes specified on the DEF line.

If an attribute name starts with a "-" character, then the specified attribute is removed. For example, if an attribute named ".TAT:-OFFSETX" is specified on the DEF line, then the specified attribute is not included in the resulting info file. This allows you to remove default attributes from standard info files.

If an attribute name starts with a "+" character, then its type will override the type of any of the standard attributes with the same name.

Controlling E00 Output describes what info files will be automatically created when geometric entities are directed at E00 files, and how to generate custom info files.

TOLERANCES

Required/Optional: Optional

An E00 file or coverage can contain a subfile which defines tolerances used within ArcInfo. There are exactly ten tolerances defined in this file. Each tolerance has a value and a state. The FME refers to these tolerances by name or by number, as described in the Tolerance Values.

The TOLERANCES keyword tells the FME to create a TOL subfile with a specific value or state for a particular tolerance value. The syntax of a tolerance specification is:

    <WriterKeyword>_TOLERANCES <id>=<val>[,<state>][:<id>=val[,<state>]]+

where id is a valid tolerance number or name from the table in Tolerance Values, val is the specified tolerance’s new value, and the optional state parameter is either 1 or 2, to specify whether the tolerance has been verified. If the state is not specified, a default value of 1 is used.

The E00 writer always generates a TOL file in each generated E00 file or binary coverage unless the E00_FORCE_OUTPUT option is specified in the coverage’s DEF line, and TOL does not appear in the list of subfiles to force. If a TOL file is generated, any tolerances not specified by the TOLERANCES keyword will take the following default values and states:

Tolerance Identifier Default Value Default State
1 (FUZZY) 1.0e-20 1

2 (GENERALIZE)

0

2

3 (NODE_MATCH)

0

2

4 (DANGLE)

0

1

5 (TIC_MATCH)

0

2

6 (EDIT)

1.0e-18

2

7 (NODESNAP)

1.0e-19

2

8 (WEED)

1.0e-19

2

9 (GRAIN)

1.0e-19

2

10 (SNAP)

1.0e-19

2

PRECISION

Required/Optional: Optional

Value: SINGLE | DOUBLE

Default Value: DOUBLE

Workbench Parameter: Coverage Precision

COMPRESSION

Required/Optional: Optional

E00 files may be written out uncompressed or they may have one or two levels of compression applied to them. Compressed files take up far less space than uncompressed files but they are impossible to inspect manually and are not readable by many systems.

The COMPRESSION directive allows you to specify how much compression to apply to a file.

Note: FME Esri Edition will also generate binary ArcInfo coverages directly, if the COMPRESSION keyword is given a value of BINARY.

Value: NONE | PARTIAL | FULL

Default Value: NONE

Workbench Parameter: Compression

MAX_OUTPUT_SIZE

Required/Optional: Optional

Workbench Parameter: Maximum Output File Size

BYPASS_LINEAR_TOPOLOGY

Required/Optional: Optional

Normally, FME will compute a line-node topology whenever it writes out an E00 file or binary coverage. This can be a very expensive operation, and is not always needed.

For instances where a fully built linear topology is not needed in the resulting coverage, one may use the BYPASS_LINEAR_TOPOLOGY keyword to disable this feature. A value of YES will disable the topology computation, and a value of NO will leave it enabled.

For example,

E00_BYPASS_LINEAR_TOPOLOGY Yes

will produce output files with no linear topology.

Note: This affects linear output only. It is not possible to create a coverage of polygons which do not have topology connecting them to their linear boundaries. (Such representation is not possible in E00 files.).

Value: YES | NO

Default Value: NO (FME will compute a linear topology)

Workbench Parameter: Linear Topology

PRESERVE_CASE

Required/Optional: Optional

When set to “Yes”, the output files will have the same case as the feature types specified on the DEF line. When set to “No” it will demote the feature type to lowercase. For example, if the feature type is PoInT, it will be output as PoInT if the directive is set to “Yes” and as point if the directive is set to “No”.

If this directive is missing, then it will have an implied value of “No”. This is to ensure backwards compatibility, so workspaces created with a previous version of FME (one that does not yet support this directive) continue to work as they always have.

Example:

E00_PRESERVE_CASE Yes

Value: YES | NO

Default Value: Yes