Markus, > 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.
This is indeed a weird problem. I don't have a theory. The PG driver implements a lot of lazy loading strategy to run efficiently with databases with many layers, but I wouldn't expect potential issues to be triggered by the fact that several v.in.org processes run in parallel... And I checked that fields returned from the PG system tables are sorted by attnum, so they should always be returned in the same order. Are you sure there's no latent memory corruption in v.in.ogr ? Did you check with Valgrind ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
