+4
Hi,
I am sending 2600 features to a PostGIS FeatureWriter. When I look in the resulting table (which was completely empty) I see 2628 rows. How is this possible?
I noticed it because first I had a primary key defined and I was sure there were no duplicates in the 2600 features, but I got an primart key violation error After removing the primary key I see several duplicates.
Any ideas on how to solve this? Or did I find a bug?
+16
Hi Arno,
Have you tried replacing the FeatureWriter by the PostGIS writer to see if that results in the same?
Erik Jan
+4
Hi Arno,
Have you tried replacing the FeatureWriter by the PostGIS writer to see if that results in the same?
Erik Jan
Yes, I tried that. No diference between the Feature Writer and the PostGIS writer.
I did find something else: it seems to go wrong for some records without geometry. When I send only records with geometry the number of features send and records in the database are the same.
You should also know that the table has 2 geometry columns. With this first FeatureWriter I try to fill all the attributes and one geometry column with inserts. In a next FeatureWriter I do an update to fill the other geometry column.
+2
@arnovananrooij if you could include your data and workspace along with your log file, we can take a look and try and see where things are going wrong
+16
Yes, I tried that. No diference between the Feature Writer and the PostGIS writer.
I did find something else: it seems to go wrong for some records without geometry. When I send only records with geometry the number of features send and records in the database are the same.
You should also know that the table has 2 geometry columns. With this first FeatureWriter I try to fill all the attributes and one geometry column with inserts. In a next FeatureWriter I do an update to fill the other geometry column.
Have you checked the number of records after the initial insert to see if the update is causing the issue?
You can add the StatisticsCalculator and a Logger to list the number of records.
My go-to solution is to read the data back in again, then use the ChangeDetector or Matcher with the source data to isolate the differences. That usually explains what happened.
By the sound of it, you might have aggregate geometries that aren't supported in the target table definition, and FME trying to be helpful deaggregating them automatically. Look for those types of messages in the FME log. Could potentially be PostGIS doing this as well, come to think of it.
+4
My go-to solution is to read the data back in again, then use the ChangeDetector or Matcher with the source data to isolate the differences. That usually explains what happened.
By the sound of it, you might have aggregate geometries that aren't supported in the target table definition, and FME trying to be helpful deaggregating them automatically. Look for those types of messages in the FME log. Could potentially be PostGIS doing this as well, come to think of it.
It seems that all the records with geometry don't create extra records, but some of the ones without geometry cause. I fixed it by sending the ones without geometry to a PostgreSQL FeatureWriter. Idon't think it should be necessary but it works.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
