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
Fixes:
- enum parameters set to "allow multiple" only allow a single
value selection when used in modeler
- optional enum parameters cannot be set to no value when
used outside of modeler
Fixes#20406
* include processing algorithm descriptions from yaml (with yaml fixes)
* create ui instead of cpp where possible and use -no-ui-lines to avoid
artificial ever changing line numbers in ts files
* drop old used scripts: create_new_ts.sh, create_new_ts.sh and
integrate_function_help.pl, update_ts_files.sh
causing rings errors
By default the algorithm now uses the strict OGC definition of polygon validity, where
a polygon is marked as invalid if a self-intersecting ring causes an interior hole.
If the "Ignore ring self intersections" option is checked, then this rule will be
ignored and a more lenient validity check will be performed.
Refs #16418, refs #21336
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 is a continuation of:
- #8db3dead87e385f2798356d
- #5c97d22b16320874dbe1
This commit only affects users that have multiple GRASS installations on
their Macs. Using the most recent GRASS version is what we do on Linux too.
After @Nyalldawson suggestion [1], we've implemented a Processing plugin
that exposes a GRASS Addon [2]. In order to do this we had to subclass
`Grass7AlgorithmProvider` and override `createAlgsList()`.
`createAlgsList()` had to be overriden in order to change the
"description folder" location.
Nyall wrote:
> And if you do it right (and only import existing
> processing grass code, minimising the copy/paste of this code), then
> your provider will automatically inherit any future fixes and
> features added to the main grass provider.
With this commit we convert the `descriptionFolder` to a class attribute
and in this way, subclasses of `Grass7AlgorithmProvider` will no longer
have to override `createAlgsList()` and will be able to continue inheriting
future enhancements.
References:
1. https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056155.html
2. 948820b1c0/estimap_recreation_provider.py (L40-59)
We no longer require the seperate CRS parameter, because the extent
parameter contains the CRS information itself. This means the algorithm
is simplified to just picking the layer and drawing the desired area
on the canvas.
