<div dir="ltr"><div>Hey Sandro,<br>in my opinion we don't need a better speed for current construction, we need a batch constructing mode !<br></div><div>Optimally it could be done by using the geos, because it constructs all the topology very very fast.<br></div><br>Adding one feature is actually quite fast, even on already big topology.<br><br>Its when you want to add a lot's that it becomes increasingly slow (maybe because indexes are not updated,or because we are in one transaction?)<br>The slowing seems to be very non linear, probably following n^2, where n is the number of feature already constructed in the transaction.<br><br>Cheers,<br>Rémi<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-19 12:27 GMT+01:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Nov 18, 2014 at 08:26:29PM +0100, Rémi Cura wrote:<br>
> This is suprising indeed.<br>
> Im my test using the v.out.postgis was still way faster than constructing<br>
> with postgis topology (about x3 I think).<br>
><br>
> Are you using v.out.postgis -l, with grass 7?<br>
<br>
</span>Yes.<br>
<br>
The topology was pretty big, maybe that's the difference.<br>
Here's the dataset (not sure if still accessible):<br>
<a href="http://lists.osgeo.org/pipermail/postgis-devel/2014-January/024085.html" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/2014-January/024085.html</a><br>
<br>
GRASS 7.0.0beta3 (world):~ > <a href="http://v.info" target="_blank">v.info</a> -t map=million_poly_topo1<br>
nodes=3247661<br>
points=0<br>
lines=0<br>
boundaries=5102420<br>
centroids=1161248<br>
areas=1855936<br>
islands=1177<br>
primitives=6263668<br>
map3d=0<br>
<span class=""><br>
> Now I think I should have used a python way from within grass (grass offers<br>
> full binding, so it should be doable to loop trough grass internal topology<br>
> and convert it to postgis topology)<br>
><br>
> I tried to reach grass dev several time to try to improve the postgis<br>
> export, I had no answer.<br>
<br>
</span>That's unfortunate.<br>
<span class=""><br>
> My intuition is that the slowness comes from the fact that grass tries to<br>
> write  edge by edge , and each time the edge_data trigger are triggered.<br>
> The correct way would be to compute full topology structure, then<br>
> deactivate trigger, then fill table , then reactivate trigger.<br>
<br>
</span>Or maybe it has to build the next_{left,right}_face info too.<br>
Enabling PostgreSQL logging should tell (but better not done with<br>
a ~2 million polygons topology).<br>
<br>
Oh how better it would be to speed up topology building in PostGIS :)<br>
<span class="im HOEnZb"><br>
--strk;<br>
<br>
  ()   Free GIS & Flash consultant/developer<br>
  /\   <a href="http://strk.keybit.net/services.html" target="_blank">http://strk.keybit.net/services.html</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br></div>