proposal: make -a flag the default behaviour for g.region

[mlennert]

In my experience, when working with raster, having a precise resolution is the most important issue, while exact extension is less important. I often use existing vector data or bounds coordinates to determine the extent, but then have to use the -a flag to make sure that the desired resolution is kept.

I would like to propose that in grass7, the behaviour is switched, i.e. to make the -a flag (Align region to resolution) the default behaviour, and "align to bounds" the option.

I know this is a fundamental change in a fundamental module, but it's been itching for quite a while and I always find myself in difficulties having to explain to students why GRASS' default behaviour is the way it is...

Moritz

[hamish]

I always find myself in difficulties having to explain to students why GRASS' default behaviour is the way it is...

Consider importing a grid-referenced dataset from 3rd party enviro model output:

g.region n=100025 s=49975 w=69975 e=120025 res=50

Using '-a' breaks that by rounding to n=100050 s=49950 w=69950 e=120050. (take care, d.zoom in grass6 does -a by default)

(I don't know about anyone else, but I have to deal with this all the time when importing various ocean model data)

That's not specifically to say preserving the bounds is more important than preserving the resolution (we'd be trading nice round resolution for ugly nsew bounds; one problem for another, pick your poison), just that IMO by default GRASS should try to do the least-damaging thing (whatever that may prove to be..) even if that pursuit of best-correctness means adding an extra lesson to the admittedly steep learning curve.

Hamish

[mlennert]

Replying to hamish:

I always find myself in difficulties having to explain to students why GRASS' default behaviour is the way it is...

Consider importing a grid-referenced dataset from 3rd party enviro model output: g.region n=100025 s=49975 w=69975 e=120025 res=50

[...]

(I don't know about anyone else, but I have to deal with this all the time when importing various ocean model data)

Ok, just wasn't aware of such use cases. Closing this as won't fix.

Moritz