The directives that are processed by the SAIF writer are listed below. The suffixes shown are prefixed by the current <WriterKeyword>_ in a mapping file. By default, the <WriterKeyword> for the SAIF writer is SAIF.
Tip: Tip: The SAIF Utilities package can be used to check the syntax and validate the definitions held in the CSN before they are used by FME.
DATASET
Required/Optional: Required
The value for this keyword is the name of the SAIF dataset file. A typical mapping file fragment specifying an output SAIF dataset looks like:
SAIF_DATASET /usr/data/SAIF/92i080.zip
DEF
Required/Optional: Required
Before any SAIF data can be written, the SAIF addressable object, in which the features are contained, must be specified. The syntax of the SAIF DEF line is:
SAIF_DEF <membertype> \ [SAIF_COMPOSITE_CLASS <composite type>] \ [SAIF_IDENTIFIER <identifier>] \ [SAIF_OBJECTSET <object set id>] \ [SAIF_AGGREGATE <aggregate spec>] \ [SAIF_COMPONENT_PATH <componentPath>] \ [<geoComponents spec>]* \ [<attr path> <attr value>]*
Each of the components of the SAIF_DEF statement are described below. The DEF line attempts to make SAIF as easy to define as possible by generating defaults that can be used in the majority of cases. See the points below for the values of these defaults and a discussion of what they mean and when to override them.
<membertype>: This is the feature type of the objects stored within the SAIF object being defined. In SAIF it is strongly suggested that all class names consist of two parts; a <class name>, and <domain name> separated by a double colon (::).
<class name>: A unique class name within the current domain.
<domain name>: Each CSN definition set, except the base set, must use a domain name. The domain name choice is left up to you.
The example below defines the member type of objects to be Roads::TRIM. Roads is the <class name> component and TRIM is the <domain name> component.
SAIF_DEF Roads::TRIM
SAIF_COMPOSITE_CLASS
This is the name of the composite class into which the SAIF objects of type <membertype> are stored. This is the actual SAIF class which is addressable. Each DEF line defines a single addressable object of the type specified here. If this is not specified, then a default value is generated which inserts the word Composite immediately before the double :: specified in <membertype>.
Using the above example, the default value of SAIF_COMPOSITE_CLASS is RoadsComposite::TRIM. This value can be overridden simply by specifying the SAIF_COMPOSITE_CLASS parameter. The example below overrides the default value instead specifying RoadsCollection::TRIM.
SAIF_COMPOSITE_CLASS RoadsCollection::TRIM
SAIF_IDENTIFIER
This is the identifier used to identify the SAIF addressable object being defined by this SAIF_DEF line. If not specified, the default value for the identifier is the same as the <membertype> with the double colon and the domain name removed.
Using the example above, the default value of SAIF_IDENTIFIER is Roads. This value can be overridden by specifying the SAIF_IDENTIIFIER parameter. The example below overrides the default value specifying TRIMRoads.
SAIF_IDENTIFIER TRIMRoads
SAIF_OBJECTSET
This defines the object set into which the addressable object being defined is to be stored. If not specified, the default value for the identifier is generated using the first 4 characters of the <membertype> followed by the last two characters before the double colon (::). If the <class name> portion of the <membertype> is less than 6 characters, the object set name is taken to be equal to <class name>.
Using the example above, the default value of SAIF_OBJECTSET is roads. This value can be overridden by specifying the SAIF_OBJECTSET parameter. The example below overrides the default value specifying troads.
SAIF_OBJECTSET troads
SAIF_AGGREGATE
This defines the aggregate into which the objects are to be placed. This parameter is only used when the features being defined are stored within a SAIF aggregate, which is itself stored within another aggregate. An example of when this occurs is the SAIF DEM into which DEMpoints, Breaklines, and other aggregates are stored. See the SAIF Formal Specification for a description of SAIF aggregates. The example below shows how to specify the aggregate for storing DEMpoints.
SAIF_AGGREGATE geoComponents{0}.position.geometry.masspoints
The statement above gives the full path to where the features belonging to this SAIF_DEF line are placed. They are placed within the aggregate identified by position.geometry.masspoints which itself is stored as the first element within the aggregate geoComponents.
Usually, this line follows immediately after one or more <geoComponents spec> lines, which are described below.
SAIF_COMPONENT_PATH
The SAIF component path defines the path to the aggregate into which the features belonging to this SAIF_DEF are placed. By default, the value of this parameter is geoComponents as this is the value used in the majority of cases. An example of when the value needs to be overridden is when the feature represents a SAIF text object. In this case, the SAIF_COMPONENT_PATH should be specified as annotationComponents. The example below overrides the default value and specifies a component path of annotation components.
SAIF_COMPONENT_PATH annotationComponents
<geoComponents spec>
This portion of the SAIF_DEF line is required only when the SAIF_AGGREGATE line is used. These specifications define the geoComponent aggregate classes before the first feature arrives. This statement configures the aggregates so that the features associated with this SAIF_DEF line can be inserted into SAIF. The example below continues the example given for the SAIF_AGGREGATE line above, and defines the two aggregates required before DEMpoints can be stored within the SAIF dataset.
geoComponents{0}.Class PointsAndBreaklines::TRIM \
geoComponents{0}.position.geometry.Class MeasuredSurface
The first line defines the type of aggregate for the first element of the geoComponents aggregate. It is defined to be of the type PointsAndBreaklines::TRIM. The first part of this statement geoComponents{0} defines the path name of the aggregate. The .Class suffix instructs the underlying SAIF Toolkit, which the SAIF writer uses, that this is the name of the class for the object that has a path of geoComponents. See the SAIF Toolkit documentation for a full discussion of the .Class notation and the meaning of path names in SAIF.
The second line defines the type of aggregate for the object with the path name position.geometry within the aggregate geoComponents{0}. It is defined to be of the type MeasuredSurface.
Once this is defined, the SAIF_AGGREGATE line follows to define the aggregate where the DEMpoints will be stored.
<attr path> <attr value>
These lines are used to simply specify attribute path and attribute value pairs. The first part of the line identifies the attribute path to be set and the second part of the line specifies the value to be assigned to the attribute. These attribute values are used to set any attribute values at the aggregate level. The SAIF_DEF line cannot be used to set any attribute values for the features actually stored within the SAIF dataset.
CSN
Required/Optional: Required
The FME mapping file will have one or more SAIF_CSN file lines which define the CSN files that contain the SAIF class definitions for the objects to be stored within the SAIF dataset. If an attempt is made to define any object not of a class specified in the CSN files, then an error results and the FME session is stopped.
The example below defines two CSN files. The first file is the SAIF base set of classes and must always be the first CSN file specified. The second CSN file is a file that contains a set of domain-specific definitions.
SAIF_CSN saif32.csn SAIF_CSN forest32.csn
XCOORD_TYPE
Required/Optional: Required
This is the numeric domain of the x coordinate. All coordinates stored within the SAIF dataset will have their x value in the domain specified on this line. The example below instructs the SAIF writer module that all x coordinates are of the type integer.
SAIF_XCOORD_TYPE STK_INT32
YCOORD_TYPE
Required/Optional: Required
This is the numeric domain of the y coordinate. All coordinates stored within the SAIF dataset will have their y value in the domain specified on this line. The example below instructs the SAIF writer module that all y coordinates are single precision floats.
SAIF_YCOORD_TYPE STK_REAL32
ZCOORD_TYPE
Required/Optional: Required
This is the numeric domain of the z coordinate. All coordinates stored within the SAIF dataset will have their z value in the domain specified on this line. The example below instructs the SAIF writer module that all z coordinates are double precision floats.
SAIF_ZCOORD_TYPE STK_REAL64