[Qgis-user] Handling of PostGIS TopoGeometry layers

[AW]

Hello everyone,

I am currently tinkering with the PostGIS topology capabilities and therefore having QGIS as an "frontend" for editing the TopoGeometries. That works really well so far, as long as we are talking about really minor counts of polygons in the layer to be edited.
That is because there is no spatial indexing available for the columns of type TopoGeometry.
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.

If the statement above is altered to get the overlapping features based on the Geometry column instead of the TopoGeometry column one can benefit from a spatial index on the Geometry column.

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?

Thanks
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20160725/2db54cbd/attachment.html>