Feature request #1899

Nested Grouping in Layer Tree

Added by Andreas Neumann about 11 years ago. Updated almost 10 years ago.

Status:Closed
Priority:Low
Assignee:Jürgen Fischer
Category:Map Legend
Pull Request or Patch supplied: Resolution:fixed
Easy fix?:No Copied to github as #:11959

Description

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.

nested-layers.diff Magnifier - patch to add support for nested layers (118 KB) Jürgen Fischer, 2010-09-30 03:58 PM

History

#1 Updated by Paolo Cavallini almost 11 years ago

I think this would be more complex than average uses could bear

#2 Updated by Donkagen2 - over 10 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.

#3 Updated by Giovanni Manghi over 10 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 [comment:3 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.

#4 Updated by Jürgen Fischer about 10 years ago

The patch also contains support for nested layers in the QGIS mapserver. Please review.

#5 Updated by Andreas Neumann about 10 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.

#6 Updated by Andreas Neumann about 10 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

#7 Updated by Jürgen Fischer about 10 years ago

Replying to [comment:9 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.

#8 Updated by Jürgen Fischer about 10 years ago

Replying to [comment:8 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.

#9 Updated by Andreas Neumann about 10 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!

#10 Updated by Giovanni Manghi about 10 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.

#11 Updated by Marco Hugentobler about 10 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.

#12 Updated by Jürgen Fischer about 10 years ago

Replying to [comment:15 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?

#13 Updated by Jürgen Fischer about 10 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).

#14 Updated by Marco Hugentobler about 10 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.

#15 Updated by Jürgen Fischer almost 10 years ago

Replying to [comment:18 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.

#16 Updated by Jürgen Fischer almost 10 years ago

applied in 0c5ebf7c (SVN r14395).

#17 Updated by michele zanolli almost 10 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

#18 Updated by Paolo Cavallini almost 10 years ago

Unsure: to me the current behaviour seems correct

#19 Updated by Alister Hood almost 10 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.

#20 Updated by Jürgen Fischer almost 10 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

nested layer applied.

Also available in: Atom PDF