8

I'm migrating data from Smallworld via FME/SpatialBiz Plugin to a PostgreSQL/PostGIS Environment and then trying to open the resulting tables with QGIS 2.12.1. Problem arises, because Smallworld supports multiple geometries per record and for areas it does not really differ between curvepolygons, multipolygons, donuts,... and simple polygons as well.

Basically my FME process (which deaggregates multiple geometries and only keeps 'area geometries' [synonym for any kind of polygon in Smallworld] of a special name) runs without errors, but when opening the PostGIS tables in QGIS I get two entries for each table (see below), one of which with a defined spatial type (CurvePolygon for example), the other lets me select the geometry type manually.

Added:

SELECT * FROM public.klrg_statistik_bezirk WHERE ST_isValid(geom) <> true

Gives me an error: Unknown geometry type: 10 - CurvePolygon

Strange behavior adding postgis layers in QGIS

No matter if I do so or not, I'm getting the following error (warning rsp.):

Error referred to above

("Unsupported geometry type 'unknown type' in layer '...'") ... which pops up again and again when adding other layers, reopen the QGIS-project and so on.

Strangely, the data seems to be displayed correctly in QGIS, as you can see here:

enter image description here

At first sight, no problem comes up, when editing these PostGIS data QGIS, but I'm not quit shure if no issues arise in the future.

In the FME process i tried to fix this by exposing the format attribute 'postgis_type' and setting its value to 'postgis_multisurface' for example as lined out in the FME postgis writers documentation (I think multisurface is the geometry type of choice when polygon types of any kind come mixed up all together ...).

Exposing format attribute in the PostGIS write feature type properties

Setting postgis_type to 'postgis_multisurface' via AttributeCreator transformer

My questions are: How do I have to interpret this behaviour of QGIS? Might there be a way to fix this in FME at all, or is some postprocessing in PostGIS required? What kind? And are these the right questions at all?

Edit: Added screenshots of FME workspace

FME Workspace left part with SpatialBizPlugin reader / transformers

FME Workspace left part with SpatialBizPlugin reader / transformers. Note what the Deaggregators / GeometryPropertyExtractors / Testers do!

FME Workspace left part with Geometry validators / PostGIS writers

FME Workspace right part (directly behind AttributeKeeprs). Note that all features pass the GeometryValidators!!!

... which are configured like this:

GeometryValidator configuration

Improve this question
3
  • It would be helpful to see a screenshot of your FME model. Especially where you are filtering the geometry types.
    – Fezter ♦
    Mar 4, 2016 at 0:39
  • I'm going to post one monday, but it's simply Deaggregator > GeometryPropertyExtractor (Extract _geometry_name) > Tester (Test for _geometry_name = 'flaeche' for example). These are only of 'area' geometry type (not 'simple_area', Smallworld speaking), wich covers any kind of polygons (cp. above).
    – Jochen Schwarze
    Mar 4, 2016 at 15:23
  • 1
    Additional hint: Evaluated for OGC validity and the usual geometry issues like duplicate consecutive points, self intersecting... with GeometryValidator, all features passed the tests.
    – Jochen Schwarze
    Mar 4, 2016 at 16:25

1 Answer 1

Reset to default
5

A solution to this issue is to cut the features in line segment with 2 vertices each with the Chopper transformer and then rebuild areas using the AreaBuilder (in case of multipolygon input this results in ambiguous id's the areas are built of, the Aggretgator transformer makes multipolygons again).

Since building areas results in loss of attributes, the attributes can be retrieved from the input features via FeatureMerger.

As a result i got straight (multi)polygons in my PostGIS (no curvepolygons anymore).

Using ArcStroker transformer is not necessary since the Chopper ist doing the segmentation on arc segments.

https://www.safe.com/transformers/chopper/

Edit:

And in addition here is another answer to the fme postgis writer issue. To prevent the writer from creating generic geometries, we have to already set the write directive 'create generic geometry column' to false when adding the writer as shown below ....

enter image description here

... in order to explicitly define the geometry type for each feature type:

enter image description here

Improve this answer
3
  • Do you lose the true arc/curve geometries in this case (aren't they just approximated)?
    – Evil Genius
    Mar 16, 2016 at 19:23
  • 1
    Yes I do. But that is a valid workaround in my opinion, since approximated curves are totally ok in my application. It's more about scales below 1:2500, and you have to zoom much closer to be aware of the approximation. The Chopper does a very good job on this :-)
    – Jochen Schwarze
    Mar 16, 2016 at 19:28
  • 1
    If the curves are to be preserved, additional research would be required about writing curvepolygons to PostGIS with FME. I'm working on this.
    – Jochen Schwarze
    Mar 16, 2016 at 19:30

Your Answer

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

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