[Qgis-user] reproduced in dev. version - was Re: graphical modeler, field calculator, NULL result but no error report

[James Powell]

I am able to reproduce this behavior in the development version of qgis.

As a consequence, I opened two issues:

"Python call to --processing.run('qgis:fieldcalculator'-- fails to catch 
divide by zero"

(https://github.com/qgis/QGIS/issues/37737)

"nonsense code causes infinite regress in error reports"

(https://github.com/qgis/QGIS/issues/37739).  Both have since been 
tagged as "Bug + Processing + Modeller".

I learned along the way from a comment in the qgis core source code that 
the syntax of the language for the FORMULA argument, which I think is 
called "Processing", is SQL or SQL-ish by design.

- JP

On 6/17/20 4:00 PM, James Powell wrote:
>
> Hi there everybody,
>
> I want to derive some floating point values using an expression in the
> field calculator (see model snapshot below).  I'm using qgis 3.10.6 on
> Debian 10.
>
> I am finding that the first field calculator call, which produces 
> 'dbgfieldcalc',
> gives only NULL answers.
>
> The second field calculator call (at the bottom, which produces 
> 'dbgfishnetFinal')
> does almost the same thing and it works great.
>
> At no time will running this model produce errors.  In fact, even
> changing attribute names to be invalid attribute names doesn't produce
> an error at all.
>
> What I expect:
> - That the field calculator is able to consistently run simple 
> expressions through.
> - That feeding invalid attribute names causes an error report and 
> aborts the model run.
>
> I've read through the docs that show up for a search on "qgis-user 
> field calculator".
>
> The python code produced for this model reads
> :  # Field calculator
> :         alg_params = {
> :             'FIELD_LENGTH': 10,
> :             'FIELD_NAME': 'emissionsAfterFishnetInGramPerHour',
> :             'FIELD_PRECISION': 3,
> :             'FIELD_TYPE': 0,
> :             'FORMULA': 'attribute($currentfeature, 
> \'emissionsingramsperhour\') * attribute($currentfeature, 
> \'xlength_2\') / attribute($currentfeature, \'length\')',
> :             'INPUT': outputs['AddGeometryAttributes']['OUTPUT'],
> :             'NEW_FIELD': True,
> :             'OUTPUT': parameters['Dbgfieldcalc']
> : }
> :         outputs['FieldCalculator'] = 
> processing.run('qgis:fieldcalculator', alg_params, context=context, 
> feedback=feedback, is_child_algorithm=True)
> :         results['Dbgfieldcalc'] = outputs['FieldCalculator']['OUTPUT']
> where "xlength_2" is a nonexistent attribute (but the script has the 
> same behavior when I use
> "length_2", which is an existent attribute).
>
> Is it usual to not detect errors like this?  Is there some reason the 
> expression I
> wrote (with the proper attribute name) wouldn't give a floating point 
> number, but produces NULL instead?
>
> many thanks,
>   James P.
>
>
> snapshot:
>
> -- 
> James E. Powell, MS
> Pronouns: he/him/his
> Applied Physics PhD Candidate
> Department of Physics
> Portland State University
> Home page:http://web.pdx.edu/~powellj
> Office: SRTC 409B Phone: +1-503-725-8515

-- 
James E. Powell, MS
Pronouns: he/him/his
Applied Physics PhD Candidate
Department of Physics
Portland State University
Home page: http://web.pdx.edu/~powellj
Office: SRTC 409B Phone: +1-503-725-8515

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20200713/39f2497d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cngcgmhnlimpfadi.png
Type: image/png
Size: 60314 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20200713/39f2497d/attachment-0001.png>