<div>100% agreed, Sandro.<br></div><div><br></div><div>I did a quick search in the QGIS hub for the mentioned issue, but couldn't find it for now.<br></div><div>Is there anybody who can comment on the complexity of such a change? <br></div><div>Would such a change in the PostGIS provider - despite the positive effects on the handling of topologies - be even wanted?<br></div><div><br></div><div>I am not experienced with creating QGIS Plugins... could that be a feasible quick option in case a change of the provider is not a thing which would be quickly implemented?<br></div><div><br></div><div>thanks,<br></div><div>Andreas<br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [Qgis-user] Handling of PostGIS TopoGeometry layers<br></div><div>Local Time: 26. Juli 2016 9:48 AM<br></div><div>UTC Time: 26. Juli 2016 07:48<br></div><div>From: strk@kbt.io<br></div><div>To: andehhh@protonmail.com<br></div><div>CC: qgis-user@lists.osgeo.org<br></div><div><br></div><div>On Mon, Jul 25, 2016 at 07:21:16AM -0400, AW wrote:<br></div><div><br></div><div>> I was examining the SQL-statements which QGIS uses to deal with TopoGeometry layers. It essentialy looks somewhat like this:<br></div><div>> <br></div><div>> ---<br></div><div>> SELECT st_asbinary("topo",'NDR'),"gid"<br></div><div>> FROM "public"."topo_test"<br></div><div>> WHERE "topo" && st_makeenvelope(138.48618410228871767,-35.03610634074148322,138.71434043049001161,-34.78702094367417885,4326)<br></div><div>> ---<br></div><div>> <br></div><div>> Those kind of statements run really slow because the column "topo" of type TopoGeometry does not have any spatial index.<br></div><div>> In my case the table has a "normal" Geometry column AND a TopoGeometry column, which are pretty much in sync.<br></div><div><br></div><div>[...]<br></div><div><br></div><div>> So I am asking for your opinion if a possibly small addition to a TopoGeometry layer properties in form of e.g. a checkbox is thinkable/reasonable which enables the alteration of the statement to something like that (given the hint, that both geometry columns have to be more or less in sync):<br></div><div>> <br></div><div>> ---<br></div><div>> SELECT st_asbinary("topo",'NDR'),"gid"<br></div><div>> FROM "public"."topo_test"<br></div><div>> WHERE "geom" && st_makeenvelope(138.48618410228871767,-35.03610634074148322,138.71434043049001161,-34.78702094367417885,4326)<br></div><div>> ---<br></div><div>> <br></div><div>> Would that be a way to tackle this well known performance issue?<br></div><div><br></div><div>My feeling is that it would be very useful to be able to specify,<br></div><div>for the PostgreSQL provider, a custom dynamic filter, where the<br></div><div>pixel size and extent are available as substitutable queries.<br></div><div><br></div><div>I think there's also an hub ticket for this enhancement, waiting<br></div><div>for a contributed patch.<br></div><div><br></div><div>That, or being able to specify different columns for *rendering*<br></div><div>and *filtering*.<br></div><div><br></div><div>Note that another use case is the "face" layer of the TopologyViewer,<br></div><div>which would benefit from filtering on the "mbr" column rather than<br></div><div>on the result of the expensive ST_GetFaceGeometry call.<br></div><div><br></div><div>--strk;<br></div><div><br></div><div>()   Free GIS & Flash consultant/developer<br></div><div>/\   https://strk.kbt.io/services.html<br></div></blockquote><div><br></div>