ST_RemEdgeModFace: Allows removing shared edges by universal face and a topogeometry

[jomarlla]

Layer t3.parcelas with 3 polygons adjacent polygons.

SELECT CreateTopology('t3', 0, 0.1);

create table t3.parcelas (gid serial primary key, codigo varchar);
select addtopogeometrycolumn ('t3','t3','parcelas','topogeom','POLYGON');
INSERT INTO t3.parcelas (codigo, topogeom) VALUES ('A',  totopogeom ('MULTIPOLYGON(((0 0, 100 0, 100 100, 0 100, 0 0)))'::geometry, 't3', 1, 0.1));
INSERT INTO t3.parcelas (codigo, topogeom) VALUES ('B',  totopogeom ('MULTIPOLYGON(((100 0, 200 0, 200 100, 100 100, 100 0)))'::geometry, 't3', 1, 0.1));
INSERT INTO t3.parcelas (codigo, topogeom) VALUES ('C',  totopogeom ('MULTIPOLYGON(((200 0, 300 0, 300 100, 200 100, 200 0)))'::geometry, 't3', 1, 0.1));

when I try to remove an edge which is needed by a topogeometry but one of the side is the universal polygon (id 0) PostGIS does not throw an error:

select ST_RemEdgeModFace ('t3', 6);
NOTICE:  Updating next_{right,left}_face of ring edges...
NOTICE:  Deletion of edge 6 joins faces 2 and 0
 st_remedgemodface
-------------------
                 0

The topogeometry returns an empty multipolygon:

select st_astext(topogeom::geometry) from t3.parcelas where gid = 2;

st_astext

---

MULTIPOLYGON EMPTY

Even though the topogeometry id = 2 exists it does not appear in the relation table:

select gid,(topogeom).* from t3.parcelas;
 gid | topology_id | layer_id | id | type
-----+-------------+----------+----+------
   1 |          30 |        1 |  1 |    3
   2 |          30 |        1 |  2 |    3
   3 |          30 |        1 |  3 |    3

select * from t3.relation ;

 topogeo_id | layer_id | element_id | element_type
------------+----------+------------+--------------
          1 |        1 |          1 |            3
          3 |        1 |          3 |            3

The current behavior (sandro santilli) is: "ST_RemEdgeModFace (which you're calling) is required to _modify_ one face to take up the space previously occupied by the faces this edge was separating.

By convention, when one of the faces is the universal face, the _other_ face is kept, while if both faces are not universal, the face on the _right_ is kept and the face on the _left_ is remved.

Now, if you have a TopoGeometry defined by only the face that is removed you get an exception, while if you have a TopoGeometry defined by the face that is modified, or by both faces, you get no exception."

Probably ST_RemEdgeNewFace is also affected

[strk]

I wonder what I had in mind when I wrote this:

  -- check if any topo_geom is defined only by one of the
  -- joined faces. In such case there would be no way to adapt
  -- the definition in case of healing, so we'd have to bail out
  --
  -- We do this only when no universal face is involved
  -- (no surface can be defined by universal face)
  --

[strk]

Fixed in r9627

I meant that the query I was building didn't make sense when universal face was involved. The query in that case could actually be much simpler but for now correctness is more important than speed. Second step should be re-factoring to avoid code duplication (in ST_RemEdgeModFace and ST_RemEdgeNewFace in this case) and finally speed will be taken in consideration.

Thanks a lot for this bug report, very welcome.