Allows direct construction of interval values from years/months/weeks/
days/hours/minutes/second values, without having to construct
a string representation of the interval first
These functions allow for direct creation of date/time values. Previously
this was only possible by going through the to_datetime/to_date/to_time
functions, which are string based and accordingly frustrating/inefficient
to use when you have numeric date/time component values.
* 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.
