[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