Opened 15 years ago
Closed 13 years ago
#1899 closed enhancement (fixed)
Nested Grouping in Layer Tree
Reported by: | neumann | Owned by: | jef |
---|---|---|---|
Priority: | major: does not work as expected | Milestone: | Version 1.6.0 |
Component: | Map Legend | Version: | Trunk |
Keywords: | Cc: | mhugent | |
Must Fix for Release: | No | Platform: | All |
Platform Version: | Awaiting user input: | no |
Description (last modified by )
It would be nice if we could have more than one group level (nested groups) in the layer tree. It would allow better structuring of more complex projects. If group opacity (#1898) is also implemented it would allow for better symbology in complex projects.
Attachments (1)
Change History (25)
comment:1 by , 15 years ago
Type: | bug → enhancement |
---|
comment:2 by , 14 years ago
Platform: | Debian → All |
---|
follow-up: 4 comment:3 by , 14 years ago
I find the lack of nested groups in projects with lots of layers to be a significant shortfall, especially when using QGIS to explain something to observers... I'm continually hunting for the correct layers to turn on and off. Nesting is the same model that everyone uses with directories to handle this complexity so should be intuitive for most users.
comment:4 by , 14 years ago
I agree, I feel the same necessity for a more complex legend structure and the same is asked by the vast majority of the users that approach QGIS. Together with the lack of multiple selection of layers in the legend and with the lack of an option to "add as group" when adding vectors/rasters (tickets already exist for both issues), is one of more important tasks to be accomplished to improve qgis usability.
Meanwhile I'll add this ticket to the list of the ones possibly to be discussed in the next developer meeting.
Replying to Donkagen2:
I find the lack of nested groups in projects with lots of layers to be a significant shortfall, especially when using QGIS to explain something to observers... I'm continually hunting for the correct layers to turn on and off. Nesting is the same model that everyone uses with directories to handle this complexity so should be intuitive for most users.
comment:5 by , 14 years ago
Milestone: | Version 1.5.0 → Version 1.6.0 |
---|
comment:6 by , 14 years ago
Cc: | added |
---|---|
Type: | enhancement → patch |
The patch also contains support for nested layers in the QGIS mapserver. Please review.
comment:7 by , 14 years ago
Owner: | changed from | to
---|
follow-up: 12 comment:8 by , 14 years ago
Thank you Jürgen, for providing this patch!
I had a brief test (only the desktop), not the QGIS mapserver. It seems to work fine. There is one usability issue, though: if you want to add a new group to an already selected group (potentially deeply nested), the newly added group is always added to the very bottom. It would be nice if the newly added group would be added to the currently active (selected) group, not to the very bottom. I don't know how complicated this would be to fix?
Should I report this as a separate issue? It is not directly related to the nested grouping patch, but the issue already existed before.
follow-up: 10 comment:9 by , 14 years ago
Further testing revealed another, more serious issue:
when removing the parent group of a nested group (e.g. 2 other groups nested within a parent) with a right-click "Remove", QGIS hangs/crashes.
This happens on Ubuntu Lucid 64bit with QT 4.6.2
comment:10 by , 14 years ago
Replying to neumann:
when removing the parent group of a nested group (e.g. 2 other groups nested within a parent) with a right-click "Remove", QGIS hangs/crashes.
fixed in the new patch.
comment:11 by , 14 years ago
Description: | modified (diff) |
---|
comment:12 by , 14 years ago
Replying to neumann:
Thank you Jürgen, for providing this patch!
np.
I had a brief test (only the desktop), not the QGIS mapserver. It seems to work fine. There is one usability issue, though: if you want to add a new group to an already selected group (potentially deeply nested), the newly added group is always added to the very bottom. It would be nice if the newly added group would be added to the currently active (selected) group, not to the very bottom. I don't know how complicated this would be to fix?
added in the new update of the patch.
comment:13 by , 14 years ago
I can confirm that adding new groups directly as a sublayer seems to work now.
Also, removing whole groups recursively seems to work fine now.
Thanks a lot!
comment:14 by , 14 years ago
yes, I also tested the patch and it really looks great!
I opened a enhancement ticket (#3026), now that we (will) have nested groups and multiple selection: drag and drop of multiple selection of layers/groups should move the entire selection. Now it moves just one layer/group.
follow-up: 16 comment:15 by , 14 years ago
Having nested groups is a very cool feature.
In the patch, there is a bug with the mapserver if there are nested groups and we do a request with the name of a nested group (e.g. LAYERS=nested_group). It works for toplevel groups and single layers.
comment:16 by , 14 years ago
Replying to mhugent:
Having nested groups is a very cool feature.
In the patch, there is a bug with the mapserver if there are nested groups and we do a request with the name of a nested group (e.g. LAYERS=nested_group). It works for toplevel groups and single layers.
Oh, I didn't notice that groups are "named layers". Is that intentional?
comment:17 by , 14 years ago
New patch also allows multiple layers to be moved (layers are hidden while the move is in progress).
In WMS groups are now nameless (not sure if that's bad - groups in UMN mapserver are nameless too).
Also it contains a change that disables the ability to query layers in editing mode. For one on shape files setting a query make (some?) OGR layers read-only, but also for other layers it might be irritating or even break things, if you have edited features, that later are filtered away (see also #2951).
follow-up: 19 comment:18 by , 14 years ago
Yes, it's intentional that groups are named layers. Because it is very convenient to refer to groups with a single WMS layer name.
comment:19 by , 14 years ago
Replying to mhugent:
Yes, it's intentional that groups are named layers. Because it is very convenient to refer to groups with a single WMS layer name.
groups should now be named again and get the CRSes and bbox.
comment:21 by , 14 years ago
Thanks, very nice and useful feature!
Let me suggest a little improvement:
If I check (set visible=yes) a group of layers, all layers/groups inside it will become visible, and viceversa. Is this correct? I think that only the previous checked layers/groups inside that group have to become visible, the others must remain unchecked. Think about groups with lot of layers and nested groups: if I check the root group... all will become visible... I think this is not correct/useful.
michele
comment:23 by , 14 years ago
Thanks, the nested groups are great.
Personally I think the behaviour suggested by Michele is more useful and more intuitive. It is also the standard behaviour in other applications like Mapinfo.
When a group is turned off in Mapinfo the checkboxes (in the layer control) for layers/groups inside it keep their state (i.e. if they were checked they stay checked). I think this is probably the best behaviour... although I guess they could also be greyed-out in the layer control.
comment:24 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Type: | patch → enhancement |
nested layer applied.
I think this would be more complex than average uses could bear