TOC Display Order Not Consistent with ArcRAVE

[joewheaton]

Hey @MattReimer, this new version of QRAVE is sweet! We have one pretty annoying little problem in which the display order that layers are added from QRAVE to Q's "Layers" Table of Contents is not consistent with how ArcRAVE works. In the video below I illustrate this:

Put more concisely than the video, layers seem to get added underneath the previous layers instead of on top. Given that we most typically add things to the map with a basemap or hillshade or something underneath, and everything else gets piled on top, this is a problem.

[joewheaton]

Sorry @MattReimer I didn't see #10 obviously!

[joewheaton]

Duplicate of #10

[MattReimer]

Hey @joewheaton this is not precisely a duplicate of #10 and there are actually about 3-4 issues bundled into this conversation.

First off I will say, if you are moving layers around then the plugin will absolutely fail to place layers correctly because it tries to figure out where to put a layer by comparing the project tree structure to the business logic structure and navigating that in a sensible way. If you move things around the layer still gets added but the placement can't be guaranteed because there's no way to find yourself in a customized project tree.

Suggestion 1: layer sorting priority

Right now in QGIS the intent is that the layers are supposed to be added to the map in the same order that they exist in the tree. Obviously this is different than ArcRave which treats layers like a stack that always adds to the top

Where we could go with this is a set of sorting priorities when deciding where in a group to place layers.

Sorting priorties when comparing two layers:

1. If they are different types prioritize as follows [points, lines, polygons, rasters]
2. If they are the same type stack the newer layer on top

With this schema rasters are always below vectors, polys are always below lines etc. but the newest layer added is always at the top. This is kind of what webrave does (albeit a lot more simply)

This doesn't address sorting between groups. Because groups are arbitrarily hierarchical I don't think there's a strategy here.

Suggestion 2: Fix the group ordering

This is pretty non-contreversial. Groups should get added in the same order as they exist in the business logic. This is what's supposed to happen and it's not so that's a bug.

Suggestion 3: Duplicating project tree layers for views

stay with me here because I think there's some merit

When you add a view the layers get added to a group with that view name like so.

RSContext for huc 17060304
   - Outputs
       - VBET 50%
   - Topography
        - DEM layer 
   - Views
        - Default VBET VIEW
            - Vbet 50%
                - DEM Layer

This may seem cluttered but it has the following benefits:

1. When you add a view It doesn't tangle your view layers up with layers you've already got open.
2. You can turn off and on everything but that view, have multiple views open at one time and switch between them
3. View layers get added in the order they are specified in the business logic view definition without having to worry where they sit in the overall hierarchy. This could give you more control.

Finally, for everything I can't fix with regards to tree management we might need to accept differences between how Q, Arc and Web work. Obviously we'll get Q and Arc closer to one another with Web being the poor cousin that never gets invited to parties.

Just some thoughts. I'm not strongly opinionated about anything here.

[joewheaton]

@MattReimer this does require more consideration, but I really like seeing the options you spelt out here. For now, my initial impression is I kind of like Suggestion 3. We have struggled with display order over and over, but I think the crux of the problem si we've been thinking too much about what is the logical order to display the tree to a user and we've been totally inconsistent. For example, sometimes we start with the outputs and end with inputs in business logic (e.g. BRAT). Other times we start with inputs and end with outputs. I think that we overcome some of this with actually using project views! However, if we are conciously organizing our business logic by display orders that make sense (e.g. Hillshade always on very bottom, most transparent rasters above that, and most vector stuff above that) then it might help us out. I am curious what @philipbaileynar thinks...

[MattReimer]

For the record these weren't OR gated suggestions. If I was the end user I would do all 3 because none of them are that hard and it makes the tool better for me.... but I am not the majority end user, just the center of my own little universe. 😺

[joewheaton]

LoL... Well all three it is (that will get Pip's reaction)..

---

Dr. Joseph M. Wheaton 435-554-1247 (direct) | http://www.joewheaton.org

On Tue, May 18, 2021 at 10:08 AM Matt @.***> wrote:

For the record these weren't OR gated suggestions. If I was the end user I would do all 3 because none of them are that hard and it makes the tool better for me.... but I am not the majority end user, just the center of my own little universe. 😺

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/QRAVEPlugin/issues/19#issuecomment-843308894, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKGAAOCWYACTZNQRWVKM6DTOKGGRANCNFSM45BQFUWQ .

[philipbaileynar]

1. I normally despise duplication, but in this case I really like @MattReimer suggestion of duplication project view layer trees to enable rapidly turning on and off visibility of entire groups of layers.
2. As I have tried to communicate in the past, a business logic tree is fundamentally incompatible with ToC may layer tree. We could kill ourselves trying to reconcile the two sets of requirements. It's like playing whack-a-mole. I suggest the following:
   • The project tree is in the "business" of communicating model inputs, intermediates and outputs. Forget about display order!
   • The ToC tree is about visibility... points on top of lines on top of polygons on top of rasters.

For the record... that very last point is what WebRAVE does. It is NOT how ArcRAVE currently works.

[MattReimer]

Just to confirm, the task here is to implement all 3 suggestions above

[MattReimer]

EDIT: SOMETHING I FORGOT:

This is a little more context for the above: Suggestion 3: Duplicating project tree layers for views

Another thing we should make sure we do is to make sure we enforce the view layer ordering.

      <Layers>
        <Layer id="channel_area_polygons" />
        <Layer id="dem" />
        <Layer id="hillshade" />
      </Layers>

This is essentially a stack. Right now QRave does loop over these layers and add them to the map from top to bottom (i.e. starting with channel_area_polygons) but since the add_to_map function chooses its own order the view's stack order isn't respected.

If we want the views to represent the order (and even possibly a different order than things appear in the BL) then we need to make sure we add some kind of override to say "This layer is coming from a view so sort it explicitly with this Z-value" and then pass in the array index from the loop.

[joewheaton]

@philipbaileynar we're over-thinking and over-complicating this display order thing in TOC. After going through the old tickets carefully and making your requested screen shots in #58, I think you and I can solve this in 5 minutes.... not half a day. The key is to do mainly Suggestion 1 & 2 in https://github.com/Riverscapes/QRAVEPlugin/issues/19 much as we just did for WebRAVE.

[philipbaileynar]

OK here is the final word on layer ordering:

ADDING LAYERS TO MAP ALWAYS FOLLOWS BUSINESS LOGIC.

Sounds simple, but this is not how ArcRAVE currently works. Please test QRAVE and ensure it follows this rule.

It's important that this work within group layers. So adding each layer within a project grouping IN ANY ORDER, will always result in a map ToC group layer that mimics the business logic.

Other Notes

1. If the user moves a project layer somewhere else within the top level RAVE project group layer, then it is still considered "in the map" and RAVE will ignore subsequent requests to add it to the map. (I don't think QRAVE respects this.)
2. If the user moves a project layer outside the top level RAVE project group layer, then it is considered "not in the map" and RAVE will add it to the correct player in the map ToC next time the user adds it to the map.

[KellyMWhitehead]

Fixed in eff22739d2dc70e4927c9047eab1b15937eb158d