[GRASS-user] Re-organizing Project

GRASS GRASS user
1

   Since I'm having all sorts of issues getting usable data in one place so I
can start modeling, I should step back and reorganize what I'm doing. I've
just picked up that mapsets can be used for different issues or themes as
well as different users. This leads to several questions for which I don't
find answers in the Book or Web site; they may be in there but I've missed
them.

   For the current project, all data is in Oregon. All source data files have
the same projection information, but each has different bounds. I'm thinking
that I should put all source data in a single location, called 'Oregon.' The
location's PERMANENT mapset, DEFAULT_WIND and PROJ_INFO will come from the
state boundary outline (an .e00 file). That will be placed in the 'statebnd'
mapset and should have the same WIND as the DEFAULT_WIND in PERMANENT.
County outlines will be placed in the 'cntybnd' mapset which should have the
same WIND, too.

   Then I use v.proj and r.proj to copy each vector map and the raster DEM
map to their own mapsets within the Oregon location. The projection
information should all the same, but each will have different WIND
boundaries.

   If I'm correct on the above, then it should be simpler and correct to
create a project mapset in the same location since it, too, has the same
projection, but bounds the smallest area.

   With the above scheme, do I need to run g.region to set the bounds for
each mapset/map theme? I ask because some of the maps (e.g., stream/rivers,
hydrologic units, soil mapping units) may extend past the state or county
boundaries.

   Re-learning after 5-6 years of not using GRASS at all will get me back to
speed so I can complete this project.

Thanks,

Rich

2

Rich Shepard wrote:

   Since I'm having all sorts of issues getting usable data in one place so I
can start modeling, I should step back and reorganize what I'm doing. I've
just picked up that mapsets can be used for different issues or themes as
well as different users. This leads to several questions for which I don't
find answers in the Book or Web site; they may be in there but I've missed
them.

   For the current project, all data is in Oregon. All source data files have
the same projection information, but each has different bounds. I'm thinking
that I should put all source data in a single location, called 'Oregon.' The
location's PERMANENT mapset, DEFAULT_WIND and PROJ_INFO will come from the
state boundary outline (an .e00 file). That will be placed in the 'statebnd'
mapset and should have the same WIND as the DEFAULT_WIND in PERMANENT.
County outlines will be placed in the 'cntybnd' mapset which should have the
same WIND, too.

There is no real advantage to using multiple locations with the same
projection unless they are used for entirely separate projects where
you will never (or, at least, rarely) need to use data in one location
from within a different location.

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.

   Then I use v.proj and r.proj to copy each vector map and the raster DEM
map to their own mapsets within the Oregon location. The projection
information should all the same, but each will have different WIND
boundaries.

There's no reason to use *.proj when the source and destination
location are the same. You can just copy/rename maps between mapsets,
or you can just leave them where they are and use the map@mapset
syntax and/or the mapset search path (g.mapsets).

Note that PROJ_INFO and PROJ_UNITS contain metadata which describes
the location. These are normally set when a location is created and
never change thereafter.

OTOH, the WIND file may change frequently. This file contains part of
the "state" of a session. It allows commands to operate on a clipped
or resampled subset of the data without every command needing explicit
n=/s=/e=/w=/nsres=/ewres= parameters.

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=...".

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.

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

3

On Wed, 23 Dec 2009, Glynn Clements wrote:

There is no real advantage to using multiple locations with the same
projection unless they are used for entirely separate projects where you
will never (or, at least, rarely) need to use data in one location from
within a different location.

   Thank you, Glynn. That's finally made sense to me.

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.

There's no reason to use *.proj when the source and destination location
are the same. You can just copy/rename maps between mapsets, or you can
just leave them where they are and use the map@mapset syntax and/or the
mapset search path (g.mapsets).

   The source and destination locations are different. I'm trying to collect
the different locations into one by using v.proj and r.proj. That's not
working properly.

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?

   Finally, I can eventually define the region/WIND for the project drainage
basin which is another mapset in the Oregon location.

   Lot's of options and opinions; I'm learning a lot from all of you, and
this far exceeds what I knew way back when. I'm grateful for the education.

Rich

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?

Again, thanks,

Rich

4

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@gclements.plus.com>

5

On Wed, 23 Dec 2009, Glynn Clements wrote:

There is no real advantage to using multiple locations with the same
projection unless they are used for entirely separate projects where you
will never (or, at least, rarely) need to use data in one location from
within a different location.

Glynn,

   With my new understanding I will structure the data by one location per
state, and one mapset per project.

OTOH, the WIND file may change frequently. This file contains part of the
"state" of a session. It allows commands to operate on a clipped or
resampled subset of the data without every command needing explicit
n=/s=/e=/w=/nsres=/ewres= parameters.

   Makes sense.

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=...".

   Let me check my understanding. In Oregon/PERMANENT/DEFAULT_WIND the bounds
for the complete state are used. If I exit GRASS, then start again from a
project mapset (e.g., Oregon/project1), use d.zoom to establish the area
within which I want to work, then run 'g.region save=project1' that region
will apply only to that mapset's WIND. Is this correct?

   If this is correct, what command should I use to eliminate all data
external to that WIND? For example, the stream/river map has > 712,000
elements, but the current project area has probably 100-200. I'd like a copy
of that map with only those elements within the smaller bounds in the
project1 mapset.

Thanks,

Rich

6

Rich wrote:

If this is correct, what command should I use to
eliminate all data external to that WIND?

fwiw "WIND" is mostly a behind the scenes term, "region" is
the user exposed term.

For example, the stream/river map has > 712,000
elements, but the current project area has probably
100-200. I'd like a copy
of that map with only those elements within the smaller
bounds in the project1 mapset.

use v.in.region + v.select (or + v.overlay)

for rasters just change the region then do
r.mapcalc crop_map=orig_map

Hamish

7

On Wed, 23 Dec 2009, Hamish wrote:

fwiw "WIND" is mostly a behind the scenes term, "region" is the user
exposed term.

Hamish,

   So there can be multiple regions in a given location. In essence, then, we
manipulate the regions and those bounds are stored in DEFAULT_WIND and
individual mapset WINDS. Works for me.

use v.in.region + v.select (or + v.overlay)

for rasters just change the region then do r.mapcalc crop_map=orig_map

   Will do.

   I still need to get the raster DEM to behave. I've no idea why it's giving
me problems. Tomorrow I'll get it all sorted out ... I hope!

Thanks,

Rich

8

Rich Shepard wrote:

> fwiw "WIND" is mostly a behind the scenes term, "region" is the user
> exposed term.

Hamish,

   So there can be multiple regions in a given location. In essence, then, we
manipulate the regions and those bounds are stored in DEFAULT_WIND and
individual mapset WINDS. Works for me.

DEFAULT_WIND doesn't normally change, but WIND is often changed as
part of the normal workflow.

WIND isn't a "property" of a particular mapset; it's just a setting
which happens to be stored there.

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

9

Rich Shepard wrote:

> 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=...".

   Let me check my understanding. In Oregon/PERMANENT/DEFAULT_WIND the bounds
for the complete state are used. If I exit GRASS, then start again from a
project mapset (e.g., Oregon/project1), use d.zoom to establish the area
within which I want to work, then run 'g.region save=project1' that region
will apply only to that mapset's WIND. Is this correct?

If you use the save= option with g.region, the settings are saved in
the named region rather than in the current region (WIND). You can
subseqently set the current region from that named region using
"g.region region=...". IOW, save= and region= provide a save/load
mechanism for the current region:

  g.region save=foo # save current region as "foo"
  g.region region=foo # load current region from "foo"

   If this is correct, what command should I use to eliminate all data
external to that WIND? For example, the stream/river map has > 712,000
elements, but the current project area has probably 100-200. I'd like a copy
of that map with only those elements within the smaller bounds in the
project1 mapset.

For vectors, see Hamish's reply.

Rasters are automatically clipped and resampled to the current region
(that's largely why the concept of a current region exists). In
general, there's no need to explicitly make a clipped and resampled
version.

When a module creates new raster maps, those maps will have their
bounds and resolution determined by the current region. And unless the
module specifically overrides it[1], any input maps will automatically
be clipped and resampled to the current region.

The result is that all raster data read and written by the module is
in the form of 2-dimensional arrays with the same dimensions and
geographic alignment. The module doesn't need to do anything special
when dealing with multiple input maps which may have differing bounds,
resolution and/or alignment.

[1] The r.resamp.* modules read their input at the map's "native"
resolution, as does r.proj. Most other modules allow the map to be
clipped and resampled to the current region (in particular, r.resample
just reads a map and writes it straight out without any processing;
the library function which reads the input map does the clipping and
resampling).

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

10

On Thu, 24 Dec 2009, Glynn Clements wrote:

DEFAULT_WIND doesn't normally change, but WIND is often changed as part of
the normal workflow.

WIND isn't a "property" of a particular mapset; it's just a setting which
happens to be stored there.

Glynn,

   This I understand. I was trying to confirm that the WIND and region are
the same thing.

Happy holidays,

Rich