92 Enhancements to Create constant raster

[lehtonenp]

This pull request introduces updates to the create_constant_raster.py file. The key changes include:

• Updated help string of the tool
• More parameters
• Use of setHelp() method to parameter variables. This means that the QgsProcessingParameters have changed by how the parameters are initialized and added to the parameter list.

The tool has been tested with the same inputs as the toolkit tests.

[nmaarnio]

I see you tried to match the CLI definition as closely as possible, which is what I had advised, but now I remember this was a bit oddly designing tool in itself which causes problems. I would say there are two core issues in this tool overall: 1) It is too modular as it allows for 3 different methods at the same time and 2) the bounds are too clunky to use this way.

The bounds can be handled with the QgsProcessingParameterExtent which was previously used in this algorithm (this is by far the most convenient way to set the bounds).

About the methods, I think we can leave out the 2. raster creation method from this QGIS tool as I don't see why anyone would like that over using template raster or defining the extent. I don't really like the idea of incorporating even just two very different methods into one algorithm, but that could be still done. So then you would have parameters for: template raster, extent, crs, pixel size, nodata value, constant value and output. The other option is to divide this into 2 tools: create constant raster from template raster and create constant raster manually (or some other, better name). Up to you which one you think is better

[lehtonenp]

@nmaarnio, I now tried to set the extent parameter to be solely the QgsProcessingParameterExtent. Toolkit runs into the issue of an unknown parameter --extent. Is this desired? I might need some more guidance with this.

[nmaarnio]

The CLI function does not have extent parameter at the moment. Let me know how you intend to implement this processing alg and I can modify the CLI functions accordingly.

[lehtonenp]

The easy way out could be to use a parameter named extent that is a string. Like this: 'extent' : '384744.000000000,384836.000000000,6671272.000000000,6671384.000000000 [EPSG:3067]'. However, I could parse the string in eis_processing_algorithm.py based on the name of the parameter. But then there would be the problem of setting the coord_north, _east, _south and _west correctly. I think the easiest way would be the most feasible as well.

[nmaarnio]

The QgsProcessingParameterExtent is the best way to implement this and can be actually handled in the CLI easily – you can take a look at IDW interpolation processing alg/CLI function. What I mainly meant with my previous comment is just the final combination of parameters and whether it will be 1 or 2 separate tools.

So in short, no need to worry about any tricks to convert any parameters. It is just about making the CLI definition to match what we have here.

[lehtonenp]

I will divide the tool into 2. It grows the list of functions in the Plugin but creates clarity over which tool to use.

[nmaarnio]

Tested together with PR GispoCoding/eis_toolkit#369 and works. Merging