Opened 22 months ago

Last modified 22 months 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:2 by strk, 22 months 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 strk, 22 months 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 strk, 22 months ago

A related interface may be explicitly finding out by itself which primitives are needed and which not, see #5183

Note: See TracTickets for help on using tickets.