Adds X and Y (or latitude/longitude) fields to a point layer.
The X/Y fields can be calculated in a different CRS to the
layer (e.g. creating latitude/longitude fields for a layer in
a project CRS).
Sponsored by SMEC/SJ
The centroid of the geometry is used for the point parameter value.
This makes it easier to write expressions for the value of point
parameters, since all the QGIS expression functions for working
with geometry types return QgsGeometry value themselves (e.g.
make_point, centroid, ...). In this case it's much nicer to
allow expression values like `make_point(3,4)` within a precalculated
expression based value in a Processing model.
The spatial_ref_sys table has srid column with ID of CRS entries.
I believe the IDs can be arbitrary, however it has been a good habit
to use EPSG number for srid (at least in GDAL - and the same thing
happens in PostGIS - srid values are the same as EPSG numbers).
In QGIS import if we add a new row to spatial_ref_sys table, the code
was using srsid() as ID which is internal ID in QGIS srs.db and it has
nothing to do with other IDs. Some pieces of code (probably incorrectly)
expect that srid is actually the EPSG number, so let's use those
so that we are consistent with GDAL and fix these minor issues
(for example, tooltip of MS SQL layers in browser show srid - which
in case of layers loaded with QGIS were meaningless)
Even though not all errors are caught by these new tests, it could
expose if otb is broken or if processing api is changed to adopt
optional status of parameters at run-time.
`alg.processAlgorithm()` is running and failing correctly.
But `parameter.checkValueIsAcceptable()` and `alg.checkParameterValues()`
aren't working as expected.
Parameters are marked required in descriptor file for certian
applications but they are only required if a parent parameter has a
"certain" value. So initial idea was to make all of those parameters
optional from OTB part. So that qgis can work correctly and was a easy
fix. But.. we (me and Antonie) decided not to take that route and
found a better fix.
`OtbParameterChoice` and its wrapper will update optional status of
all sub-parameters depending on the value of a choice parameter.
A test has been added to check this issue and will be available in
next commit.
getWindowsCodePage is taken from Grass7Utils.py
Instead of writing a cli_file at startup, provider now pass all
required env_variables directly to subprocess.popen. This has known to
cause issues when handling with windows path names. subprocess.Popen
handles it correctly depending on platform
Logging of output from otbalgorithm and updating progress bar is
slightly updated.
Algoirthm is now launched directly using otbApplicationLauncherCommandLine
`encoding` (on windows) and env arguments passed to subprocess is
logged in QgsMessageLog
