Adding a small feature to PostGIS topology

Sandro Santilli strk at kbt.io
Sat Mar 14 00:51:17 PDT 2026


Have you compared with using existing indices to only fetch edges that have any of the faces forming an areal TopoGeometry on one side and none on the other, from the existing table ?

Note the test/perf dir under topology, it would be useful to add a test focused on you use case.


Il 13 marzo 2026 21:12:34 CET, Scott Smith <smiths at latfor.state.ny.us> ha scritto:
>I have found that casting from topogeometry to geometry can be slow when the topogeometry is not of primitive features, particularly when a large number of primitive faces make up individual topogeometry elements and/or the topogeometry layer has multiple child layers.
>
>In order to improve that performance, I propose the addition of another table similar to edge_data that would have one record per edge in the topology per layer where two sides of the edge are different topogeo elements for the layer. Whereas the current method of casting from topogeometry to geometry is to identify all the faces in the topogeometry, get their geometries, and the geoaggregate those geometries. That process is what degrades the performance such conversions.
>
>The additional table would allow direct access to the lines defining the boundary of the each topogeometry and build the sequence of those lines as the sequence of lines of primitive faces is built.
>
>I have started a github repository<https://github.com/sighthnd/PostGIS_TopoEdges/tree/main> to hold the code as I develop it. At this point I have not figured out how to push what I have developed into the repo. Once I do, it will contain the CreateTopology function as it is in PostGIS in my setup, the modified CreateTopology function that adds the above described table, named edge_topo, and some of the triggers, and the start of work on a couple of the trigger functions that would be used when the functionality is employed. I have written code in perl to populate edge_topo from a fully populated edge_data and relation tables. Next step is to develop the trigger functions that would update edge_topo as changes are made in edge_data and relation.
>
>Scott Smith
>

-- 
Sent from hand-held device with K-9 Mail. Please excuse my brevity.


More information about the postgis-devel mailing list