[Qgis-developer] Support for QGIS variables in Processing

Nyall Dawson nyall.dawson at gmail.com
Wed Apr 6 12:59:43 PDT 2016


On 6 Apr 2016 23:23, "Matthias Kuhn" <matthias at opengis.ch> wrote:
>
> Hi Victor,
>
> On 04/06/2016 02:49 PM, Victor Olaya wrote:
> > Hi all
> >
> > I am trying to add support for QGIS variables in Processing, since
> > that can be a useful functionality. To start with, I want to add it to
> > scripts, so you can use the @variable syntax in Processing scripts as
> > well
> >
> > It is easy to implement that, but the scope here is not so clear as in
> > other places in QGIS where variables are used. It would be nice to
> > have the project scope, but also the layer scope of the layers that
> > are used are input. I was thinking of using @variable for the project
> > scope and layername at variable for the layer scope, but before
> > introducing a new notation, I would like to get ideas and feedback
> > from you.
> >
> > Of course, people writing scripts can get variables using the
> > QgsExpressionContextScope class...but i want to make it easier and
> > have it documented for script developers that do not want to  having
> > to dive in the QGIS API docs...
> >
> > Please, feel free to comment and tell me what you think of this idea,
> > and how you think it would be better to implement it. In a second
> > step, support might be added to the algorithm dialogs, so inputs such
> > as numbers or strings can be entered using variables.
>
> That sounds like an interesting integration.
>
> One question I have is if it's required to see variables as an isolated
> topic outside of expressions. Or if whenever a variable is required, a
> complete expression would offer much more flexibility.
>
> I also think that it's often implicitly clear from the context an
> expression appears in, which layer should be the source of the variables.

Matthias is right. If a user is trying to access a layer variable *outside*
of a single layer's context then they are doing things wrong and should be
using a project variable instead.

There really shouldn't be any need to access a layer variable outside of
the layer's scope (even via a function). Effectively they are like
protected variables in a c++ class. So layer dependant contexts (eg
labelling, symbology) can access them, but higher contexts (map canvas,
composer) can't.

I'd suggest just using the global and project scopes, and then adding the
layer scope only when the expression/value is used in a single layer
context.

Cool idea btw!

Maybe you could add a processing model scope that an individual model run
will temporarily store its own variables in. Then a new set variable
algorithm added, and also the option to store non spatial calculation
results in a variables. That + ability to use variables/expressions in
parameters would add a *ton* of new possibilities to models!

Nyall

>
> What are the use cases you have in mind?
>
> Cheers
> Matthias
>
> --
> Matthias Kuhn
> OPENGIS.ch - https://www.opengis.ch
> Spatial • (Q)GIS • PostGIS • Open Source
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160407/a512aa45/attachment.html>


More information about the Qgis-developer mailing list