<div dir="ltr"><div><div><div><div><div><div><div>Back after some other testing .<br><br></div>(_from memory, suppressing checks in addpoints was about 2 sec instead of 3 sec.<br></div>_About 21k unique points.)<br><br><br>
</div>
Here is a little comparison :<br>(32k polylines,21k unique points, already 'topological'( no need to cut the lines) ,with a lot of attributes)<br><br>Postgis Topology<br><div style="margin-left:40px">Postgis Topology (addtopogeom) : 700+ sec for 10k lines, (??about 1600 sec for 32k lines??)<br>
Postgis Topology (addlinestring) : 240+ sec for 10k lines, (??about 780 sec for 32k lines??)<br></div><div style="margin-left:40px">Postgis Topology (addnode, addedge) : 80sec for 10 k lines (??about 260sec for 32k lines??)<br>
<br></div>Grass Gis 7 :<br><div style="margin-left:40px">Importing everything : 10 sec<br></div><div style="margin-left:40px">Importing only geom (no attributes) : 5 sec<br></div><div style="margin-left:40px"><br>Importing everything then Exporting all topologies to postgis topology : 150 sec<br>
</div><div style="margin-left:40px">Declare postgis topo as external source and fill it with shapefile : 145 sec<br></div><div style="margin-left:40px"><br></div>Geos : (upper bound measured trough st_polygonize)<br>
<div style="margin-left:40px">ST_Polygonize on everything (aggregates on 32k lines) : about 5 sec<br><br></div>TopoJSON (according to previous thread : postgis topology/60 )<br><div style="margin-left:40px">Importing geometry (extrapolated) : about 30 sec?<br>
</div></div><div><div style="margin-left:40px"><br></div>CGAL (half edge) :<br><div style="margin-left:40px">hopefully soon<br>
</div><br></div><div>Geoxygene (JTS) :<br><div style="margin-left:40px">hopefully soon<br></div></div><br>I succeeded in putting the grass vector layer into postgis topology as it is proposed here <a href="http://grasswiki.osgeo.org/wiki/PostGIS_Topology" target="_blank">http://grasswiki.osgeo.org/wiki/PostGIS_Topology.</a><br>
</div><div>Maybe it could be better configured, but it is still slow (I tried both proposed ways).<br>
</div></div>
<br></div><div>About using GEOS as backend : currently there is no way to access topological information from geos (all methods are private).<br></div><div>
<br></div>Cheers,<br>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-21 10:40 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"><div class="">On Thu, Mar 20, 2014 at 06:46:51PM +0100, Rémi Cura wrote:<br>
> Yep,<br>
> We tried a modified version of AddNode without check (because I already<br>
> delete duplicates nodes before calling the function), it was not incredibly<br>
> faster, and anyway way faster than line insertion (where I feel we need to<br>
> focus now).<br>
<br>
</div>Show numbers, c'mon! :)<br>
<div class=""><br>
> I may try to simplify the add edge function, but I don't think this is the<br>
> way to go.<br>
<br>
</div>For sure the AddEdge funtion makes a lot more checks.<br>
I was actually thinking to split that myself between a checking and<br>
non-checking version.<br>
Also the checks themselves might have space for optimizations.<br>
<div class=""><br>
> It would be better to do batch direct insertion in table<br>
> (to be precise : insert all edges into edge_data for the columns edge_id,<br>
> start_node, end_node, geom )<br>
> , then batch edge_data completion (next_left_edge, next_right_edge, found<br>
> with querry on node_id),<br>
> then batch compute face (with polygonize) .<br>
<br>
</div>I agree this would be also an interesting way to proceed.<br>
Still I don't think polygonize would be that fast (not right now).<br>
<div class=""><br>
> This way there would be no edge by edge insertion.<br>
<br>
</div>But there'll still be edge-by-edge updates, which would be still<br>
expensive (every update is like a new insert).<br>
<div class=""><br>
> About your question :<br>
> only filling the edge_data with geometry (on next_left etc) is about 4.5<br>
> sec (on par with inserting all the points) for 10k lines. ON this 4.5 sec<br>
> you can remove about 3 sec related to my data selection process (I only<br>
> insert a part of a table).<br>
> This way, I would say that taking 1.5 sec to insert 10 k lines+ check<br>
> constraints and update index is OK for me.<br>
<br>
</div>So it makes 1.5 seconds for 10k edges + 4.5 seconds for their unique points<br>
(how many ?)<br>
<div class=""><br>
> Still a long way to go from 80 sec to few sec (10 sec would be cool, if it<br>
> scales well).<br>
<br>
</div>Well, if you could compute all the linking in memory it'd be about those<br>
inserts only (< 10 secs for the inserts). Time to look at GEOS GeomGraph<br>
capability of representing all we need ?<br>
<div class="HOEnZb"><div class="h5"><br>
--strk;<br>
_______________________________________________<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>