[Qgis-user] Handling of PostGIS TopoGeometry layers

[AW]

100% agreed, Sandro.

I did a quick search in the QGIS hub for the mentioned issue, but couldn't find it for now.
Is there anybody who can comment on the complexity of such a change?
Would such a change in the PostGIS provider - despite the positive effects on the handling of topologies - be even wanted?

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?

thanks,
Andreas


-------- Original Message --------
Subject: Re: [Qgis-user] Handling of PostGIS TopoGeometry layers
Local Time: 26. Juli 2016 9:48 AM
UTC Time: 26. Juli 2016 07:48
From: strk at kbt.io
To: andehhh at protonmail.com
CC: qgis-user at lists.osgeo.org

On Mon, Jul 25, 2016 at 07:21:16AM -0400, AW wrote:

> I was examining the SQL-statements which QGIS uses to deal with TopoGeometry layers. It essentialy looks somewhat like this:
>
> ---
> SELECT st_asbinary("topo",'NDR'),"gid"
> FROM "public"."topo_test"
> WHERE "topo" && st_makeenvelope(138.48618410228871767,-35.03610634074148322,138.71434043049001161,-34.78702094367417885,4326)
> ---
>
> Those kind of statements run really slow because the column "topo" of type TopoGeometry does not have any spatial index.
> In my case the table has a "normal" Geometry column AND a TopoGeometry column, which are pretty much in sync.

[...]

> 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):
>
> ---
> SELECT st_asbinary("topo",'NDR'),"gid"
> FROM "public"."topo_test"
> WHERE "geom" && st_makeenvelope(138.48618410228871767,-35.03610634074148322,138.71434043049001161,-34.78702094367417885,4326)
> ---
>
> Would that be a way to tackle this well known performance issue?

My feeling is that it would be very useful to be able to specify,
for the PostgreSQL provider, a custom dynamic filter, where the
pixel size and extent are available as substitutable queries.

I think there's also an hub ticket for this enhancement, waiting
for a contributed patch.

That, or being able to specify different columns for *rendering*
and *filtering*.

Note that another use case is the "face" layer of the TopologyViewer,
which would benefit from filtering on the "mbr" column rather than
on the result of the expensive ST_GetFaceGeometry call.

--strk;

() Free GIS & Flash consultant/developer
/\ https://strk.kbt.io/services.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20160727/8f9e2b3e/attachment.html>