Answer
Description
INTERLIS is a standard which has been especially composed in order to fulfil the requirements of modelling and the integration of geodata into contemporary and future geographic information systems. The current version is INTERLIS version 2 (english). INTERLIS version 1 remains a Swiss standard. With the usage of unified, documented geodata and the flexible exchange possibilities the following advantage may occur:
- the standardized documentation
- the compatible data exchange
- the comprehensive integration of geodata e.g. from different data owners.
- the quality proofing
- the long term data storage
- the contract-proof security and the availability of the software
INTERLIS fulfils the above mentioned requirements. Consequently the discussion of interfaces about fixed formats and open programm interfaces (APIs) and interfaces leads to the question which type of geodata we want to capture and maintain. INTERLIS is not only targeting the mass market of the casual geodata viewers but was especially designed as and answer to the needsof the users and producers (the doers) who are relying on explicitly described geodata structures. Additional properties of this language are: the special adaption to geographic informations systems implementability and practicability and the extensibility.
ili2fme
ili2fme is an Open Source FME Plugin for reading and writing data according to the Swiss Standard For Geodata Exchange "INTERLIS".
This page aims to describe how to give some help to use the plugin.
What it does
ili2fme can:
- Read and Write INTERLIS1-Data
- Read and Write INTERLIS2-Data
Latest changes
ili2fme 5.3.2 (2011-01-26)
- java.lang.NoSuchMethodError: ch.interlis.ili2c.metamodel.Constant$Numeric.getValue()D
- iox-ili-1.5.4
ili2fme 5.3.1 (2011-01-17
ili2fme 5.3.0 (2010-12-29)
- support http proxy (new params HTTP_PROXY_HOST, HTTP_PROXY_PORT)
- itf reader: skip/ignore missing 3rd value of a coord
- bug itf reader: skip space after 'CONT'
- reader: return exception to FME to enable error detection by FME
- ili2c-4.3.3
- iox-ili-1.5.3
- test result of ili1 polygon building (new param ILI1_CHECKCONVERT)
- new, not yet implemented, params CHECK_ATTRTYPE, CHECK_ATTRMULTIPLICITY
Where to find it
- In FME 2011 SP1, the version 5.3.1 of ili2fme is included in the standard version.
- More recent versions are available from here.
How to install it
- To install the new version, the content of the folder "FME Suite" has to be copied to the FME_HOME directory (e.g. c:\program files\fme)
(Since version 4.9, an msi windows installer is available. It installs the plugin into your FME_HOME directory.
- To use the plugin, a Java Virtual Machine has to be installed on your PC. A minimum version of Java 1.5 is recommended.
Reading INTERLIS1 Data
To read INTERLIS1 Data, the data model (.ili) must be known to FME.
It can be stored:
- in %fme_home%\plugins\interlis2\ilimodels
- in a special model directory you specify
- in the same directory than your data
Then you can select an INTERLIS1-Data-File (.itf) and open it with FME (Viewer, Workbench, Universal Translator) and use it.
- All the enumerations from the ITFs will be converted to texts (values), unless you specify that you want to use codes.
- If more than one geometry exists, the first geometry will be used as FME geometry, the other ones will be stored as Hex Well Known Binary in Attributes.
Reading INTERLIS2 Data
Reading INTERLIS2 - Data is essentially the same than reading INTERLIS1-Data with the following differences:
- The data comes in XTF - Files (and not ITF-Files)
- If your data-models contains EXTENDS, FME will show all the data in a single "superstructure" - feature type. You will have to use an AttributeFilter on XTF_CLASS to separate the different classes in Workbench. Since v. 4.4.0, the data model may also be imported with a "subclass"-strategy rather than a superclass strategy. When "subclass" is chosen, a feature type is created for each concrete extended class, whereas one feature type is created per parent object when "superclass" is chosen.
Writing INTERLIS1 Data
To write INTERLIS1-Data, the process is the following
Prerequisites: the INTERLIS Model (.ili) has to exist before!
- Set up a Workbench
- Define an "Swiss INTERLIS (ili2fme)” Writer
- Import the FeatureTypes from your ILI-Model (Writer -> Import FeatureTypes -> Browse to your ILI-File)
- Define a transfer identification for each feature, by setting the format attribute "xtf_id" (e.g. generate it with a counter or map a format attribute like OBJECTID / FID or similar)
- Route your features to this featuretype (connect the arrows)
- GO!
Writing INTERLIS2 Data
To write out INTERLIS2-Data, you will have to follow these steps in addition to the ones explained for INTERLIS1:
- Create one feature of feature type “XTF_BASKETS” for each TOPIC (With a Creator / NullGeometryCreator + AttributeCreator)
- Reference this basket in each feature type of the topic, by setting the format attribute "xtf_basket" (e.g. by attaching a constant)
- Write all herited classes to a "superstructure" feature type. (or choose a subclass-strategy)
- Define the qualified INTERLIS class name of each class, by setting the format attribute "xtf_class" in each feature type
Please note, that:
- “XTF_BASKETS” features must be created by hand in a common transformation with an INTERLIS 2 writer.
- “xtf_basket” format attributes must be set by hand in a common transformation with an INTERLIS 2 writer.
- You always need to provide fully qualified class names of the target INTERLIS model. For example, the correct parameter might be: "Fallbeispiel.Raumplanung.Bauzone".
- If the “xtf_class” format attribute is set, its value supersedes the name of the feature type. This may lead to unexpected results if your features come from an INTERLIS dataset, and “xtf_class” is still set (to the source class instead of the target class).
List Handling
In INTERLIS2, there can be lists, such as "BAG OF", "LIST OF", STRUCTUREREF.
In this case, an FME - list is given to every INTERLIS-feature. In the example below, there is an illustration about how to work with these lists.
Examples
There are two examples here:
A General one illustrating how to
import data from an ITF to an ESRI Geodatabase (MDB)
export data from the ESRI Geodatabase to an ITF
The data is the freely available testdataset from swisstopo's VECTOR25. The Geodatabase schema has been generated with
iliX.
List-Handling
This example show how to work with lists in INTERLIS2
Problem Solving
This Q and A was taken from an actual Safe Support email discussion and is intended to provide a "knowledge base" for xyz->ili, ili->xyz and ili->ili transformation applyers in order to help others who might have similar challenges.
Q) In some cases the log appeared to complete successfully, but then when I tried to open the output.xtf all FME viewer could read was the single xtf_basket feature.
A) In the end, that's what FME did actually right: not finishing the transformation until all input features are correct...
Q) What format attributes need to be populated? I exposed all the xtf_* format attributes on the reader and writer feature types to make sure they were being populated (xtf_basket, xtf_class, xtf_geomattr).
A) Actually, according the manual, only XTF_Basket attributes must be created by hand in a common transformation with an Interlis writer. Depending on what format transformation one carries out, (e.g. ili->shp) the xtf_geomattr geometry attribute must be exposed and a constant (i.e. the geometry type name) must be attached to it. In other cases, such as ili->ili semantic transformations, the xtf_class format attribute needs to be exposed and filled with the qualified target-model class-name by hand.
Q) I added xtf_geomtype to all the destination classes and set it using a GeometryFilter and AttributeCreator.
A) Perhaps it is only necessary to expose the xtf_geomattr when you carry out a XYZ->ili transformation (e.g. shp->ili) because the inner geometry model of shp is completely different form the one in Interlis (geometry = "normal", i.e. structured class attribute; classes may as well have no geometry at all...).
Q) Is the XTF_Basket feature supposed to have an xtf_topic value of 'Features' or 'Beispiel_ILI2_Model.Features' or 'Beispiel_GINA_Model.Features'?
A) You always need to provide fully classified names of the target model. In this example, the correct parameter would be:"Beispiel_ILI2_Model.Features". In the modified model, it would be "ILI2Model.Features", respectively. Source model (reader): Beispiel_GINA_Model (new version: GINAModel) Target model (writer): Beispiel_ILI2_Model (vew version: ILI2Model)
Q) Why do we need to write to feature types = Beispiel_ILI2_Model.Features.polnum etc and not Beispiel_GINA_Model.Features.polnum etc?
A) Because we have to write to the target model which is called "Beispiel_ILI2_Model.whatever" or "ILI2Model.whatever" in the new version.
Q) Why doesn't a straight across translation work? That is, read from input.xtf and write to output.xtf with all feature types mapped directly across XTF_BASKETS to XTF_BASKETS ModelA.TopicA.ClassC to ModelA.TopicA.ClassC etc?
A) It should work if the source data is ok. You can try a new tool from Claude's, which is particularly designed for Interlis 2 datasets and models. This new (beta-status) tool can check the references correctly and help you find out what is wrong with the data...
Q) What is the purpose of the PointOnArea overlay given that none of the output geometry types are supposed to be areas?
A) Input features consist of a set of polylines that are to be transformed into area tesselation borders. The point features are actually the centroids of these areas and carry all thematic information. So, the PointOnArea overlay combines the area borders with the appropriate thematic information from the former centroid features.
[ Remark: if you use an Interlis 1 writer which produces a data file in the old Interlis 1 format, you actually would have needed the ceontroid coordinates at the end because the "old" tesselation encoding consists of a table with the area borders and another table with the appropriate centroid coordinates carrying all thematic information. The relation between borders and centroids would in this case not be explicit, but geometric. ]
Q) Are the xtf_class names supposed to be the same as the source fme_feature_type or does the 'Beispiel_GINA_Model.Features' need to be changed to 'Beispiel_ILI2_Model.Features'?
A) Yes, the names need to be changed according the target data model.
Q) Do both models need to be referenced in the writer parameter: 'Models'? Currently only Beispiel_ILI2_Model is referenced, but not Beispiel_GITA_Model.
A) In ili2fme, the source model-name is read from the dataset. Each feature element starts with the qualified class name. Hence, the data model must have the same name.
Q) Did we import the schemas from the destination model directly, or should we generate the destination feature types based on the input schemas?
A) Import the target schema via "Destination... -> Import Feature Type Definition"-dialog and generate the feature type from the input schema.
Q) Why don't we have any destination geom feature types? I tried adding Beispiel_ILI2_Model.Features.gebaeude_geom and Beispiel_ILI2_Model.Features.bauzone_geom but was not able to get the translation to complete.
A) In an Interlis model, the geometry is basically a normal feature attribute. The two classes you mentioned above are normal classes as the others. They are not 'geometry types' as is. So, any Interlis class may or may not carry geometry type attributes (in the models the keywords are: COORD, POLYLINE, SURFACE and AREA.
Q) Overall, is getting this to work is largely a configuration issue?
A) Well, after all it depends much on input feature quality... But you need to know two or three "tricks" to get an Interlis translation successfully realized.
One suggestion - if you use AttributeCopiers and AttributeCreators to set things like xtf_class, then you dont need to reconnect them every time you edit your workspace - the xtf_class will stay green meaning it will stay populated without having to manually connect the fields again.