[GRASS-user] Re-organizing Project

[Michael Barton]

Rich,

I'm going to try to respond to this message and your subsequent one about organization.

On Dec 22, 2009, at 7:08 PM, grass-user-request at lists.osgeo.org wrote:

> Date: Tue, 22 Dec 2009 17:02:02 -0800 (PST)
> From: Rich Shepard <rshepard at appl-ecosys.com>
> Subject: Re: [GRASS-user] Re-organizing Project
> To: "grass-user at lists.osgeo.org" <grass-user at lists.osgeo.org>
> Message-ID:
>        <alpine.LNX.2.00.0912221644430.14561 at salmo.appl-ecosys.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> On Tue, 22 Dec 2009, Michael Barton wrote:
> 
>> Maybe I can help with suggesting a work flow. To start with, I want to
>> explain a couple features about regions and projecting. Some of this has
>> been explained before, but maybe this can put it all in one place.
> 
> Michael,
> 
>   Thank you. I actually understand most of this (other than multiple maps
> for setting the largest region), but did not clearly express myself. The key
> question for me is why it's not working as it should.
> 
>> There are various ways to set regions, but the most direct and reliable is
>> to use g.region.
> 
>   Without getting into my issues of reorganizing everything so it's in a
> single location, with each map and/or issue a separate mapset, the largest
> region should be the entire state. And, the state boundary map and counties
> map _should_ have the same region even though the west boundary of the state
> is doubled (from the .e00 import). I guess that's the effects of erosion by
> the Pacific Ocean on the coast. It's not worth my time to clean that now.
> 
>   All the vector maps can happily reproject into the collective location.
> It's the raster DEM that's being recalcitrant.

Following up on Glynn's comment. If all your maps are in the same projection and you want to work with them together, they should be in the same location. IIUC, this is what you want to do.

Do not use v.proj or r.proj to combine maps with the same projection.

However, you cannot use g.copy to move maps from one location to the other. So I'm going to suggest a workflow for doing this--IF ALL the maps are in the SAME projection.

1. Create a mapset with some meaningful name in each location that is distinct from the mapsets in the other locations. For example: 
   location=Location_area1 mapset=maps_area1, location=Location_area2 mapset=maps_area2, etc.
2. Open GRASS in each location and the mapsets you've created. For example, start in Location_area1, maps_area1
3. Using g.copy, copy all the maps from the location (raster and vector) into the mapsets you've created in each location. For example: g.copy rast=rastmap1 at PERMANENT,rastmap1.
   Now all the maps in Location_area1 will be copied into the mapset maps_area1
4. Do the same thing for all locations with the same projection.
5. Pick a location that will hold ALL your maps.
6. From your OS (i.e., NOT from GRASS), move all the new mapsets (e.g., maps_area1, maps_area2, etc) from their old locations into the base location. 
7. Open GRASS in your new base location and make sure that all your mapsets are accessible (g.mapsets). 

Now you can work with all of them together. Just change the region as needed to see them.

> 
>> If RMapSrc is a raster map in the source location, r.proj will read the
>> the cells of RMapSrc **that lie within the extents of the current region
>> of the target location** and create a new map, RMapTgt, **at the
>> resolution of the current region** whose cell values are calculated from a
>> transformation function that maps information from a map in one projection
>> into another.
> 
>   Which suggests that I should have had no problems. The DEM coverage is for
> the northwestern portion of the state; approximately from the top of the
> Cascade Mountains on the east to the Pacific Ocean on the west, the Columbia
> River on the north, and someplace about the southern end of the Willamette
> Valley on that end. This source region is a sub-set of the target region
> (the entire state), and any cells in the water can happily be ignored and
> clipped off because I'm not doing bathymetry on this project.
> 
>   The region of the raster source map is a subset of the target region.
> That's why I don't understand why GRASS kept throwing errors at me.
> 
>> Workflow:
>> -Start in the source location.
>> 1. Set the region to match the map you want to reproject in the source location: g.region rast=RMapSrc.
> 
>   That's the way I set the source region after importing the raster file.
> 
>> 2. Create VregionSrc as a rectangular vector area to match the extents of
>> the region: v.in.region output=VregionSrc
> 
>   I did this, too. It provides a box that is a subset of the target region.
> 
>> -Change to target location (quit GRASS and restart in target).
>> 1. Reproject VregionSrc: v.proj input=VregionSrc location=SourceLocation
>> mapset=SouceMapset output=VregionSrc
> 
>   I _think_ this step worked for me. I'll have to do it over again to be
> sure.
> 
>> 2. Set the current region in the target location to match the reprojected
>> VregionSrc in the target region and set the resolution as desired:
>> g.region vect=VregionSrc res=resolution.
> 
>   I may not have done this.

This is critical and may be why you can't see the reprojected maps. You have not extended your target region to encompass the maps you want to read and reproject.

> 
>> 3. Reproject RMapSrc, creating a new map in the target location at the
>> desired resolution, with cells that match up with the cells of RMapSrc:
>> r.proj input=RMapSrc location=SourceLocation mapset=SouceMapset
>> output=NewReprojectedMap.
> 
>   It's all quite different from when I worked with versions 4.1 through 4.3.
> Heck, even the modules and steps in the 2nd edition of the GRASS book are
> frequently no longer valid.

A surprising amount of the commands are the same from GRASS 4.1-4.3. But yes, the software has evolved considerably in the past 15 years. Also note that you can do all this from the GUI, and extensive help is available online with every module.

Michael

> 
> Thanks very much,
> 
> Rich