i.zero2null: fix nodata handling if nodata-border is already present

[griembauer]

This PR fixes the following issue in i.zero2null:

Bug description

In some cases, i.zero2null results in blurred (=extrapolated) image borders where null() should be. This occurs if there already is a nodata-border in the input map. An example of a Sentinel-2 scene processed with i.zero2null:

to reproduce

• start GRASS in an epsg:32630 location
• download Sentinel-2 scene S2A_MSIL2A_20210329T105631_N0214_R094_T31UCV_20210329T134554 (e.g. via i.sentinel.download)
• set the region to g.region n=5944230 s=5603910 w=564260 e=823750 res=10 -p
• import a Band from the scene with i.sentinel.import extent=region ...
• run e.g. i.zero2null map=T31UCV_20210329T105631_B08_10m

fix

The bug is introduced because
a) Setting the region to the input raster does not necessarily set it to the maximum no-null() extent. This is now ensured with g.region zoom=...
b) After setting the region to the input raster, there may be border areas which are already null(). These are now excluded from the result of r.grow.distance too.

[neteler]

May this PR be merged?

[metzm]

Good catch, I did not encounter this case in my tests, please merge!

[metzm]

Sorry, the fix in this PR is not correct. i.zero2null must be used before reprojection to avoid artefacts at the transitions from zero to non-zero cells. In this example, i.zero2null is used after reprojection (from UTM zone 31 to UTM zone 30), this is too late, artefacts have already been introduced.
A proper fix would be to check if there are both NULL and zero cells in the input image (with e.g. r.info -s, if yes, exit with a warning like "Sorry, too late, the input image has already been reprojected".

[metzm]

A good place for this zero2null method would be r.import with a new -z flag where zero2null could be applied before any reprojection happens. I would keep this i.zero2null addon anyway for cases when r.in.gdal is used directly.
@griembauer Could you create a corresponding PR for r.import?

[ninsbl]

A good place for this zero2null method would be r.import with a new -z flag where zero2null could be applied before any reprojection happens. I would keep this i.zero2null addon anyway for cases when r.in.gdal is used directly.
@griembauer Could you create a corresponding PR for r.import?

See also:
OSGeo/grass#580

[griembauer]

Thanks @metzm, I now understand the correct processing order. I agree it would be better to optionally put i.zero2null into r.import before reprojecting. Will create a corresponding PR

[neteler]

@griembauer pls rebase this PR to the (new) grass8 branch

[griembauer]

This PR can be closed as the fix should be added to r.import (see @mmetz comment)