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

Markus Metz markus.metz.giswork at gmail.com
Tue Dec 3 12:44:43 PST 2019


Thanks for your feedback! I think I figured it out. The GRASS module
v.in.ogr goes through the input features twice, but only for polygons. This
is needed to properly convert non-topological polygons to topological areas
in GRASS. The order of features can be different between the first and
second pass through the input features. We are now using FID to map
features in the second pass to features in the first pass. This solution is
not ideal because in between the two passes, features might be added or
deleted. Ultimately, we will go through the input features only once and
make a local copy for the second pass.

On Tue, Dec 3, 2019 at 8:32 AM Andreas Oxenstierna <ao at t-kartor.se> wrote:

> 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 listgdal-dev at lists.osgeo.orghttps://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.sehttp://www.t-kartor.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191203/1eb2d49d/attachment.html>


More information about the gdal-dev mailing list