[gdal-dev] OGR C API PostGIS geometry with wrong field entries

Andreas Oxenstierna ao at t-kartor.se
Mon Dec 2 23:25:11 PST 2019


I am no Postgre expert but we have experienced similar cases when 
running complex transactions with large geometries, i.e. faulty results.
When splitting the transaction into several pieces, i.e. enforcing 
COMMITs (Postgre doesn't support COMMIT inside functions), the correct 
results are given.
One guess is that this may happen for large geometries which are pushed 
to TOAST tables.

Check Postgre memory parameters and trace exactly what is happening in 
the database.
Test also with EXTERNAL STORAGE for the geometry if they are really large.


> In the GRASS module v.in.ogr we follow pretty much the vector API 
> tutorial. The only difference is that we first fetch the geometry of a 
> feature, then the fields. When input is a PG database, sometimes the 
> wrong field entries are associated with the geometries, as if 
> geometries and field entries were mixed up. This happens when several 
> different v.in.ogr processes are trying to read the same features from 
> the same PG database at the same time. When instead using several 
> different ogr2ogr processes, this mixing up of geometries and field 
> entries does not happen. I could not find any hints in the OGR PostGIS 
> documentation about how to avoid this problem.
>
> Any hints are highly appreciated!
>
> Markus M
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Hälsningar

Andreas Oxenstierna
T-Kartor Geospatial AB
Olof Mohlins väg 12 Kristianstad
mobile: +46 733 206831
mailto: ao at t-kartor.se
http://www.t-kartor.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191203/3ba46b7f/attachment.html>


More information about the gdal-dev mailing list