Adding a small feature to PostGIS topology
Scott Smith
smiths at latfor.state.ny.us
Sat Mar 14 18:44:06 PDT 2026
The edge_topo table was populated using those indices. However, I am not aware of anything in the indices that identifies what edges follow each other. I wrote a script to fill in that information based on what edges of each topogeometry share common nodes, however, I want to avoid needing to look that up each time it is desired to get the border of a topogeometry. I'm open to the possibility that such an index exists, I just don't know.
I have only started developing this feature. Once I get what I have into the repo, I'll start documenting what I know needs to be done and what I have done.
When I have tried typing 'git push' and specifying the repo, I get an error message that it can't find the repo. What do I need to do so that git would know what collection to look under to find the repo?
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Sandro Santilli <strk at kbt.io>
Sent: Saturday, March 14, 2026 3:51:17 AM
To: postgis-devel at lists.osgeo.org <postgis-devel at lists.osgeo.org>
Subject: Re: Adding a small feature to PostGIS topology
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260315/7db849a2/attachment-0001.htm>
More information about the postgis-devel
mailing list