[Qgis-user] Let's discuss on a Mask feature

[HAUBOURG]

> 
> Before going into details, I just want to point to the fact that generally
> speaking, I really do not like having a mask as a classic layer. Layers are data,
> and a mask is a graphical artefact that is only intended for visualization in a
> particular map output. Therefore, it should be something more like an
> overlay, if not a composer only feature.
> This remark could be relativized if it has some complex implementation
> consequences.
Agreed, I maybe was thinking like a plugin developper, that have few capacities to change underlying implementations. 


> This mask layer feature request is maybe time for a more general question :
> do we want something like <modifier layers> ?

It is an option, but we should then apply modifiers to all layers concerned ? 
Another one is to jump a step beyond and go for a Arcgis - like and add something similar to what they call 'data blocks'. It is a way to handle multi map inside Mapcanvas. 
We could then apply modifiers (including masks) to that Data Block level. I must say it would really be more usable for multi maps composers. In current state, modifying multimaps is a pain, playing with data groups, composer and 'lock layer options', with many window switches to tune Composer correctly. I would then appreciate to be able to switch to "Paper units" projection and be able to tune labeling exactly as it will be rendered on paper. 
IMHO, we are discussing here of a major evolution, touching API.. QGIS 3.0?  




> That would enable to do compositing for example, like in the gimp ? You
> could attach a <modifier> to a specific layer, which would add effects to the
> layer, but would not be a layer by itself, just added rendering options with
> parameters (a mask could be one of those modifiers).
> Modifiers would not affect the way the features themselves are drawn, but
> the way the global resulting image is printed on screen for that layer.

I'm not familiar with those tools. Isn't it too far away from the goal of keeping QGIS simple and very usable for common users? 

> > > We could also have a button in the composer to <create a mask for
> > > this map based on the currently selected features in the map window>.
> >
> > No, because when exporting in batch mode with Atlas can't deal with a
> > manual selection.
> 
> When exporting in batch mode for atlas then you have this mask generated
> automatically in the composer, based on the current coverage. That's exactly
> the same than for a mask layer, except that it's a composer geometry object,
> attached to a specific map.

Sorry, I think I misunderstood previously. OK with you.


> 
> > - When Atlas is not activated, then composer Maps should only show
> > current map state (with Mask ON or OFF). IMHO when several maps are in
> > the composer, users wish to use mask only on some maps. If we want to
> > keep actual workflow, that implies using the "Lock layer for this map"
> > to show some layers or not on each map.   Then I see no other choice than
> > materializing Mask as a layer. That layer  would have a special behavior:
> > it should be able to mask all labels of layers that lies under it, but
> > not those lying on top of it. Options could be using a buffer and its
> > size, simplify feature on the fly or not + threshold.
> 
> I think the labelling point would be the most tricky to handle, as labels are
> normally drawn for the whole map afterwards. I do not know enough of the
> labelling part to discuss it in depth though, inputs welcome.

Well, Objects are already modified on the fly before labeling for some options :
See "labels only objects in extent" and "Label using perimeter" options. Geometries are clippes with BBOX of current mapcanvas, and then are used for labeling?
This induce new bugs I just reported yesterday : http://hub.qgis.org/issues/6835



> 
> > That would allow a user to switch differents masks on and off, and to
> > use them or not in different Composer maps. A memory layer would be
> > fine for it.. BUT we need a way to save them along with the project.
> > THAT implies we need to commit in CORE "Memory Layer Saver" features.
> > (previously discussed here [0], but left opened)
> >
> >  - When Atlas is activated, the idea is to let Atlas code generate a
> > temporary mask layer fo each object of Coverage Layer, and suppress
> > the mask layer each time a export iteration is done. Buffer and
> > simplify options could be retyped in Atlas Panel and then passed as
> > arguments to Mask classes.
> 
> Looks complicated to me, generating a data layer each time to have a display
> feature sounds a complex way of handling things. But maybe it is the most
> reasonable one.
Of course, any better implementation idea is welcome!

> 
> > > The only drawback to this approach is that the labels will be
> > > covered by the mask, and will appear truncated if part of it lies
> > > under the mask. I do not know if this would be a blocker.
> >
> > This is a BLOCKER, since this is what Mapinfo does, and this is not
> > satisfying at all. People do workarounds like cookie cutter to destroy
> > objects outside the mask. We loose the dynamic link with data and
> > batch Atlas possibilities. This is why I was asking devs on risks of
> > it, and submitting the idea of simplifying the masks polygon. Warnings
> > would be welcome if polygons have to much vertices and parts , along
> > with suggestions to mask less layers, and simplifies polygons..
> 
> The label issue is again probably the most complicated one. If this is a blocker,
> we should go deeper into the way labelling works, as it's gonna be complex.

> 
> Before speaking about performance and technical aspect, we should agree
> on where in QGIS this kind of display-oriented <layer> should go : composer,
> some kind of modifier layer, overlay layer, or classic data layer, or another
> better solution ?
Or change global logic to add multimap capabilities in Mapcanvas. 

> We should generalize the problem, find a global concept, and verify that
> masking is covered by it.
> Or is masking the only forseen feature of this kind ?
+1


> 
> What do other think of it ?
> 
> Vincent
> 
> >
> > > Therefore the question is : do we need this in the main map window,
> > > or this solution for composer would be enough ?
> > >
> > > We'd be glad to implement that in composer and Atlas if this is a
> > > good solution for you.
> >
> > Sure ;-) but we need to find a global agreement on it, and we
> > previously need to act what method is choosen to implement Memory
> > Layer persistency in core. I'll be glad to fund this too.
> >
> >
> >
> >
> >
> > [0] -
> > http://osgeo-org.1560.n6.nabble.com/Memory-data-provider-
> persistence-t
> > d410
> > 8012.html