<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 8:32 AM Andreas Oxenstierna <<a href="mailto:ao@t-kartor.se">ao@t-kartor.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <div>I am no Postgre expert but we have
      experienced similar cases when running complex transactions with
      large geometries, i.e. faulty results.<br>
      When splitting the transaction into several pieces, i.e. enforcing
      COMMITs (Postgre doesn't support COMMIT inside functions), the
      correct results are given.</div>
    <div>One guess is that this may happen for
      large geometries which are pushed to TOAST tables.</div>
    <div><br>
    </div>
    <div>Check Postgre memory parameters and
      trace exactly what is happening in the database.<br>
      Test also with EXTERNAL STORAGE for the geometry if they are
      really large.<br>
    </div>
    <p><br>
    </p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>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.</div>
        <div><br>
        </div>
        <div>Any hints are highly appreciated!</div>
        <div><br>
        </div>
        <div>Markus M<br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
    </blockquote>
    <p><br>
    </p>
    <pre cols="72">-- 
Hälsningar

Andreas Oxenstierna
T-Kartor Geospatial AB
Olof Mohlins väg 12 Kristianstad
mobile: +46 733 206831
mailto: <a href="mailto:ao@t-kartor.se" target="_blank">ao@t-kartor.se</a>
<a href="http://www.t-kartor.com" target="_blank">http://www.t-kartor.com</a></pre>
  </div>

_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div>