Geopackages and different polygon types in same layer ?

Instead of modifying my geometry, I‘ve had very good results setting the geometry type to geopackage_geometry. Essentially that allows all sorts of mixed geometry, but is really helpful when dealing with polygons and mult-polygons and aggregate polygons.

Thanks s.jager. I hadn’t noticed the spatial definition option.

Luckily I can switch to manual attribute definitions, which is requirede to change the spatial definition.

But now it at least accepts any geometry type inserted - Yay!

However, after I’ve created the geopackage, and dumps it into QGIS, QGIS claims that two features are acually geometrycollections. These are two of the unaltered original fme_aggregate geometries. And it again strips the geometry off the features, as if QGIS cannot handle geometrycollections.

In the fmeobjects dox for (FMEFeature) getGeometryType and setGeometryType there’s no GeometryCollection, only FME_GEOM_AGGREGATE.

Is the GeoPackage writer doing some dark magic to these geometries, and if so, what triggers it ? And how can one tell this in advance to do something about it ?

I suspect it’s the two larger polygons with multiple holes that are designated as geometrycollections.

Oh. Ouch. Geometry Collections are a nightmare. They might happen because of an arc in a polygon definition for example, or other such things, but there’s no surefire way of intercepting them in FME unfortunately.

But, if you check this thread: Aggregated surfaces written in wrong file format in SQL server | Community, you can find my solution of dealing with them. Not a 100% guarantee, but it seems to fix most of my geometry collections.

I’ve created an Idea to add Geometry Collections to the GeometryFilter. If you can catch them like that, it would make a difference.

Ah, the old buffer-out/buffer-in approach. Good call ​@s.jager 

I went and took a hard look at the original zone data, which the municipalities provide here, so they’re of (very) varying quality. I try to aggregate+dissolve these in advance, and the smaller of the previously collectionized polygons had 63 holes from the outset, primarily due to sloppy registration work from the muncipality (adjacent polygons with unmatching common borders).

I now added the buffering solution, and reduced that to 3, although I had to go up to 1 meter to get there.

I’m running the calculations again, and will try to convert the output to a geopackage, and see whether that’ll eliminate the problem.

These are judicial zone boundaries I’m working with, but for this current purpose, I hope it’ll be ok.

Cheers.

Alas, buffering only solved some of the problems. The low quality zone handling was solved, but the larger aggregate remains, and its geometry is still being stripped away in QGIS.

This geometry is an fme_aggregate with 110 parts. As far as I can see, it’s a mix of FMEPolygon and FMEMultiArea. Nothing seems problematic.

I wonder whether there’s a limitation of parts ? E.g. 100 ?

Cheers.