Opened 3 weeks ago

Closed 3 weeks ago

#5709 closed defect (fixed)

ST_ChangeEdgeGeom fails to update face MBR when movement is smaller than float4

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 3.4.3
Component: topology Version: 3.4.x
Keywords: Cc:

Description

Similarly to what was reported for ST_RemEdgeModFace and TopoGeo_addLineString there are cases in which the MBR of a face gets ruined by calling ST_ChangeEdgeGeom and slightly moving a vertex.

Downstream report: https://gitlab.com/nibioopensource/resolve-overlap-and-gap/-/issues/74

Change History (4)

comment:1 by strk, 3 weeks ago

Testcase:

SELECT NULL FROM createtopology('t5709');
SELECT 't5709', 'edge', * FROM TopoGeo_addLineString('t5709',
  'LINESTRING(
    12.123711265448206 65,
    12.123711265448206 65.21007378815003,
    12.208829785296102 65,
    12.123711265448206 65)
  ');
SELECT 't5709', 'mbr-invalid-before', face_id
FROM t5709.face
WHERE face_id > 0
AND NOT ST_Equals(
    mbr,
    ST_Envelope(
      ST_GetFaceGeometry('t5709', face_id)
    )
  );
SELECT NULL FROM ST_ChangeEdgeGeom('t5709', 1,
  'LINESTRING(
    12.123711265448206 65,
    12.123711265448206 65.210073788150040000,
    12.208829785296102 65,
    12.123711265448206 65)
  ');
SELECT 't5709', 'mbr-invalid-after', face_id
FROM t5709.face
WHERE face_id > 0
AND NOT ST_Equals(
    mbr,
    ST_Envelope(
      ST_GetFaceGeometry('t5709', face_id)
    )
  );

comment:2 by strk, 3 weeks ago

The problem, like in #4941, is that lwgeom_get_bbox gets an approximaged bounding box from the serialized representation of the geometry:

+psql:test.sql:28: DEBUG:  [topo/lwgeom_topo.c:lwt_ChangeEdgeGeom:3569] BBOX of changed edge did not change

Paul, Regina: should we maybe stop reding that lamed-down box from the serialized representation when deserializing into LWGEOM ?

Last edited 3 weeks ago by strk (previous) (diff)

comment:3 by strk, 3 weeks ago

Or, what we would need is an SQL accessible function to round float8 boxes into float4 ones, as the topology MBR doesn't really need to be all that strict, as long as it contains all the face edges. But that's probably worth a separate ticket as it's a performance concern.

comment:4 by strk, 3 weeks ago

Resolution: fixed
Status: newclosed

Fixed in:

I will not backport further for now

Note: See TracTickets for help on using tickets.