In Postgis Topology a merge of two surfaces does not involve spatial operations, since the surface to border relation has foreign key structures in the database. This means that the border of the new object is spatially not touched/changed when two surfaces are merged. With simple feature the common border must be computed on the fly, which again may involve snapTo and cause tiny overlaps and gaps. With Postgis Topology you can easily make an API where the client only sends new borders which is a key issue to secure data integrity. This secures that old border are not are not moved by a client error or the by simple transport format, because existing points are never not passed back to the server. Postgis Topology makes it easy for the server to work with those new borders(delta), because there are standard methods for this in Postgis Topology and all relations between border and surfaces are stored in the database. Postgis Topology also has validation routines in addition to using standard database constraints to secure a healthy system. The principles that Postgis Topology is based on was used in spatial system many years ago, but one problem was to keep the border line work nice and clean and not end up in a spaghetti. So one of the first things we did together with Sandro Santilli was to create methods on top of Postgis Topology to avoid this, by throwing away any border parts that does not contribute to a new “valid” surface. Postgis Topology is built on a relational database model that is based on SQL-MM part 3. Your own domain data are easily linked to border, surface objects with more. For instance to check domain attributes on a surface on the other side of a border is not spatial query but a standard relational query. The following projects will also be touched in this talk: gitlab.com/nibioopensource/pgtopo_update_sql (Functions using Postgis Topology to make it easy to create spatial update clients.) github.com/strk/qgis_pgis_topoedit (Postgis Topology is very well integrated with QGIS.) github.com/larsop/resolve-overlap-and-gap (Show how we clean up, simplify, generalize simple feature tables with millions of rows using Postgis Topology) Is relational database structure a good choice for Postgis Topology? Yes I will mean and since it’s also linked up SQL-MM part3 and not a random private structure and with all great Postgis functions available this is very good combination. You may take take glance at ibm.com/ibm/history/ibm100/us/en/icons/reldb/ and other articles about relational databases. The plan now is to build a full ecosystem around Postgis Topology with a generic client to support declarative rules, where you can define attributes, rules for attribute handling and how to deal with overlap and gap. All the work NIBIO has done/is doing here would not have been possible with out the great support from Sandro Santilli.