<p dir="ltr"><br>
On 5 Apr 2016 17:17, "Sandro Santilli" <<a href="mailto:strk@keybit.net">strk@keybit.net</a>> wrote:<br>
><br>
> On Mon, Apr 04, 2016 at 10:25:35AM +1000, Nyall Dawson wrote:<br>
> > On 3 April 2016 at 01:27, Sandro Santilli <<a href="mailto:strk@keybit.net">strk@keybit.net</a>> wrote:<br>
><br>
> > > Being able to use canvas-dependent variables (extent and scale,<br>
> > > mostly) would help a lot with speeding up some kind of query<br>
> > > layers (TopoGeometry ones, for example).<br>
> ><br>
> > Be aware that this would not be possible in a vector layer filter.<br>
> > Expressions at the vector layer level will only have access to global,<br>
> > project and layer variables. Think about it this way - if the project<br>
> > has multiple maps in various composers, which extent and scale would<br>
> > be used when fetching features from the layer for something which<br>
> > isn't specific to an individual map (Eg the attribute table).<br>
><br>
> How's the current support for "simplify at the provider side" done ?<br>
> It seems to have the exact same constraints of the ones you're<br>
> mentioning (yes, I've seen the recent thread about $area parameter<br>
> changing value across zoom levels, which seems to be one of those<br>
> side-effects).</p>
<p dir="ltr">That's done on the feature request. </p>
<p dir="ltr">What's the topology issue you're hoping to solve with this?</p>
<p dir="ltr">Nyall<br></p>
<p dir="ltr">><br>
> --strk;<br>
</p>