QGIS » QGIS Application

#13270 is closed as fixed, do you mean that in an older qgis release this was working as expected?

Short version:

The problem I found while troubleshooting/triaging this ticker were much less obvious than expected, it took really a while to understand what was going on and ultimately it as about a in issue in QGIS/Processing, but not where I was expecting it after the error message reported here.

The new issue is #16878

If you re-create from scratch the attached model, that seems to need grass64 - not used anymore in recent QGIS releases -, it works as expected.

Long version:

1) I started to test on my Linux box. The first I noticed it was that on 2.18.10 (using then the latest version of QGIS, that ships GRASS 7.x by default under Windows, and Processing, I have an hunch the issuer could have an old version of Processing masking the new one shipped with the latest installers) the attach model - that includes a couple of v.clean steps - was looking for GRASS64:

Algorithm test starting...
Prepare algorithm: QGISREMOVENULLGEOMETRIES_2
Running RemoveNullUpTo [1/6]
Parameters: INPUT_LAYER =/home/giovanni/Downloads/Bounding_Polygon_AreaB-3_As on 20170630.shp
Converting outputs
OK. Execution took 0.022 ms (1 outputs).
Prepare algorithm: QGISREMOVENULLGEOMETRIES_1
Running RemoveNullFTA [2/6]
Parameters: INPUT_LAYER =/home/giovanni/Downloads/Area_B3_MBES_FTA.shp
Converting outputs
OK. Execution took 0.018 ms (1 outputs).
Prepare algorithm: GRASSV.CLEAN.ADVANCED_1
Running CleanFTA [3/6]
Parameters: input =/tmp/processingf94bbb15333e4f0095cc3c42e62fff34/0f9b0de1ae6648e39313dacc03f50ec9/OUTPUTLAYER.shp, tool =break, thresh =0.1, GRASS_REGION_PARAMETER =601227.5,605351.5,6850684.5,6855050.5, GRASS_SNAP_TOLERANCE_PARAMETER =0.1, GRASS_MIN_AREA_PARAMETER =0.0001
g.proj -c proj4="+proj=utm +zone=35 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs" 
v.in.ogr min_area=0.0001 snap=0.1 dsn="/tmp/processingf94bbb15333e4f0095cc3c42e62fff34/0f9b0de1ae6648e39313dacc03f50ec9" layer="OUTPUTLAYER" output=tmp15001406991524 --overwrite -o
g.region n=6855050.5 s=6850684.5 e=605351.5 w=601227.5 res=100
v.clean input="tmp15001406991524" tool="break" thresh="0.1" output=outputc852cb292078476f921a1b7fcf9cabac error=errorc852cb292078476f921a1b7fcf9cabac --overwrite
v.out.ogr -s -c -e -z input=outputc852cb292078476f921a1b7fcf9cabac dsn="/tmp/processingf94bbb15333e4f0095cc3c42e62fff34/e4556ce0688145aabe95f2ab83bbfb6f" format=ESRI_Shapefile olayer="output" type=auto
v.out.ogr -s -c -e -z input=errorc852cb292078476f921a1b7fcf9cabac dsn="/tmp/processingf94bbb15333e4f0095cc3c42e62fff34/b30d8c0304634baf88be5b9de309b820" format=ESRI_Shapefile olayer="error" type=auto
GRASS commands output:
/bin/sh: 1: grass64: not found 
/bin/sh: 1: grass64: not found
...
...
...

2) I have then recreated from scratch the model (attached as model1.model) and run it with the attached input files and... it worked.

3) I always do test on other platforms, so I did it on Windows on my clean testing VM installed QGIS 2.18.10 from osgeo4w and GRASS 7.2.x. Then imported the model and run it and...

Clip 'NoneType' object has no attribute 'fields'

it failed in the step where a "clip" operation is performed with the QGIS native tool. I of course blamed immediately the tool, but after a few checks it resulted to work also within the modeler. So did one step up in the model and realized that the problem was in the v.clean steps -> no output was generated so the clip operation has no inputs and it just returns that (users point of view) puzzling "Clip 'NoneType' object has no attribute 'fields'".

I tested v.clean in and out the modeler with other data, and it worked. I looked in possible CRS or geometry problems in data at no avail and then found that the issue is #16878

In fact I had the data from this ticket saved in the root of my e:\ disk. Once saved in another folder the model worked as expected.

PS
when you use GRASS tools to clean geometries you may want to set some value (you will need to do same test to understand what value is best for your data) for the (advanced) "snap tolerance" option, this will fix (most of) geometry/topology errors, and after that you'll get more reliable results. In fact your data has geometry errors, if don't fix them the result (in particular of the "difference" operation) is pretty much wrong as a lot of geometries are skipped.