This adds a second variant for the existing "attribute" function.
The current function requires both a target feature and attribute
name to be specified, while the NEW variant just uses the current
feature.
E.g.
NEW:
attribute( 'name' ) -> returns the value stored in 'name' attribute
for the current feature
EXISTING:
attribute( @atlas_feature, 'name' ) -> returns value stored in 'name'
attribute for the current atlas feature
It's just a faster shorthand version!
OTB only supports gdal and ogr providers for now. Maybe memory
provider can be easily supported using some conversion on the fly.
For the moment, we can go with this method. IO Formats in OTB not
using GDAL/OGR (LUM, ONERA) are not supported by QGis. Those can be
treated as simple files.
nyalldawson, pointed that AUTHORITY id can have types not starting
with 'EPSG:'. Current otb takes just EPSG number and run with it. The
algorithm doesn't know what to with a number which is not EPSG because
it uses Gdal's 'ImportFromEpsg' method AFAIR.
QgsProecessing Exception is raised in both the above invalid cases.
This can easily go into GuiTests.py but we tend to keep it out due to
usage of create_from_metadata(). All widget in GuiTests uses
create_from_class() which will not work for this special widget
Whenever user would click on the map (e.g. to identify a feature),
the freeze and subsequent unfreeze would force map refresh even though
it is not needed. A new internal flag is introduced to avoid
the unnecessary map refresh in cases when map has not been moved nor zoomed.
Often when users want to click (tap) the map, they still move the cursor
position a bit. This would trigger unwanted map pan and map refresh afterwards.
A configurable minimum drag distance is introduced in order to prevent that.
* [vertex tool] rename mSelectedFeature to mLockedFeature
* also rename file and class
* remove uselesss method, move code to constructor
and initialize in header
* followup rename
When user was coming with mouse to a vertex of the locked feature
from a different feature, it could happen that the vertex would not
get picked by vertex tool - this was because snapToEditableLayer()
keeps the last snap which would belong to a different feature, but
that feature was not allowed (blocking a new snap).
The fix makes sure that with a locked feature its matches always win.
A small UX improvement: after right click in a location with feature A and B,
we would do a loop A - B - nothing - A - B - nothing ...
But if after first click to get A locked user would move the mouse a bit,
the loop would get broken and would end up with A - nothing - B - nothing - A - B - nothing
The fix is to identify where we are in the cycle and set the index correctly after mouse move.
It was a bit strange effect when locking feature... when moving mouse
over a feature it would have highlight, then on right click it would
also get vertex editor square markers in addition to the highlight, but
then immediately after mouse move the original highlight would be gone.
Now it's simplified so that feature highlight on right click gets removed.
