totopoGeom have an extra arg to prevent addition of primitives to topology

[robe]

This is a request from Leo. In writing the example, he realized I could screw up his topology network with my reckless use of toTopoGeom and I did by not getting my points quite right to line up with his topology.

The scenario: You are the master maintainer of a topology for say a city or something and have meticulously laid out the topology that should account for all department topogeometry needs.

Some reckless person in department A, comes by and creates a topogeometry with toTopoGeom because his/her topogeometry which should have snapped to existing edges, did not. Now you have extra annoying nodes in your topology.

That reckless person may very well be you. You want the totopoGeom not to do you favors by creating new primitives if you know all the topos you are adding should be able to use the edges,nodes, and faces already existing in your topology.

So after discussion, proposed solution is to add an extra proto to toTopoGeom that prevents creation of new primitives and if a topogeometry can't be created without adding a primitive, it should throw an error.

So basically:

change this existing proto:

toTopoGeom(geometry geom, varchar toponame, integer layer_id, float8 tolerance);

toTopoGeom(geometry geom, varchar toponame, integer layer_id, float8 tolerance, allow_primitive_creation = true);

He wanted it to default to false, but since we are asking for this in a minor, we can't change that behavior without screwing up some people.

[strk]

I like it. The AddFace function does something similar, but only works with polygons and accepts NO tolerance.

[robe]

another nice google summer of code candidate. And strk can be the mentor

[strk]

I'm wondering… wouldn't it be safer to define roles to have or not privilege of adding primitives and other roles to have or not privilege of defining TopoGeometries ? TopoGeometry definition only needs to write into the relation table, while adding/changing primitives would need to write into the node,edge,face tables, revoking insert/update/delete/truncate to those primitives would give you what you need.

[robe]

Not entirely. The reason is if you are throwing in a bunch of geometries where you've already built a topology, any creation of a new face etc, might imply a problem if your assumption is you have already created the elemental pieces. So even as an admin you may want that safety net. Then in some cases having primitive automatically created is expected and desired (even possibly for admins).

I suppose you could go around changing set session_authorization and so forth to change your role, but that sounds like a huge hassle to me (more so than just adding an extra optional arg to the function)

[robe]

Milestone renamed

[strk]

Another idea I'm having is to have a different signature all together. The thing is toTopoGeom currently does BOTH the work of TopoGeo_addWhatever AND something else, we could encode that "something else" into its own function such function could be used in by users who have trouble building up their own TopoElementArrays, it could return a TopoElementArray so that its return value can be fed to CreateTopoGeom directly.

Evil as usual is in the details: how do you decide whether or not you accept the components ? Should we compute hausdorffdistance of the topogeometry::geometry and the input geometry to tell if the result is acceptable ? Possible outcomes: we pick elements which also covers space OUTSIDE of the input geometry; the sum of all returned elements is not enough to cover all the space of the input geometry.