[GRASS-user] Re-organizing Project

[Glynn Clements]

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