In some instances geometry is being unexpectedly dropped when writing to a MapInfo writer. This occurs when FME has a conflict with the Format Attribute of 'mapinfo_type' which has been attached to a feature from a non-mapinfo source such as SQL Server Spatial. The conflict arises when the mapinfo_type is point or line but the feature it has been passed to is a polygon. Sorry I don't have enough reputation to post an image of a simple workbench so hope the URL works or the following description:

Example workbench

Description: It will happen if we use a SpatialRelator transformer to perform a simple 'point INTERSECTS polygon' exercise. If the base polygon features come from a SQL Server Spatial reader but the point candidates originate from a native MapInfo reader the 'mapinfo_type' format attribute of the points is transferred to the base polygon features (as this attribute did not already exist on the base feature). The result when writing out to a MapInfo writer is that FME sees a mapinfo_type of point on a feature which is actually a polygon and drops the geometry of any polygons that intersected.

We've worked around it by the following:

  1. Write to SQL Server instead, or if native Mapinfo output is required do any one of the following:

  2. Expose mapinfo_type on any offending MI input datasets then remove it just prior to writing to output,or,

  3. add a Geometry_Coercer transformer to the MI input dataset and force it to polygons.

Any comments on better solutions?

  • I was going to suggest a geometry_coercer. But it looks like that's working for you already. What do you see when you output to an inspector?
    – Fezter
    Aug 8, 2013 at 4:19
  • Suggestion: Switch out the SpatialRelator for the FeatureReader and use the INTERSECTS option then introduce a PointOnAreaOverlayer.
    – Mapperz
    Aug 8, 2013 at 17:43
  • When I switch the output to an inspector all the polygons are there indicating there is nothing wrong with the FFS format and the problem lies in the mapinfo writer. Aug 13, 2013 at 5:24
  • I tried switching out the SpatialRelator for the FeatureReader but canned it part way thru due to performance issues. I'm intersecting 30,000 polygons with 700 points. The spatialRelator takes less than a minute and the FeatureReader (with intersects) outlasted my curiosity and patience. So can't report back on if it avoided the problem. Aug 13, 2013 at 6:10

1 Answer 1


If you put an AttributeExpressionRemover before the SpatialRelator candidate port then you can use it to remove all incoming attributes starting with "mapinfo". That should prevent anything untoward being copied across.

  • Thanks Mark, It still requires us to expose the offending mapinfo format attribute (there's only one - mapinfo_type). As a better solution we settled on removing that attribute just before the tab writer rather than after the reader as in our case we had lots of readers but only one writer. Ideally if there's a conflict between the ffs geometry (correct) and the attribute of mapinfo_type (incorrect) it would be better if FME ignored mapinfo_type rather than dropping the geometry. Is this something that could be achieved within the MapInfo writer? Even as a tick box the user could control? Aug 21, 2013 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.