Opened 2 years ago
Last modified 2 years ago
#5180 new enhancement
Batch edges removal function
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Fund Me |
Component: | topology | Version: | |
Keywords: | Cc: |
Description
When cleaning topologies a tipical workflow consists in removing a lot of edges (for example QGIS PostGIS Topology Edit plugin allows selecting edges and clicking an icon to delete all of them).
At the moment the only way to remove all edges is to call ST_RemEdgeModFace or ST_RemEdgeNewFace multiple times, once for each edge being removed.
This operation is very very slow as the number of edges augment.
This ticket is to expose a function taking a set of edge identifiers and remove them ALL while ensuring the topology is left in a valid state. The function would be aimed at performance improvement.
Ensurance of valid topology MAY benefit from implementation of RecomputeEdgeLinking function, see #4942
Change History (4)
comment:1 by , 2 years ago
comment:2 by , 2 years ago
Such a function might also need to take a parameter to tell whether to completely bail out if any given EDGE cannot be removed because doing so would make it impossible to retain immutable definition of existing TopoGeometry objects.
This is because the current code allows to call ST_RemEdgeModFace or ST_RemEdgeNewFaces in a loop and catch exception due to the above impossibility, and as such is known to be used by the pgtopo_update_sql code. Exposing a batch-removal function will need to somehow provide a similar characteristic (or the caller would need to pre-compute what's possible to drop and what not)
comment:3 by , 2 years ago
A pl/pgsql implementation of a batch edge-removing function (taking a bounding box as the only parameter, and skipping removal of edges needed to represent TopoGeometries) is here: https://gitlab.com/nibioopensource/pgtopo_update_sql/-/merge_requests/277
The function really also removes unneeded nodes, a core function might need to take parameters to specify what to remove and what not…
comment:4 by , 2 years ago
A related interface may be explicitly finding out by itself which primitives are needed and which not, see #5183
The problem was spotted on a real-world case here: https://gitlab.com/nibioopensource/pgtopo_update_sql/-/issues/209#note_1014657071