<div dir="ltr">Thanks to you and for the ongoing work!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-20 8:14 GMT+02:00 Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/20/2016 12:33 AM, Nyall Dawson wrote:<br>
> On 19 October 2016 at 22:22, Neumann, Andreas <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br>
</span><span class="">> - attributes from the parent feature are automatically available<br>
> within the filter, UNLESS there's a duplicate field name from the<br>
> child feature<br>
<br>
</span>I like this, e.g. PostgreSQL handles it the same way for joined fields.<br>
But it warns in case of duplication and requires an explicit source<br>
table statement in case of duplication. In the case where the child<br>
feature suddenly gets a new field with the same name, the semantic of<br>
the expression should not silently change but a warning be issued.<br>
<span class=""><br>
> - expose the parent feature via the variable @parent. This could be<br>
> used with the functions geometry(@parent), attribute(@parent,<br>
> "some_dup_field_name")<br>
<br>
</span>Based on above statement, there should also be a @child variable.<br>
Or attributes could be exposed as parent.attr / child.attr.<br>
<span class=""><br>
><br>
> Then you'd be able to write:<br>
><br>
> aggregate ('mypoint', 'count', "id", intersects ($geometry, geometry(@parent)))<br>
<br>
</span>aggregate('mypoint', 'count', "id", <a href="http://mypoint.fk" rel="noreferrer" target="_blank">mypoint.fk</a> = @<a href="http://parent.id" rel="noreferrer" target="_blank">parent.id</a>))<br>
<br>
or<br>
<br>
aggregate('mypoint', 'count', "id", attribute(@child, "id") =<br>
attribute(@parent, "id"))<br>
<br>
# Error in case both have a field "id"<br>
aggregate('mypoint', 'count', "id", <a href="http://mypoint.fk" rel="noreferrer" target="_blank">mypoint.fk</a> = "id"))<br>
<span class=""><br>
><br>
> The trickiest part in implementing this would be making sure the<br>
> current aggregate value cache correctly handles use of parent feature<br>
> attributes/geometry.<br>
><br>
> Re virtual layers: I've always seen these as a "heavier" (+ more<br>
> powerful!) approach, which is OK for some use cases but for others (Eg<br>
> data defined controls, composer labels, etc) it's preferable to have<br>
> these calculations available directly within the expression engine.<br>
<br>
</span>I also think this needs to be fixed in expressions. I have a use-case<br>
for it with default values at the moment.<br>
<span class="HOEnZb"><font color="#888888"><br>
Matthias<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br>
List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-user</a><br>
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-user</a></div></div></blockquote></div><br></div>