wxGUI/gmodeler: Correct variable replacement in model_convert.py

[gureckyfrantisek]

I found the issue which caused the previous variable in the same string not get recognized.

The issue was that when another match was found, the old value got replaced instead of the updated one called "parametrizedValue".

Also made the curly braces around variable names optional, they get recognized correctly but leaving them mandatory should be readable, that is up for debate.

I tested this with r.in.pdal and a *.laz file and the import worked as expected with both the values replaced with options.

This will resolve #7212.

[landam]

Curly braces enclosing variables were introduced in version 8.5. I assumed this change was meant to ensure backward compatibility, which would be nice. I tested to load model without braces (attached in the issue), the conversion to Python works. But attempt to run the model (directly from the modeler, not converted Python code) fails - no variables are substituted.

p.in.pdal -e -o --overwrite input=%path/dmp1g/%tile.laz output=%tile_dmp method=mean type=FCELL zscale=1.0 iscale=1.0 resolution=%resolution dimension=z
...

Backward compatibility wasn’t explicitly mentioned in the issue. I think it’s fine to keep this change in the PR, but in that case the model execution should be fixed as well.

[gureckyfrantisek]

With the latest commits I changed every re.compile in the gmodeler folder have optional curly braces.

I managed to both run the model directly and have the values parametrized in the generated python code, but I had a leftover empty raster in my map at the end of the process:

Failed to run command 'd.rast map=%tile_chm'. Details:

GRASS_INFO_ERROR(70582,1): Raster map <%tile_chm> not found
GRASS_INFO_END(70582,1)
Failed to run command 'd.rast map=%tile_chm'. Details:

GRASS_INFO_ERROR(70665,1): Raster map <%tile_chm> not found
GRASS_INFO_END(70665,1)

I couldn't see, where the d.rast function is called, it's not in the model or the python code.

It doesn't break it, so I didn't look for a solution yet.

[gureckyfrantisek]

I realized that the regex now allows for a variable to be parametrized as %{tile.laz or %tile}.laz, which works but could be unwanted behavior.

Should I improve the regex based on this realization?

[landam]

ealized that the regex now allows for a variable to be parametrized as %{tile.laz or %tile}.laz, which

@gureckyfrantisek Yes, please refine the regex—either adopt curly brace syntax (%{tile}), which is recommended in GRASS 8.5 and newer, or retain the older format (%tile) for compatibility with GRASS 8.4. Nothing between.