Implement topology.ToTopoGeom(Geometry, topology_name, layer_id)

[strk]

Such a function would make it easier to build topologies by iteratively adding simple features to it. The function should take care of all noding and splitting and update of all pre-existing topogeometries.

The signature seems sufficient, the name might be changed.

[aperi2007]

I guess this function should have also a parameter "tolerance", because when you add , for example, a line to an existent topology, it could be need add only some segments of that line because other segments there is available in the topology. So you could use the CommonShared and ST_Snap to understand what is really needed to add to the topology of the new geometry.

[trapanator]

+1 it would be a great thing.

[strk]

This ticket is looking for co-funders. We're 1/3 into the way to fully funded.

[strk]

See ​http://strk.keybit.net/projects/postgis/index.html#tasks for more informations about funding status.

[strk]

Other ways to fund this: ​http://www.pledgebank.com/postgistopology

[strk]

Do we want to support EMPTY TopoGeometry object ?

There can't be an empty primitive so an empty complex would be one defined by no primitives. Hierarchical empties could be defined by any number of underlying empty complexes.

Bored GIS researchers would have something to talk about during the holidays ( quoting Even Rouault

[strk]

More on the topic of empties: should a typed EMPTY simple geometry retain its type when converted to a TopoGeometry ? If so we'd also need typed TopoGeometry objects (not that hard once we accept to support empty at all)

[strk]

Even more on empties: every TopoGeometry object needs to have a reference into a "relation" table. The table holds a list of components for each TopoGeometry object.

Given we can't have a TopoGeometry id w/out at least one component, we'll need to add an empty component to have an empty TopoGeometry. Such empty component could have a special primitive with id 0. Although id 0 is taken for face components (the universal face), a TopoGeometry composed by face 0 isn't documented as being legal. I guess void==universe==nirvana holds pretty nicely after all, doesn't it ?

If we go there, we should probably make sure that TopoGeometry editors (add components, drop components) make sure to remove the special component 0 as soon as a real one is added and to re-add the special component 0 when all are removed.

So far it all looks over-complex for just retaining typed emptiness during round-trip conversion from simple to topological feature…

[strk]

With r8613 we have the concept of empty TopoGeometry objects. They do have an ID but no entry in relation table. Basically their construction only increments the sequence. You can create them by omitting the components parameter to CreateTopoGeom. Under the hood, the CreateTopoGeom function skips from the given array any TopoElement with type=0 (and expects id=0 as well).

[strk]

r8671 fully implements the function, and r8672 briefly documents it.

This was after many commits containing underlying functions being used by this one. The underlying functions were stubbed already since 2006: TopoGeo_addPoint, TopoGeo_addLinestring, TopoGeo_addPolygon. Recently they changed their signature so that a DROP would be required for some of them. A dump/restore (as expected for 2.0) would work fine. #1430 should help those not willing to dump/restore at this stage.

It is a good time to play with the function and reporting issues as bugs.