|
Jump to: |
|---|
The following clauses describe how ili2fme maps INTERLIS objects to FME features. Features written to the INTERLIS transfer file are expected to have the same structure, as they would have had when read.
INTERLIS 1
INTERLIS allows for some nesting of type definitions. A class or table is defined in a topic. Several topics are grouped to a model. FME does not allow such a nesting; therefore, ili2fme maps INTERLIS class with their qualified name to FME feature types.
Each FME feature type has a format attribute xtf_id that is the transfer identification of that feature in the ITF file.
INTERLIS 2 Full Transfer Mode
For INTERLIS 2, the mapping is the same as for INTERLIS 1, but only if there are no extended topics in the INTERLIS model and there is only one basket per topic in the transfer file.
If an INTERLIS 2 data file has multiple baskets (instances of a topic; set of objects) of the same topic or the model has extended topics, additional format attributes are required.
To know which feature belongs to which basket, each feature has a reference to the basket in the format attribute xtf_basket. Each basket is represented as an instance of the format feature type XTF_BASKETS. The attribute xtf_topic holds the qualified topic name that describes this basket (in this case that would be ModelA.TopicA). The attribute xtf_id of the feature type XTF_BASKETS is the transfer identification of the basket (BID).
Multiple Geometries per Class
An INTERLIS class may define multiple attributes of type geometry.
ili2fme maps the first geometry of the INTERLIS class to the FME geometry of the feature. Any additional INTERLIS geometry attributes are mapped to existing FME attributes. The value of these attributes (attribute b in the diagram above) is HEX-encoded OGC WKB (this can be changed with the parameter Geometry Encoding) and can be extracted from that attribute to the feature geometry with the GeometryReplacer transformer or set with the GeometryExtractor transformer.
INTERLIS 1 Area
INTERLIS 1 encodes attributes of type AREA in helper table prior to the main table. ili2fme can read these attributes in three modes:
- build polygons/donuts automatically from the line table
- read the main table and the line table as they are in the transfer file
- combination of the two cases above
Automatic polygon building works only, if the AREA attribute is the first geometry attribute of the INTERLIS table.
With automatic polygon building, the mapping is as follows:
With automatic polygon build disabled, the mapping is as follows:
INTERLIS 1 Surface
INTERLIS 1 encodes attributes of type SURFACE in helper table following the main table. ili2fme can read these attributes in three modes:
- build polygons/donuts automatically from the line table
- read the main table and the line table as they are in the transfer file
- combination of the two cases above
Automatic polygon building works only, if the SURFACE attribute is the first geometry attribute of the INTERLIS table.
With automatic polygon building the mapping is as follows:
With automatic polygon build disabled, the mapping is as follows:
The line table (ModelA.TopicA.ClassA_a_LT) gets an additional attribute (with the name of the main class; in this case _itf_ref_ClassA) that is a reference from the lines to the feature in the main table (ModelA.TopicA.ClassA_MT).
INTERLIS 2 Incremental Transfer
INTERLIS 2 supports incremental transfers (change only transfers). Incremental transfer happens per basket. There are two kind of incremental transfers: INITIAL and UPDATE. INITIAL is the first transfer in a series of transfers. It includes all objects. UPDATE is used for all succeeding transfers following INITIAL and includes only changed objects since the last transfer. Both kinds require additional format attributes.
For an INITIAL data transfer, the XTF_BASKETS feature that represents the basket has a value in the xtf_endstate attribute. The xtf_startstate” attribute should not be set. There are no XTF_DELETEOBJECT features. The xtf_operation attribute should not be set.
For an UPDATE data transfer, the XTF_BASKETS feature that represents the basket has a value in the xtf_startstate and the xtf_endstate attribute. The xtf_startstate value is the same as the xtf_endstate of the last transfer of that basket. The xtf_operation attribute should be set to INSERT, UPDATE, or DELETE. Instead of mapping deleted objects to ordinary features with xtf_operation set to DELETE, they may alternatively be mapped to instances of the format feature type XTF_DELETEOBJECT (without any INTERLIS attribute values; just xtf_id and xtf_basket).
Inheritance Mapping Strategy
ili2fme supports two inheritance mapping strategies. The appropriate strategy depends on your INTERLIS model.
Superclass Strategy
Attributes of non-root classes are shifted to the root, as illustrated by the following figure:
The format attribute xtf_class may be used to determine if a feature is an instance of class ModelA.TopicA.ClassB or class ModelA.TopicA.ClassC.
Subclass Strategy
Attributes of base classes are shifted to leafs, as illustrated by the following figure:
There is no feature type ModelA.TopicA.ClassA because it is an abstract class in the INTERLIS model.
Enumerations
There are two modes to read enumerations:
- SingleType will read all elements of all enumerations with the same FME feature type XTF_ENUMS.
- OneTypePerEnumDef will create one FME feature type for each enumeration type.
Enumerations as a Single Feature Type
For the feature type XTF_ENUMS, the following features will be read:
One Feature Type per Enumeration
For the feature type ModelA.TopicA.Color, the following features will be read:
BAG/LIST OF
INTERLIS structure attributes (in the example the attribute color in the class Car) are mapped to FME lists. The definition of the INTERLIS structure (in the example, the structure Color) is not mapped as a FME feature type. The type of the structure element is defined by the value of the attribute xtf_class (similar to the class type of objects; see Superclass Strategy), which is mandatory to be set.
In the example above, the list attribute color{0}.xtf_class therefore has the value ModelA.TopicA.Color.
Format Attributes
In addition to the generic FME feature attributes that FME Workbench adds to all features (see About Feature Type Attributes), this format also adds format-specific attributes (Format Attributes).
|
Attribute |
Description |
|---|---|
|
xtf_basket |
Value of the BID XML-attribute out of the INTERLIS transfer file. May be used as foreign key to a feature of the feature type. XTF_BASKET (see below). On writing, this may be used to write multiple baskets of the same topic. If writing INTERLIS 1 transfer files, this attribute is not required. |
|
xtf_class |
Qualified name of the INTERLIS class name. This is different from the feature type name in the case of non base classes. In the figure above would ModelA.TopicA.ClassB be a possible value. If this value is not set, the feature type name is used as the qualified INTERLIS class name. |
|
xtf_consistency |
Only used for somehow modified data. Not yet fully supported. |
|
xtf_geomattr |
Deprecated: Name of the geometry attribute read (for example, Geometrie). An INTERLIS class may define multiple geometry attributes. |
|
xtf_id |
Value of the TID XML-attribute out of the INTERLIS transfer file. Unique across all feature types. |
|
xtf_operation |
Only used for incremental INTERLIS 2 transfer. Possible values are: INSERT, UPDATE, DELETE. |
Format Features
The reader creates additional feature types, and the writer expects this feature types as well. If writing INTERLIS 1 transfer files, these feature types are not required.
XTF_BASKETS
|
Attribute |
Description |
|---|---|
|
xtf_id |
For each basket in the INTERLIS 2 transferfile, the value of the BID XML-attribute. |
|
xtf_topic |
Qualified name of the INTERLIS 2 topic name. In the figure above would ModelA.TopicA be a possible value. |
|
xtf_startstate |
Only used for incremental INTERLIS 2 transfer. If set, it indicates an UPDATE transfer. It indicates an INITIAL transfer, ifit is not set. If it is not an incremental transfer, the value is ignored. |
|
xtf_endstate |
Only used for incremental INTERLIS 2 transfer. If set, it indicates an incremental transfer. If it is not set, this is not an incremental transfer. |
|
xtf_consistency |
Only used for somehow modified data. Not yet fully supported. |
XTF_DELETEOBJECT
|
Attribute |
Description |
|---|---|
|
xtf_id |
Value of the TID XML-attribute out of the INTERLIS transfer file. Unique across all feature types. |
|
xtf_basket |
Value of the BID XML-attribute out of the INTERLIS transfer file. May be used as foreign key to a feature of the feature type XTF_BASKET. On writing, this may be used to write multiple baskets of the same topic. |
XTF_ENUMS
This feature type is only created by the reader, if the parameter Create Feature Types For Enumerations is set to SingleType.
|
Attribute |
Description |
|---|---|
|
thisEnum |
Qualified INTERLIS name of the enumeration definition of this element. |
|
baseEnum |
Qualified INTERLIS name of the base enumeration definition of this element. This is only set, if the enumeration is EXTENDED. |
|
iliCode |
Qualified INTERLIS Name of the enumeration element. Same as it would appear in an INTERLIS 2 transfer file (XTF). |
|
itfCode |
Code of the enumeration element as it would appear in an INTERLIS 1 transfer file (ITF). |
|
seq |
Ordering position of the element. Only set, if this enumeration is ORDERED. |
XTF_ERRORS
Errors from the reader.
|
Attribute |
Description |
|---|---|
|
iliname |
Qualified name of the INTERLIS 2 model element that is related to the message. |
|
message |
Error message |
|
tid{} |
TID/OIDs of the objects related to the message. |
XTF_TRANSFER
Content of the INTERLIS 2 transfer file header section.
|
Attribute |
Description |
|---|---|
|
oidspace{} |
Content from the <OIDSPACES> element from the header section of the transfer file. |
|
oidspace{}.name |
For each OID domain used in this INTERLIS 2 transfer file, an alias name (as used in this transfer file). |
|
oidspace{}.oiddomain |
Qualified name of the INTERLIS 2 OID domain definition. |
|
comment |
Content of <COMMENT> element from the header section of the transfer file. |
Limitations
- custom line forms
- XTF line attributes
- recursive structure attributes