If a .ui file is specified and the widget specified in the .ui file is not
supported by the widgetwrapper which is configured in the layer properties
the system will automatically try to find a better suitable widgetwrapper.
To do this, widgetwrappers (respectively their factories) can return a map of
supported widget types with priority values.
The widgetwrapper which offers the heighest priority for a certain widget type
will be used in case of a mismatch.
Sponsored by OPENGIS.ch special projects team (aka gis.se troubleshooting
section)
Allows you to make labels prefer to overlap features from certain
layers rather than others. Can also be data defined, so that certain
features are more likely to be covered than others.
act as obstacles
Options are either avoid placing labels over polygon interior
or avoid placing over polygon boundaries. (Previous behaviour
was always avoid placing over interior).
Avoiding placing over boundaries is useful for regional boundary
layers, where the features cover an entire area. In this case
it's impossible to avoid placing labels within these features,
and it looks much better to avoid placing them over the boundaries
between features. End result is better cartographic placement of
labels in this situation.
This allows users to set a layer as just an obstacle for other
layer's labels without rendering any labels of its own.
Ideas for UI improvements are welcome!
As it seems to address a meanwhile reverted behavior change in PostGIS 2.1
before it was released (see also https://trac.osgeo.org/postgis/ticket/2834).
This reverts commit 048aff01bb9cf42e2c1c17eb0ddbd81537443e19.
(under the layer properties, rendering tab)
So why would you want this? Well, extremely detailed layers (eg
polygon layers with a huge number of nodes) can cause composer
exports in PDF/SVG format to be huge as all nodes are included in
the exported file. This can also make the resultant file very slow
to work with/open in other programs (*cough* Inkscape *cough*).
Now, these you can force these layers to be rasterised so that the
exported files won't have to include all the nodes contained in these
layers. (Before you could also do this by forcing the composer to
export as a raster, but that was an all-or-nothing solution).
The ideal solution would be a simplification option for composer
exports which would simplify the layers by removing redundant points
at the export DPI, but this is an easy workaround for now.
