[postgis-users] Topology creation performance

Alexandre Silva amsilva at infoportugal.impresa.pt
Mon Nov 23 05:18:39 PST 2020

Hi and thanks for your response,

Most likely. I would try splitting these big faces into smaller
pieces. A way to do so would be inserting abitrary lines cutting
the plane into a grid. This would also split lines, further
reducing working set for each further insertion. You could add
these lines upfront or during the load, to see how they affect
the loading (it's good that you use multiple transactions).

Never thought of that approach, it seems a good way to go.
My only doubt about this is that we use a no tolerance topology, but there is a need for snaps (that will be made manually) but only on start/end points. With this approach I will have to ignore the nodes where lines and grid intersect, but it seems feasible.
I don't get the part of adding during load, do you mean when adding a line if there is no grid line nearby, to create it before insert it?

What version of PostGIS are you using ? What GEOS version ?
POSTGIS="3.0.1 ec2a9aa" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 5.2.0, September 15th, 2018" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.3.1" WAGYU="0.4.3 (Internal)" TOPOLOGY

Note that the Polygonize function will NOT properly setup edge-linking
(next_right_edge, next_left_edge) so you'd still not end up with a valid
topology when only using AddEdge + Polygonize.
I hadn't noted it, i saw the fields were populated and not realized that it only references itself. In a first step I'm only using the topology to fix snaps and generate faces. Is there any downside to not having the edge linking correct?

One improvement that was implemented in spatialite was to allow for
TopoGeo_addLinestring to NOT detect the creation of new faces while
still doing edge-linking. It still implied constructing an invalid
topology but the Polgonize step would then make it valid.
I saw your PR trying this approach for batch creation, unfortunately my knowledge of the topology codebase is very small to help in this matter. But is there any way of funding to make this feature happen?

Alexandre Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20201123/22f28e40/attachment.html>

More information about the postgis-users mailing list