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_______________________________________________
Qgis-user mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
