[QGIS-Developer] Geoprocessing tools give empty results for data using crs EPSG:7694

[Giovanni Manghi]

Hi,


> Hi all
>
> I have made a few tests of GDAL 2.2.0 on Ubuntu 16.04 with QGIS 2.14.14 and
> have found out that most geoprocessing tools implying 2 layers (clip,
> difference, intersection, etc.) wrongly give empty geometries when the data
> is in CRS  EPSG:7694 (*Kyrg06-3*, newly added CRS to GDAL in 2.2.0). Same
> behavior with QGIS 2.18.11 with GDAL 1.11.3
>
> For example, when using the Tool *Vector - Geoprocessing tools - Difference*
> the difference between 2 layers gives an empty geometry. Using the same
> tool on the same data with the CRS 32643 (*WGS84 UTM43N*) gives correct
> results.
>
> I have communicated on the Ubuntugis mailing list and got the following
> feedback from Even Rouault:
>
> *I've run ogrinfo -al shp > log.txt on your dataset with GDAL 2.2 and GDAL
> 2.1 and get almost the same results. The only difference is that GDAL 2.2
> now reports the SRS of layers kyrgyzstan_UTM43N and rayons_UTM43N with an
> explicit EPSG:32643 code, which is an intended change of GDAL 2.2, and I
> wouldn't think that would cause issues to QGIS. So my feeling is that the
> issue is more with the processing tool itself, or a subtle issue in the
> integration of QGIS&GDAL.*
>
> Test dataset (in both CRS) here: http://www.henriod.info/share/shp.zip
>
> Is it something to be reported as a QGIS bug? Can you reproduce this
> behavior?


I made some test and here following a few notes:


1) the geoprocressing tools in the "vector" menu are the native QGIS
ones, and I don't thinkthey make use of GDAL/OGR to make the
operations, on the other hand in the Processing toolbox you find also
a few ones (I have in mind since a long to add more) really based on
GDAL/OGR.


2) I noticed that in your layers in EPSG:7694 there are geometries
errors that are not present in the EPSG:32643, and here lies the
problem of the wrong results you see, it does not depend on the CRS of
the inputs.


3) I fixed the inputs geometry errors with my favorite tool, the
liblwgeom plugin for the Processing toolbox and its "MakeValid" tool
(equivalent to PostGIS's ST_MakeValid) and after that the operation
returned the expected results


4) The geoprocessing OGR based tools are more verbose in their log and
so was easy to spot the geometry error messages


5) the OGR based "clip by vector" tool returned also an output in
EPSG:7694 while the equivalent QGIS tool returned an output with 4326
assigned CRS, but if you change it manually the result is there and in
the right place.



hope this helps

-- G --