<div dir="auto">Wow this is a hell of a comprehensive answer :)<div dir="auto"><br></div><div dir="auto">Thank you very much... My bad, I didn't even think about checking the validity of the geometries here.  I will correct them and make further tests</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Stéphane</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 Jul 2017 9:39 p.m., "Giovanni Manghi" <<a href="mailto:giovanni.manghi@gmail.com">giovanni.manghi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
<br>
> Hi all<br>
><br>
> I have made a few tests of GDAL 2.2.0 on Ubuntu 16.04 with QGIS 2.14.14 and<br>
> have found out that most geoprocessing tools implying 2 layers (clip,<br>
> difference, intersection, etc.) wrongly give empty geometries when the data<br>
> is in CRS  EPSG:7694 (*Kyrg06-3*, newly added CRS to GDAL in 2.2.0). Same<br>
> behavior with QGIS 2.18.11 with GDAL 1.11.3<br>
><br>
> For example, when using the Tool *Vector - Geoprocessing tools - Difference*<br>
> the difference between 2 layers gives an empty geometry. Using the same<br>
> tool on the same data with the CRS 32643 (*WGS84 UTM43N*) gives correct<br>
> results.<br>
><br>
> I have communicated on the Ubuntugis mailing list and got the following<br>
> feedback from Even Rouault:<br>
><br>
> *I've run ogrinfo -al shp > log.txt on your dataset with GDAL 2.2 and GDAL<br>
> 2.1 and get almost the same results. The only difference is that GDAL 2.2<br>
> now reports the SRS of layers kyrgyzstan_UTM43N and rayons_UTM43N with an<br>
> explicit EPSG:32643 code, which is an intended change of GDAL 2.2, and I<br>
> wouldn't think that would cause issues to QGIS. So my feeling is that the<br>
> issue is more with the processing tool itself, or a subtle issue in the<br>
> integration of QGIS&GDAL.*<br>
><br>
> Test dataset (in both CRS) here: <a href="http://www.henriod.info/share/shp.zip" rel="noreferrer" target="_blank">http://www.henriod.info/share/<wbr>shp.zip</a><br>
><br>
> Is it something to be reported as a QGIS bug? Can you reproduce this<br>
> behavior?<br>
<br>
<br>
I made some test and here following a few notes:<br>
<br>
<br>
1) the geoprocressing tools in the "vector" menu are the native QGIS<br>
ones, and I don't thinkthey make use of GDAL/OGR to make the<br>
operations, on the other hand in the Processing toolbox you find also<br>
a few ones (I have in mind since a long to add more) really based on<br>
GDAL/OGR.<br>
<br>
<br>
2) I noticed that in your layers in EPSG:7694 there are geometries<br>
errors that are not present in the EPSG:32643, and here lies the<br>
problem of the wrong results you see, it does not depend on the CRS of<br>
the inputs.<br>
<br>
<br>
3) I fixed the inputs geometry errors with my favorite tool, the<br>
liblwgeom plugin for the Processing toolbox and its "MakeValid" tool<br>
(equivalent to PostGIS's ST_MakeValid) and after that the operation<br>
returned the expected results<br>
<br>
<br>
4) The geoprocessing OGR based tools are more verbose in their log and<br>
so was easy to spot the geometry error messages<br>
<br>
<br>
5) the OGR based "clip by vector" tool returned also an output in<br>
EPSG:7694 while the equivalent QGIS tool returned an output with 4326<br>
assigned CRS, but if you change it manually the result is there and in<br>
the right place.<br>
<br>
<br>
<br>
hope this helps<br>
<br>
-- G --<br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></blockquote></div></div>