ton of available area units (eg m2, km2, mi2, ft2, yd2, ha, ac,
etc)
Adds a new option in both the QGIS setting and project properties to
set the units used for area measurements. Just like the distance
setting, this defaults to the units set in QGIS options, but can
then be overridden for specific projects.
The setting is respected for area calculations in:
- Attribute table field update bar
- Field calculator calculations
- Identify tool derived length and perimeter values
Also adds unit tests to ensure that area calculated by attribute table
update bar, field calculator and identify tool are consistent wrt
ellipsoidal calculations and area units.
TODO: make measure tool respect area setting
(refs #13209, #4252 and fixes#12939, #2402, #4857)
Adds a new option in project properties to set the units used for
distance measurements. This setting defaults to the units set in
QGIS options, but can then be overridden for specific projects.
The setting is respected for length and perimeter calculations in:
- Attribute table field update bar
- Field calculator calculations
- Identify tool derived length and perimeter values
- Default unit shown in measure dialog
Also adds unit tests to ensure that length and perimeter calculated
by attribute table update bar, field calculator and identify tool
are consistent wrt ellipsoidal calculations and distance units.
(refs #13209, #12939, #2402, #4857, #4252)
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.
Rationale:
- there was a lot of large objects passed by value, so potentially
there's a speed bump from this
- even for implicitly shared classes like QString/QList there's still
a (small) cost for copying the objects when there's no reason to
- it's the right thing to do!
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.
- update methods of existing classes
- add comment to methods missing in the sip bindings
- split up collective sip files into single files and use
same directory structure in python/ as in src/
- add a lot of missing classes (some might not make sense because of
missing python methods in those classes)
- remove some non-existing methods from the header files
- add scripts/sipdiff
- replace some usages of std::vector and std::set with QVector/QSet
that might try to fix the missing layers. There's a default handler (QgsProjectBadLayerDefaultHandler) which simply ignores
all missing layers. Then there's a GUI handler (QgsProjectBadLayerGuiHandler) in GUI library which asks user about
the path for missing layers. QGIS application automatically installs the GUI handler on startup.
This should allow python plugins/applications to work with QgsProject without a fear of a segfault as there are no more
exceptions thrown during load/save of the project files.
Some further notes:
- removed QgsProjectBadLayerException class and (now empty) qgsexception.cpp file
- openFilesRememberingFilter() moved to QgisGui namespace (was duplicated: QgisApp vs QgsOpenVectorLayerDialog)
- removed deprecated buildVectorFilters_ methods
- added python bindings for new classes/methods
git-svn-id: http://svn.osgeo.org/qgis/trunk@12350 c8812cc2-4d05-0410-92ff-de0c093fc19c
