Re: [Qgis-user] Handling of PostGIS TopoGeometry layers
I commented on that issue (4374) and explained my view on that topic again. Do you think the plugin way would be easier (knowing that it is not necessarily faster)? It seems to me that the implementation into the postgres data provider of QGIS might have a undefined time horizon. I could really use that feature and have entry-level python experience and never developed a QGIS plugin. Are there more people out there who would welcome that change? Original Message Subject: Re: [Qgis-user] Handling of PostGIS TopoGeometry layers Local Time: 28. Juli 2016 1:33 PM UTC Time: 28. Juli 2016 11:33 From: s...@kbt.io To: ande...@protonmail.com CC: qgis-user@lists.osgeo.org On Wed, Jul 27, 2016 at 02:47:39AM -0400, AW wrote: > 100% agreed, Sandro. > > I did a quick search in the QGIS hub for the mentioned issue, but couldn't > find it for now. I found this one, for allowing the specification of a "bbox" column to use for filtering: http://hub.qgis.org/issues/9516 And this, to allow keyword substitution: http://hub.qgis.org/issues/4374 I guess the latter would deprecate the former. Your comments on the ticket(s) would be welcome. > 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? Well, I would want it :) > 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? I guess a plugin could effectively change the query associated with a layer so to filter by current bbox against an arbitrary column, but I'm not sure what would be "quicker"... --strk;___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Handling of PostGIS TopoGeometry layers
On Wed, Jul 27, 2016 at 02:47:39AM -0400, AW wrote: > 100% agreed, Sandro. > > I did a quick search in the QGIS hub for the mentioned issue, but couldn't > find it for now. I found this one, for allowing the specification of a "bbox" column to use for filtering: http://hub.qgis.org/issues/9516 And this, to allow keyword substitution: http://hub.qgis.org/issues/4374 I guess the latter would deprecate the former. Your comments on the ticket(s) would be welcome. > 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? Well, I would want it :) > 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? I guess a plugin could effectively change the query associated with a layer so to filter by current bbox against an arbitrary column, but I'm not sure what would be "quicker"... --strk; ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Handling of PostGIS TopoGeometry layers
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: s...@kbt.io
To: ande...@protonmail.com
CC: qgis-user@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___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Handling of PostGIS TopoGeometry layers
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
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] Handling of PostGIS TopoGeometry layers
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
Qgis-user@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
