[postgis-users] ST_Intersection very slow

[Rémi Cura]

This would be awesome "
I'm keen to experiment with the dumped points, using my recursive quadgrid
function, so the vector grids subdivide to a maximum depth or number of
points per cell. So this will be applied at the point level to give an
optimized number of grid cells.
"
If I understand you correctly, you would subdivide like you do currently,
but the depth of subdivision would be a function of number of points
remaining in the square?
It would be a great feature, at a reasonable cost (you would need to change
only a few lines in your code)

"Then the challenge is to rebuild the intersecting points or lines"
I hadn't thought of that (namely I was cutting the square in pieces,then
finding which pieces is trully in big bad polygon, but I didn't thought of
directly reconstructing).
It is an excellent idea, which solves the problem that was slowing me down
(which piece of square is really in the big bad polygon, which involves
using the full outer ring and inner ring geom! ).
I might rely on ring point order to find which piece is inside or outside
the ring.

I'm going to test it tomorrow, I would expect to break the 10 minutes marks
(1 core), but I'm not certain


In fact we could combine our approaches, I'll start thinking about that.

Cheers,
Rémi-C


2015-03-05 11:54 GMT+01:00 Mark Wynter <mark at dimensionaledge.com>:

> Hi Remi - I followed most of it - the squarised representation -
> approaching the form of a raster - that was another approach I was
> contemplating - rasterising the vectors and using inbuilt raster functions.
> Pixel in polygon uses the pixel centroid I recall. with your approach, the
> squares always overlap the boundary, which means neighboring land classes
> will share squares in common. I think I can see that in one of the images.
> Yes? Pixel in polygon avoids this.
>
> Anyway, I like your dumping to segments and points.
>
> I'm keen to experiment with the dumped points, using my recursive quadgrid
> function, so the vector grids subdivide to a maximum depth or number of
> points per cell. So this will be applied at the point level to give an
> optimized number of grid cells.
>
> Then the challenge is to rebuild the intersecting points or lines which is
> where I think you have got to. I'm thinking of just running
> ST_intersection, like with my version 2 solution, but with the quadgrid.
>
> Hmm, just thinking aloud- keeping the parent polygon id of every point, so
> the quadgrid knows not only how many points, but which distinct polygons -
> so ST Intersection only evaluates those we already know to intersect.
> Cool!!
>
> Sent from my iPhone
>
> > On 5 Mar 2015, at 8:32 pm, Rémi Cura <remi.cura at gmail.com> wrote:
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150305/6b2928cd/attachment.html>