Opened 13 years ago
Last modified 3 years ago
#1195 new enhancement
CopyTopologyLayer
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Fund Me |
Component: | topology | Version: | master |
Keywords: | usability | Cc: |
Description
strk,
I tried the Copytopology and I'm thinking its not appropriate to have it copy the relations and layers. I mean I'm at a loss as to how I would use these new records since no tables exist etc. Just causes clutter.
I think it would make more sense to have a CopyTopologyLayer or alternatively if you really see a need for copying those layer and relation records, add a default argument to CopyTopology — copy_layer or something. I just don't see myslef normally wanting this extra fluff copies when I copy a topology.
So CopyTopologyLayer would basically recreate the whole feature table to a new location and copy the related relation records.
Change History (5)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Milestone: | PostGIS 2.0.0 → PostGIS Future |
---|
comment:4 by , 3 years ago
Keywords: | usability added |
---|
comment:5 by , 3 years ago
An UpdateTopoGeometryTopology function is being worked on in https://gitlab.com/postgis/postgis/-/merge_requests/76 — may help with the re-linking of those relations
No tables exist but relations do. The relations table is like a collection of TopoGeometry objects (the full definition is available there, and strictly coupled with the primitives in that specific topology).
If we drop them, we drop a full level of abstraction built on the primitives. We keep the primitives but loose the higher level.
About what to do: if you know which TopoGeometry id has which attributes, you may re-link the TopoGeometry to its attributes. For example you may add a new topogeometry column to an existing table (the source topology layer) to point to the copy. This may be useful, in turn, to have a simplified version of the same topology layer.
An additional argument to CopyTopology to avoid the copy of the TopoGeometry definitions might be a good idea, since you have use cases for that.
What would CopyTopologyLayer do exactly ? It'll need to copy the primitives to a new topology I guess ? If you call the function on multiple layers, sharing the same primitives, what will happen ?
What I've been thinking about was more along the lines of making it easier to re-link orphaned TopoGeometry to actual tables. Because you should be able to easily add a TopoGeometry field and set it to old TopoGeometry with just topology id changed, but probably NOT that easily and surely NOT usin the AddTopoGeometryColumn function, which would insist on adding rows in topology.layer which you already have available.