[GRASS-user] Re-organizing Project

[Glynn Clements]

Rich Shepard wrote:

> > How to use mapsets is a judgement call. If the data is shared between
> > multiple users, each user needs their own mapset (you can only select a
> > mapset as the current mapset if you own the mapset directory). Similarly,
> > if you want multiple concurrent sessions, each session really needs a
> > separate mapset so that sessions don't end up stomping on each other's map
> > and WIND files.
> 
>    I'm the only user and can work with a single session.
> 
>    If I correctly interpret your preference it's to have a single location
> (e.g., Oregon in my situation) with mapsets for each theme map. Nothing in
> PERMANENT other than the default window and projection information. That's
> what I'm trying to do. Daniel likes everything in PERMANENT but the specific
> project directory, and that's just a different way of organizing.

I would say that the "default" layout is one location and one mapset
(plus PERMANENT). I wouldn't use more than one mapset unless and until
I had a specific reason to do so (disclaimer: I'm a programmer, not a
geo<anything>; GRASS is something I work on rather than have a
practical use for).

> > If you have several specific regions of interest, you can create named
> > regions with "g.region ... save=...", then subsequently select a named
> > region as the current region with "g.region region=...".
> 
>    Within a specific location? Isn't the region reflected in the mapset's
> WIND file? What I think I want to have is location=Oregon with
> PERMANENT/DEFAULT_WIND == the entire state (using the state boundary map as
> the source), PROJ_INFO and PROJ_UNITS set as the Oregon LCC since that's
> what the state uses.
> 
>    Then within that location I can have a mapset for each theme map, and
> another one for the project itself. The region of each mapset would be set
> as the local WIND ... or would it change the location's region?

The WIND file is mutable. It's quite common to change it during normal
usage. Unlike PROJ_INFO and PROJ_UNITS (and, to a lesser extent,
DEFAULT_WIND), the WIND file isn't a static description of the data
set but an operational parameter. Think of it like the marquee in an
image editor, where any operations operate upon the data inside the
marquee and ignore any data outside it.

It's arguable that each mapset should have its own DEFAULT_WIND file,
but that isn't currently the case (although you could just create a
named region named "default" in each mapset).

> > The DEFAULT_WIND file offers a convenient way to restore the current
> > region to cover the entire dataset, but it isn't any more than that,
> > and nothing actually requires data to fit within the bounds defined in
> > the DEFAULT_WIND file, nor is the current region constrained by it.
> 
>    So for my purposes I should set DEFAULT_WIND to the WIND of the state
> boundary mapset as that's the reference for all subregional work. Correct?

It's typical for DEFAULT_WIND to define the area of interest, and the
default resolution. You might set WIND to a smaller area for specific
commands, but it's less likely that you would set it to a larger area.

Ultimately, it's just a reference setting which can easily be restored
with "g.region -d". It doesn't actually have any significance beyond
that.

-- 
Glynn Clements <glynn at gclements.plus.com>