8000 Consistent treatment of child features when set to 'composition' type - copy, split, and merge · Issue #62435 · qgis/QGIS · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Consistent treatment of child features when set to 'composition' type - copy, split, and merge #62435
Open
@Aeshna314

Description

@Aeshna314

Feature description

When a child is set to 'composition' type of relation with a parent, it is supposed (I think) to mean that the child objects 'compose' the parent - ie that they are part of it and require it. This principle is followed with deletion.

If the child is a component part of the parent, then the same principle ought to apply to copying, splitting, and merging.

For example, if a parent object, say a house, has necessary child objects, say a lounge, a kitchen, and a bedroom, then when that parent is copied, the new object should be assumed to also be composed of a lounge, a kitchen, and a bedroom. Likewise if two houses each with a lounge, a kitchen, and a bedroom, are merged then the new house will be composed of all six rooms.

Yet, Qgis doesn't work this way. Oddly, it does retain child objects when splitting a feature, but in only one (arbitrary) half, which seems to make no sense at all - either the new polygons are two halves of the same object (in which case both should have copies of the child objects) or they are now new objects (in which case neither half should have copies of the child objects). One half arbitrarily being left with the child objects makes least sense of all the arrangements (though for pragmatic reasons, I understand it's probably more useful to at least have some copy).

I've no idea how difficult it would be to implement and probably wouldn't have even suggested it were it not for the fact that the 'composition' option exists and therefore obviously, the possibility to keep track of child objects and deal differently with them.

It shouldn't affect users who wouldn't want this action because they already have the option of an 'association' type relationship.

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0