Implements a method in QgsGeometry and a processing algorithm to
calculate the pole of inaccessibility for a surface, which is the
most distant internal point from the boundary of the surface. This function
uses the 'polylabel' algorithm (Vladimir Agafonkin, 2016), which is an iterative
approach guaranteed to find the true pole of inaccessibility within a specified
tolerance. More precise tolerances require more iterations and will take longer
to calculate.
fixes#14703
Include C++ and Python tests
Travis won: ported all test cases to Python
and disabled C++ companion test (still useful locally and
for debugging)
For the curious: QTemporaryFile is not working as expected
Moved to Qt5 new style signals
Disabled C++ test and connected cancel to progress
Make string comparison on SSL errors more robust
Better solution is to set handlesNull to true to avoid the default
null parameter = null result behaviour, and handle null values
in params 1 and 2 manually
- support negative start value (e.g. substr('hello',-2) returns 'lo')
- support negative length value (e.g. substr('hello',3,-1) returns 'll')
- length parameter now optional, defaults to end of string
(e.g. substr('hello world',7) returns 'world')
default value SQL clauses
QgsVectorDataProvider now has two methods:
- defaultValueClause: returns SQL fragment which must be evaluated
by the provider to obtain the default value, eg sequence values
- defaultValue: returns the literal constant default value
for a field
The new function returns an array of strings captured by capturing
groups in a supplied regular expression. For e.g., the following
expression: regexp_matches('qgis=>rocks','(.*)=>(.*)')
will return the following array: 'qgis', 'rocks'.
With a new option to prefer to snap to closest point on geometry.
The old behaviour was to prefer to snap to nodes, even if a node
was further from the input geometry than a segment. The new option
allows you to snap geometries to the closest point, regardless
of whether it's a node or segment.
Warnings are shown, but features can be committed. Fields which
fail an unenforced constraint are now shaded in yellow to differentiate
from the red failure for enforced constraints.
Non-enforced constraints just show a warning to the user, but
do not prevent committing the feature. Enforced constraints
block users from comitting non compliant features.
Any constraints detected by the provider are always
enforced.
and not any constraints enforced by the provider
Because:
1. we want to keep browsing features nice and responsive. It's nice to give
feedback as to whether the value checks out, but not if it's too slow to
do so. Some constraints (eg unique) can be expensive to test. A user can
freely remove a layer-based constraint if it proves to be too slow to
test, but they are unlikely to have any control over provider-side
constraints
2. the provider has already accepted the value, so presumably it doesn't
violate the constraint and there's no point rechecking!
