Skip to main content
  • EN

This is very country-specific as Interlis is only used in Switzerland, and FME relies on a plugin (Eisenhut) to read/write Interlis-Data.

I have done a lot in Interlis1 (ASCII), which always worked like a charm.

 

No I am on my first Interlis2 (XML) project, which also worked fine just to this problem.

FeatureTypes and their attributes in Interlis are set by an Interlis Model (*.ili).

 

In this model there is also set which "attribute" is used to store the geometry per featuretype.

 

So, e.g. a line in interlis stores its geometry in the attribute "Lage" (which stands for "position" translated in English)

For the Labels, I now have two Classes "InfrastrukturHaltung_Text" and "InfrastrukturKnoten_Text".

 

For this Label-Classes the defined attribute for geometry is "Textpos" (stands for "textposition").

 

 

My problem now is, that after importing these two featuretypes, FME always writes them without the geometry attribute. There is no way I could think of to predefine the geometry-attribute in the workspace

 

or per featuretype. This information completely relies on the model-file (see attachment).

I tried the deprecated "xtf_geomattr" to tell FME to write the geometry into the right attribute, without any success.

Also funny thing is, that the other FeatureTypes work without any problem.

Any advice? Thx, and best regards, Chris.

Unfortunately, debugging Interlis issues can be very time consuming. Could you perhaps post a minimal workspace here that allows us to reproduce the issue?

Sure... the label-classes are at the bottom...

AG64_Interlis2.fmw

Writing ILI2 in FME is way more complex than ILI1. I suggest some reading like the tutorial from swisstopo (https://www.geo.admin.ch/de/geoinformation-schweiz/geobasisdaten/geodata-models.html -> "Downloads" section, "Hilfsmittel für die Geodatenmodellierung").

The first thing I noticed in your workspace were the missing attributes xtf_basket and xtf_class. These are essential when writing to ILI2 to tell ili2fme to which basket and class the features belong to. You will find more information about these attributes in the tutorial mentioned above.

Regards, Stefan

Writing ILI2 in FME is way more complex than ILI1. I suggest some reading like the tutorial from swisstopo (https://www.geo.admin.ch/de/geoinformation-schweiz/geobasisdaten/geodata-models.html -> "Downloads" section, "Hilfsmittel für die Geodatenmodellierung").

The first thing I noticed in your workspace were the missing attributes xtf_basket and xtf_class. These are essential when writing to ILI2 to tell ili2fme to which basket and class the features belong to. You will find more information about these attributes in the tutorial mentioned above.

Regards, Stefan

Hello Stefan,

Thx for your input, unfortunately I had a look at the Eisenhut Informatik Manual.

 

xtf_class attribute is not necessary if the "Sub-Class" approach is used instead of "SuperClass".

 

In that case, the featureTypes need to have the exact class-names as specified in the model.

I also think, that the basket-stuff is optional. (in case only one basket is used).

I already checked the output XTF in IGchecker, and got no errors except the mentioned ones concerning the labels not having the geometry attribute "Textpos".

Maybe I should consider trying out the basket-stuff, though I doubt it will have an effect on my problem. All the other classes are written 100% correct.

thx again, best regards, Chris.

Hello Stefan,

Thx for your input, unfortunately I had a look at the Eisenhut Informatik Manual.

 

xtf_class attribute is not necessary if the "Sub-Class" approach is used instead of "SuperClass".

 

In that case, the featureTypes need to have the exact class-names as specified in the model.

I also think, that the basket-stuff is optional. (in case only one basket is used).

I already checked the output XTF in IGchecker, and got no errors except the mentioned ones concerning the labels not having the geometry attribute "Textpos".

Maybe I should consider trying out the basket-stuff, though I doubt it will have an effect on my problem. All the other classes are written 100% correct.

thx again, best regards, Chris.

You are right, the xtf_class is only necessary if the FME output feature type name doesn't match the Interlis class you're writing to, e.g. when writing to abstract classes etc.

The xtf_basket attribute is only necessary if you also write to the XTF_BASKET feature type.

In short, neither are mandatory for simple exports.

Sure... the label-classes are at the bottom...

AG64_Interlis2.fmw

Thanks, but since I cannot access the input data, I also cannot reproduce the issue. Can you perhaps extract a part of the data to FFS or some similar file-based format that can be posted here?

Any news here? Sorry for not getting back so long. I was on holidays...

Any news here? Sorry for not getting back so long. I was on holidays...

Since we do not ave access to your Oracle instance we cannot execute the workspace to try and reproduce the issue. Could you please post a minimal workspace here with the accompanying data, e.g. in a File Geodatabase.

In the end, the problem was related to the FME build (2019.2 Beta Build 19724).

After downgrading to stable 2019.1 the Label-Features were written WITH geometry.

memo to myself: First try a stable FME build when having problems with the FME "blackbox"...

In the end, the problem was related to the FME build (2019.2 Beta Build 19724).

After downgrading to stable 2019.1 the Label-Features were written WITH geometry.

memo to myself: First try a stable FME build when having problems with the FME "blackbox"...

That's very interesting, thanks for sharing!

Community Stats

31,956
Posts
121,348
Replies
39,566
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.