* add expressions for min and max M and Z - including tests
* add my info to contributors.json
* Apply suggestions from code review
suggestions to help for expressions from Nyall
Co-Authored-By: Nyall Dawson <nyall.dawson@gmail.com>
* Apply suggestions from code review
add suggestions to qgsexpressionfunction.cpp from Nyall
Co-Authored-By: Nyall Dawson <nyall.dawson@gmail.com>
* [feature][expressions] - fix expressions Z/M min and max
* [feature][expressions] - fix styling Z/M min and max expressions
Co-authored-by: Nyall Dawson <nyall.dawson@gmail.com>
To complete the existing function layer_property(...), this change add a new argument 'distance_units' for return a string with the layer distance units (see QgsUnitTypes::DistanceUnit)
This function can be used for display units for labels, in layouts or for access to more layer properties in the expression builder for algorithms.
And when running srssync, return early if the version number is unchanged
from the last run.
This avoids running the full (slow, on proj 6 builds) srssync with
every build, which is PITA for rapid development...
Instead of hardcoding these values, allow them to be customised by changing
settings in QSettings (either via the settings ini file or through the
advanced settings editor), as some serial GPS devices require non-default
settings for the connection to work correctly.
to be placed on the maximum number of point, line and polygon candidates
which are generated for label features
These settings are set via the core\rendering\label_candidates_limit_*
settings, and allow for global limits to be set on the maximum number
of candidates allowed for label features. Placing these limits can
improve map rendering time, at the expense of worse label placement or
potentially missing map labels. (By default no global limit is set, which
means the labeling engine auto calculates the limit or uses the project
level settings)
The intended use case is for server administrators who are seeking for
maximum rendering speed to globally set these limits, causing them to
apply to all projects without the need for project-specific tweaks.
By default, those expression use the application's locale. The addition of an optional
language parameter allows handling of dates that wouldn't match that default
locale (say for e.g. an English system running QGIS trying to transform a
French-formatted string into a date object).
