Hi,
Sorry for the delay.
In the case of ST_Intersects, which is symmetric, there is no particular
order to follow. Both orders should work.
where st_intersects(lie.geometry, tbap.Geometry) AND lie._search_frame_
= tbap.geometry means:
"for each geometry of tbap, compute its bounding box, select
Hugo,
sorry for posting so late but i have the following question after this
exchange :
when it come to 'order' the operators why do u advise to write
*lie._search_frame_ = tbap.geometry* and not :
/tbap._search_frame_ =lie.geometry/
What is the logic behind this syntax ?
Thanks !
--
Sent
Hi Andreas and Totò,
Thanks for the confirmation.
I agree this is not well documented. Even the small section in the
manual is a bit ... enigmatic :-/
Andreas' suggestion to have a link in the GUI to the manual seems good.
This, with a bit more explanations in the manual :) I'll see what I can d
Hi Hugo
but the _search_frame_ is always usable ?? or only in special cases?
Il giorno gio 2 mag 2019 alle ore 17:18 Andreas Neumann
ha scritto:
> Hi Hugo,
>
> Indeed - when I add the test against the _search_frame_ - everthing
> works almost equally fast than within Postgis. Certainly now the
Hi Hugo,
Indeed - when I add the test against the _search_frame_ - everthing
works almost equally fast than within Postgis. Certainly now the virtual
layer suddenly becomes useful and fast enough for us.
But to be honest - I would never have guessed that. I was searching for
the "&&" operat
Hi,
One big difference between spatialite and PostGIS is that PostGIS is
able to use spatial indexes transparently, while spatialite cannot.
Could you try with something like " ... AND lie._search_frame_ =
tbap.geometry" ?
On 02/05/2019 11:02, Andreas Neumann wrote:
> Hi,
>
> One of my colleag
Hi Matteo,
this should be possible saving the virtual layer in a new
layer/datasource (e.g. Memory Layer)
Marco
Am 02.05.2019 um 12:51 schrieb matteo:
> I might be super wrong, but AFAIK, virtual layers behave like db views.
> Is there any chance to change this behavior and make as materialized
Hi Andreas,
> Seems like I am not the only one that suffers from this slowness.
not at all!
> The same query that takes about 40 secs in a virtual layer runs in 200ms
> in Postgis. Now I know that there is a lot of overhead to bring the two
> different data sources (Postgis and Geopackage) toget
Hi Matteo and Toto,
Seems like I am not the only one that suffers from this slowness.
The same query that takes about 40 secs in a virtual layer runs in 200ms
in Postgis. Now I know that there is a lot of overhead to bring the two
different data sources (Postgis and Geopackage) together, but i
Hi Andreas,
I also noticed the slow rendering of virtual layers, also when a layer
is small.
I think it depends on the result of the query: with 50 points when
linking one point with a line to all the other 49 points, at every map
zoom in/out it takes seconds to refresh the query
Cheers
Matteo
Hello everyone,
I use virtual layers a lot and confirm the slowness and the continuous
updating that makes the tool almost unusable.
it would be very useful to speed things up.
thank you
Il giorno gio 2 mag 2019 alle ore 11:02 Andreas Neumann
ha scritto:
> Hi,
>
> One of my colleagues created
Hi,
One of my colleagues created a QGIS project where they loaded a parcel
layer with approx. 24000 polygons (data source Postgis) and another
layer with 3 polygons representing project perimeters of contruction
sites. That second layer is in a Geopackage.
Now they want to select all parcels
12 matches
Mail list logo
