[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.
This adds the possibility to manage data on a normalized relational
database in N:M relations. On the relation editor in a form, the tools
to add, delete, link and unlink work (also) on the linking table if a
relation is visualized as N:M relation.
Configuration is done through the fields tab where on the relation a
second relation can be chosen (if there is a suitable relation in terms
of a second relation on the linking table).
Limitations
===========
QGIS is not a database management system.
It is based on assumptions about the underlying database system. In
particular it expects
* A `ON DELETE CASCADE` or similar measure on the second relation
* Does not take care of setting the primary key when adding features.
Either users need to be instructed to set them manually or - if it's a
database derived value - the layers need to be in transaction mode
(currently only activatable through the API)
This check tests that if a function has been declared deprecated
with either Q_DECL_DEPRECATED or has a @deprecated Doxygen note
then it MUST have both the Q_DECL_DEPRECATD and @deprecated note.
It's important that both are used, as Q_DECL_DEPRECATED allows
throwing a warning if that method is used in code, while the
@deprecated doxygen note gives an indication to devs/PyQGIS users
of why it's deprecated and what should be used instead.
Ideally we'd also test for SIP /Deprecated/ tags, but I can't
find any reliable way to do this.
* make sip coverage test aware that there are less classes where QSci sip
headers are not available
* exclude properties from members
* fix QgsFeatureIds typedef (fixes missing signal
QgsVectorLayer.featuresDeleted and others)
* add missing notes for PyNames
* include some missing new methods in bindings
This introduces two new options to filter legend elements:
- filter by expression: a boolean expression can be set. Only symbols of
features that make the expression evaluated to true will be kept in the legend
- filter by polygon: only symbols of features that are inside the given
polygon will be part of the legend.
The polygon filtering is used in particular for a new option in the
composer legend that allows to filter out anything that is not included
in the current atlas polygon.
Not perfect, but good for a quick warning if a new class or member
has been added to the public API without Python bindings. The test
only considers the name of members, since it seems to be impossible
to test for the signature of a Python member. (So adding a new
overloaded method without bindings will still unfortunately pass).
You can avoid the test where bindings are not applicable:
- for a whole class by placing "@note not available in Python bindings"
in the class' Doxygen comments
- or by placing the @note inside a member's Doxygen comments for a
specific member
Additionally, classes which aren't included in the API docs
will not be tested.
