+1 Handling multiple geometries is a need.

I've encountered a bug when dealing with Postgis mutliple geometries table which requires to specify which geometry is taken into account, otherwise FME loses geometry :

https://github.com/qwat/qwat-data-model/issues/265

This may help:

https://knowledge.safe.com/articles/24702/handling-data-that-contains-multiple-geometry-colu.html

However yes, a more intuitive way would be greatly appreciated by many of us.

See also duplicate Idea: https://knowledge.safe.com/idea/117563/native-support-for-postgresql-multiple-geometry-co.html

One of the advantages of PostGIS is that it can handle multiple geometry columns in the same table. For example and a polygon area of interest, then the gradual erosion of that AOI which regard to image collection, etc. Should not have to choose one or the other, in my opinion.

I now too have this challenge whereby the table holds multiple geometries. Coming from Oracle Spatial and seeing how easy it works with FME I was surprised Safe has not implemented the same for PostGIS

I realise this idea relates to the PostGIS Reader, but it would also be good if PostGIS Writer could write to multiple geometry columns.

I tried the workaround at https://community.safe.com/s/article/template-write-multiple-geometry-types-to-an-exist, but writing the second geometry column is extremely slow, as bulk insert for this writer is switched off during translation (the following warning message is received):

POSTGIS Writer: Bulk Insert is set to Yes, but a conflicting Feature Operation has been detected. Feature type 'rc_srb.srb_01' has a Feature Operation of 'Update'. Bulk Insert is now being set to No, which can cause insert operations to be much slower

As a result, the timings for writing a dataset of 130,000 features is as follows:

• 1st geometry column – 1 minute
• 2nd geometry column – 42 minutes