<div dir="ltr"><div><div><div><div><div>This would be awesome "<br>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.<br>"<br></div>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?<br></div><div>It would be a great feature, at a reasonable cost (you would need to change only a few lines in your code)<br></div><div><br>"Then the challenge is to rebuild the intersecting points or lines"<br></div>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).<br></div>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! ).<br></div><div>I might rely on ring point order to find which piece is inside or outside the ring.<br></div><div><br></div><div>I'm going to test it tomorrow, I would expect to break the 10 minutes marks (1 core), but I'm not certain<br></div><div><br><br></div><div>In fact we could combine our approaches, I'll start thinking about that.<br><br></div>Cheers,<br></div>Rémi-C<br><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-05 11:54 GMT+01:00 Mark Wynter <span dir="ltr"><<a href="mailto:mark@dimensionaledge.com" target="_blank">mark@dimensionaledge.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Anyway, I like your dumping to segments and points.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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!!<br>
<br>
Sent from my iPhone<br>
<br>
> On 5 Mar 2015, at 8:32 pm, Rémi Cura <<a href="mailto:remi.cura@gmail.com">remi.cura@gmail.com</a>> wrote:<br>
><br>
</blockquote></div><br></div>