[GRASSLIST:3162] Re: [Fwd: New User Creating first Location]

[Paul Kelly]

On Tue, 13 Apr 2004, Richard Greenwood wrote:

> The units would be based on your projection. Meters for UTM, degrees for
> lat/lon, maybe feet for State Plane. Make a guess, but don't worry
> because it can be changed easily. In fact you will probably change it
> frequently during the course of your work.

Yes: what it prompts you for at the location set-up stage is the *default*
region & resolution, which is really fairly meaningless as almost all
modules use the *current* region & resolution to perform all their
options. So, while having a think about what it means is useful to help
understand your data and how GRASS works, it is not important now and you
can really just skip this stage and set the region after you import your
data.

>
> Best way to import raster data is with r.in.gdal -oe ... The -oe
> Over-rides the resolution and Extends the extent of the region if
> necessary.

As I understand it the -o flag overrides the projection check (not the region):
this wouldn't be a good idea if the projection was not set up correctly to
start with. Better to use the location= parameter to generate a new
location with the correct projection.

And somebody correct me if I'm wrong about this but the -e flag extends
the default region, which IMHO there's not much point in doing because it
is fairly meaningless as I said above. But in my experience if the -e flag
is not used then r.in.gdal doesn't change the region at all (which is how
it should be because e.g. if you're doing a batch import of multiple files
and want to do some other processing while it's going on you don't want
the background process messing around with the region settings).

HOWEVER, looking at the source code of r.in.gdal it seems this behaviour
was not intended. We have:
/* -------------------------------------------------------------------- */
/*      Set up the window representing the data we have.                */
/* -------------------------------------------------------------------- */
    cellhd.rows = GDALGetRasterYSize(hDS);
    cellhd.cols = GDALGetRasterXSize(hDS);

... and other functions for getting resolution etc. from GDAL and storing
in the cellhd struct ...

and then later on:

/* -------------------------------------------------------------------- */
/*      Set the active window to match the available data.              */
/* -------------------------------------------------------------------- */
    if(G_set_window (&cellhd) < 0)
        exit(3);

i.e. r.in.gdal is attempting to change the current region to match the
resolution of the data (IMHO a bad idea as I said above). So this function
G_set_window() seems not to work and in my experience looking at v.in.ogr
for 5.7 it used some caching mechanism that made it think nothing had
changed and you had to use G__put_window() to force the change. My memory
is not perfect on this but it was something like that. The code is not in
the current v.in.ogr though.

So, summary of suggestion for improvement: The -e flag should be used to either
extend or (preferably) set the *current* region (i.e. the code for this should
first be fixed and then made conditional on the -e flag) and the bit about
extending the default region should be removed. Or has anybody ever found a
good use for extending the default region rather than the current region?

If you don't use the -e flag when running r.in.gdal then you must use
g.region rast=xxx to set the region to match your data (which is I think
how it works currently and how it should be but perhaps not how it was
intended to be).

> So again, don't stress about your initial settings, they will
> not restrict you.

Exactly.

Paul.