Map Compare - Swipe and overlay.

[NathanW2]

QGIS Enhancement: Map Compare - swipe and overlay.

Date 2018/09/09

Author Nathan Woodrow (@nathanw2)

Contact woodrow.nathan at gmail dot com

maintainer @nathanw2

Version QGIS 3.4

Summary

This QEP covers adding the ability the current layers in the map canvas with a saved theme using swipe or overlay transparency.

Users will be able to select a map theme to compare the active canvas layers against using a new UI control attached the main canvas. This will be rendered and created as an overlay on the main canvas that will enable them to swipe from left/right, top/bottom, or full overlay transparency to fade in and out.

{example image}

(Ignore the black lines over the map)

The user will be given a new UI control in order to control the theme to compare with as well as the mode and value in the form of a slider.

Existing plugin

A plugin, MapSwipe Tool, already exists to give this function to 2.x users. That plugin is based on some early prototype work and uses a QgsMapCanvasMap while waiting for events from the canvas. This works quite well for 2.x, however, a more stable and deeper integrated approach would be better for 3.4. (It's also worth noting that QgsMapCanvasMap was removed from the Python bindings in 3.0, so porting the plugin to 3.x will be tricky).

Proposed Solution

Update QgsMapCanvas with the following new methods (pending name changes):

• setCompareMode(CompareMode mode)
• setCompareValue(bool value) (sets the current "percent" of the comparison to use - the actual meaning will vary depending on the compare mode. E.g. for a split compare this corresponds to the pixel position at which the split occurs, and for an Overlay mode it corresponds to the opacity level of the overlay).
• private: renderFinishedCompare()

CompareModes contains

• Disabled
• SplitV
• SplitH
• Overlay

In order to render the new overlay, it will include a new render job and QgsMapCanvasMap item in QgsMapCanvas

When enabled the new renderer job will kick off alongside the current main canvas job in order to stay in sync, will also be canceled when the main renderer job stops.

The current rendererFinished() will remain as is and a new renderFinishCompare() will be added to render the overlay.

Preview tiles or printing for the compare renderer job will not be supported.

Whilst adding this in QgsMapCanvas adds complexity to the map canvas API it also allows 3rd party applications to create and use this new API, e.g QField, Roam, etc, without having to re-implement all the logic and rendering jobs themselves.

Current design limits

• Snapping will still only work on the canvas map, not the overlay map.
• All map tools will only work on the non-overlay rendered map.

The above consider that Map Compare is a new mode and would only be used in limited cases and adjusting the tools to understand features on different sides of the map would be a lot harder and not worth the effort vs just not supporting it for the first cut.

• No preview tiles or printing will be supported for the overlay.
• All plugins that connect to renderComplete signal will still only get the main QPainter for the main job. A new signal can be created for the compare map if needed.

Example(s)

{example image}

Affected Files

• QgsMapCanvas()

Performance Implications

As this is connected to QgsMapCanvas and the main render job start/end it should never block the user and only render when it is ready, even if this is after the main canvas has finished. This will ensure that the user can continue to work without blocking while it renders the compare side.

All start and end events on the main render job should be connected to the compare job in order to keep things in sync.

Compare job will be run async in order to not block.

Further Considerations/Improvements

Backwards Compatibility

• No API break

Issue Tracking ID(s)

(optional)

Votes

(required)

[NathanW2]

@wonder-sk @nyalldawson @m-kuhn @nirvn This is open now for your comments. I'm keen to try and get this into 3.4 if possible.

[nyalldawson]

+1 to using map themes here. The existing plugin uses individual layers, which is limited and tricky to manage (as a user). Taking advantage of map themes means this ties nicely into the additional map canvas functionality too.

Whilst adding this in QgsMapCanvas adds complexity to the map canvas API it also allows 3rd party applications to create and use this new API, e.g QField, Roam, etc, without having to re-implement all the logic and rendering jobs themselves.

Agreed. On that note, what's the plans for extra map canvases? Will they be swipe enabled? Or is that overkill?

Snapping will still only work on the canvas map, not the overlay map. All map tools will only work on the non-overlay rendered map.

To me this is a big feature. Overlays are just that - an overlay "on top" of the actual real map. So I like that they are totally transparent to user events and don't affect any map tools or snapping.

[NathanW2]

Agreed. On that note, what's the plans for extra map canvases? Will they be swipe enabled? Or is that overkill?

I would say we don't do it at this stage but if they are just a QgsMapCanvas then nothing stopping it in the future.

[nyalldawson]

I would say we don't do it at this stage but if they are just a QgsMapCanvas then nothing stopping it in the future.

+1 - it would be a lot of added ui complexity for quite a limited use case.

[nyalldawson]

@nathanw2

Got any other ideas of cool comparison techniques? I did a brief scan of what else is out there and the only other one I found was the "spotlight" style overlay (but honestly to me I can't see how that one is actually useful for comparison as opposed to being just a neat effect).

[andreasneumann]

See also https://hal.inria.fr/hal-01144163/document and https://www.youtube.com/watch?v=-q702OTBpT8 and

[andreasneumann]

From my own personal judging, while the "blending lense" and "offset lense" look "sexy" probably juxtapose and swipe are more efficient. I like the "translucent overlay" the least.

So the juxtapose technique shown in the above paper is already possible in 3.2 by introducing a second map frame - right? The important thing is that the cursor shows the same location in the different frames.

From a usability point of view, it would probably still make sense to introduce a "juxtapose" mode along with the "swipe" mode in one single map frame.

I personally found the map frame thing a bit complicated to set up for beginners (too much freedom, too many options).

[andreasneumann]

Actually I revise my statement a bit: on second thoughts, the "translucent overlay" could be just as efficient, if there is a nice UI control to interactively control the level of opacity between the two map themes.

So, ideally, the map comparison tool could support the following three modes:

• swipe mode
• juxtaposition mode
• translucent overlay with a transparency slider

The user can have a choice then.

[andreasneumann]

Interesting summary from the paper:

SUMMARY We characterized and evaluated five techniques for performing interactive map comparison, using real-world maps. The study’s results suggest the following guidelines to UI designers: (1) Translucent Overlay (OV) is the best technique overall, which makes it a good choice when only one comparison technique should be provided to users. (2) Even if its overall performance is not as good as that of OV, Blending Lens (BL) performs as well as or better than OV when the task consists of identifying extra or modified entities. We tentatively attribute this to BL’s mostly motor-driven scanning strategy, which helps structure inspection of candidate features in the upper layer. The combination of OV and BL should be favored by UI designers when possible, as the two are quite complementary. (3) Swipe (SW) and Offset Lens (OL) perform poorly. This is an interesting finding given that SW is a technique commonly encountered in Web mapping applications. Its use should probably be reconsidered.

[nyalldawson]

So, ideally, the map comparison tool could support the following three modes:

Fortunately all the methods from that paper/video could be implemented using the same approach (even offset lense).

My 2c: I've always found swipe to be a poor way to compare maps. The fundamental issue is that it only works for comparisons on the sides of the map - it's very difficult to compare something in the center of the map without the visual distraction of the changes on the left vs right map.

[nyalldawson]

But I should say - great find @andreasneumann. More like this please! (I can't wait to dig back into cartographic improvements in QGIS... it's been too long!)

[NathanW2]

Thanks the good find and feedback. Once I get some more feedback here and general approval I will see what I can get implemented. I suspect most of the work is in the UI and making that work well. The core stuff shouldn't be that hard to do.

[onietosi]

Any progress/updates on this enhancement?