This adds a configuration interface and renderer that makes it easy to
put all the pieces together which are required to get a 2.5D effect.
It allow for configuring some of the styling and is meant to create an
easy-to-use setup.
Since every part of the system is built around QGIS' internal rendering
and symbology engine, there is much to fine tune. To get all the
possibilities, just change the renderer to a graduated, categorized or
single symbol renderer upon creation and you will find full access to
improve the style to your needs.
Funded by
* Regional Council of Picardy
* ADUGA
* Ville de Nyon
* Wetu GIT cc
[FEATURE] Tracing of features (digitizing)
Tracing can be now used in various capturing map tools (add feature, add part, ...) including reshape and split tools.
Tracing is simply a new mode for these tools - when tracing is not enabled, the tools work as usual. When tracing is enabled (by clicking the new magnet icon or pressing T key), tools switch to tracing behavior:
- first click on a vertex/edge (must be snapped!) will start tracing - moving mouse on top of the map continuously updates the trace
- next click will confirm the trace and mark start of a new trace Tracing can be enabled/disabled anytime even while digitizing one feature, so it is possible to digitize some parts of the feature with tracing enabled and other parts with tracing disabled.
Tracing respects snapping configuration for the list of traceable layers.
If there are too many features in map display, tracing is disabled to avoid potentially long tracing structure preparation and large memory overhead. After zooming in or disabling some layers the tracing is enabled again.
Internally, things work like this:
- when tracing is requested, linestrings are extracted from vector layers, then noded (using GEOSNode to resolve all intersections) and finally a simple planar graph is built (vertices + edges)
- when tracing, endpoints are temporarily added to the graph (if not equal to one of existing vertices already) and Dijkstra's algorithm is run to get shortest path
Original specs for the curious ones (the interaction with QGIS is slightly improved from what has been specified): http://www.lutraconsulting.co.uk/crowdfunding/autotrace-phase-2/specification.pdf
Now all classes and members are either exposed to bindings or marked
as "not available in Python bindings" in the docs.
Drop test thresholds to 0. Now it should be much easier to determine
what missing members have been added which are causing test
failures.
* layerFilterExpression
Return an additional filter, used in
WMS/GetMap, WMS/GetFeatureInfo, WFS/GetFeature to filter the features
* layerFilterSubsetString
Return an additional the subset string (typically SQL) filter.
Faster than the layerFilterExpression but not supported on all the
type of layer
* layerPermissions
Change the rights on the layer per user (known by the plugin)
Concern rights: publish, insert, update, delete.
Mostly used in WFS/Transaction, and the publish in all requests.
* authorizedLayerAttributes
Be able to show some attributes only for a subset of user
Used in: WMS/GetFeatureInfo, WFS/GetFeature
* allowToEdit
Be able to don't allow to edit a particular feature, in our case base
on the Geometry
Used in: WFS/Transaction
* cacheKey
Cache key to used to create the capabilities cache, "" for no cache,
shouldn't contains any "-", default to ""
This commit adds the ability for expressions to be evaluated against
specific contexts. It replaces the previous behaviour where
expressions were evaluated against a specific feature and could
utilise fragile global "special columns".
Now, expressions are instead evaluated using a context designed for
each individual expression. This is done via QgsExpressionContext
and QgsExpressionContextScope objects.
A QgsExpressionContextScope encapsulates the variables and functions
relating to a specific context. For instance, scopes can be created
for "global" variables (such as QGIS version, platform, and user-set
variables specified within the QGIS options dialog. Think things
like user name, work department, etc), or for "project" variables
(eg project path, title, filename, and user-set variables set
through the project properties dialog. Project version, reference
number, that kind of thing). Many more scopes are planned, including
map layer scopes (variables for layer name, id, user-set variables
through the layer properties dialog), composer scopes, etc...
QgsExpressionContextScopes are 'stacked' into a QgsExpressionContext
object. Scopes added later to a QgsExpressionContext will override
any variables or functions provided by earlier scopes, so for
instance a user could override their global 'author' variable set
within QGIS options with a different 'author' set via the project
properties dialog.
The intended use is that a QgsExpressionContext is created before
a batch set of QgsExpression evaluations. Scopes are then added to
the context based on what makes sense for that particular
expression. Eg, almost all contexts will consist of the global
scope and project scope, and then additional scopes as required.
So a composer label would be evaluated against a context
consisting of the global scope, project scope, composition scope
and finally composer item scope. The batch set of expression
evaluations would then be performed using this context, after which
the context is discarded. In other words, a context is designed
for use for one specific set of expression evaluations only.
methods are now in core
A new QgsVisibilityPresetCollection object has been created
which stores a set of visibility presets. QgsProject now
contains a preset collection object.
This allows plugins and other core objects to retrieve and
modify visibility presets.
A new QgsStringUtils class has been added containing some
common fuzzy matching algorithms, including Levenshtein edit
distance and Soundex. These can be used for finding "similar"
strings in a table.
Expression functions for these algorithms have also been
added to a new "Fuzzy Matching" group.
This commit adds a new framework for implementing paint effects, which
modify the results of QPainter operations to apply visual effects
such as drop shadows and blurs.
The initial implementation allows for effects to be applied to entire
layers and individual symbol layers.
Included are a drop shadow, inner shadow, blur, inner glow, outer glow,
colorise and transform effect. A "stack" effect is also implemented
which allows other paint effects to be combined in various ways.
Sponsored by hundreds of generous kickstarter contributors!
Contains framework for multithreaded operations on QImages, and
numerous operations such as grayscale, hue/saturation, brightness/
contrast modification, flip, blur, distance transform, alpha
modification and color overlays.
Allows for live, dynamic heatmaps for point layers. Options include
specifying heatmap radius in pixels, mm or map units, choice of
color ramp, and a slider for selecting a tradeoff between render
speed and quality.
The multirenderchecker allows to have several images, each with its own set of
anomalies distributed in several subdirectories.
With the help of multiple reference images, it is possible to apply a color
tolerance to each of these
QToolButton. Features:
- context menu items have been moved to the attached menu button
- new gui widget QgsColorSwatchGrid, which displays a grid of colors
- new class for QgsColorScheme, which generates colors to show in a
color swatch grid
- new class QgsColorSchemeRegistry, with a global instance containing
default color schemes. QgsColorButtonV2 accepts a color scheme
registry, to control which schemes to show in the popup menu as
color swatch grids.
- color button can have a default color
- color button can also be quickly set to a totally transparent color
- c++ and python unit tests for all core components
- map layers have associated QgsMapLayerLegend instance
- QgsMapLayerLegend is interface for generation of legend with some default implementations
- QgsLayerTreeModelLegendNode is interface for representation of legend item in layer tree model with some default implementations