Hi Micha, No worries, thanks for the headsup re: creating subsets. I noticed that resolution thing also, and just thought that it was because that scene is from a different path/row and the g.region command actually sets the region on the edge of this scene, so there are null values from this scene in the processing region. I have since gotten rid of this scene, but I figure that might explain it?
JDC On Tue, May 12, 2015 at 1:52 PM, Micha Silver <mi...@arava.co.il> wrote: > Hi Jake > Excuse for butting in... > > On 05/12/2015 05:23 PM, Jake Chila wrote: > > Hi Moritz, > > I definitely did mean 'g.region -p', sorry for that. I ended up getting it > to work using 'r.mapcalc' after setting the region. I saw someone online > had used it with the simple expression newmap=oldmap. Then, when I export > the newmap it is only of the subset. This small workaround was easy to set > up, but I don't have any idea why it didn't work in the first place. > > > It's not a "workaround". The correct way to clip a section of a raster is > two steps: define the new region with g.region, then run r.mapcalc (which > honors the region settings) to get a new raster, at the new region > settings, with values equal to the original. > > However, in your r.info output below, something seems wrong with the > resolution. The landsat imagery is at 30 meters resolution. WHere did the > (very small) values below come from? And why is the N-S 6 times smaller > than the E-W ?? > > > > r.info returns: > > (Tue May 12 11:19:01 2015) > > r.info map=L5_2007_ATCOR_COMP@Jacob > > > > +----------------------------------------------------------------------------+ > | Map: L5_2007_ATCOR_COMP@Jacob Date: Mon May 04 14:31:43 > 2015 | > | Mapset: Jacob Login of Creator: Jacob > | > | Location: FordingRiver > | > | DataBase: C:\Users\Jacob\Documents\grassdata > | > | Title: ( L5_2007_ATCOR_COMP ) > | > | Timestamp: none > | > > > |----------------------------------------------------------------------------| > | > | > | Type of Map: raster Number of Categories: 0 > | > | Data Type: CELL > | > | Rows: 11374 > | > | Columns: 12191 > | > | Total Cells: 138660434 > | > | Projection: UTM (zone 11) > | > | N: 557000 S: 554300 Res: 0.23738351 > | > | E: 659000 W: 642200 Res: 1.37806579 > | > | Range of data: min = 0 max = 32767 > | > | > | > | Data Description: > | > | generated by r.composite > | > | > | > | Comments: > | > | r.composite red="GRASS_ATCOR_2007_B3@Jacob" > green="GRASS_ATCOR_2007_\ | > | B2@Jacob" blue="GRASS_ATCOR_2007_B1@Jacob" levels=32 > output="L5_2007\ | > | _ATCOR_COMP" > | > | > | > > > +----------------------------------------------------------------------------+ > (Tue May 12 11:19:02 2015) Command finished (0 sec) > > > However, I have encountered a new problem. On one of my ETM+ images, the > subset is returned as an empty raster. The process runs fine on the other > ETM+ image from one year earlier but for some reason, the subset from the > scene one year later has a min and max data range of 'NULL'. This range > appears to be constant across all the other scenes, so is there a way for > me to quickly edit this scene so it has the correct data? > > > As before, I would double check "g.region -p", and "r.info" for both the > original Landsat image, and the clipped image that comes out NULL. > > > Thanks, > > JDC > > On Tue, May 12, 2015 at 3:33 AM, Moritz Lennert < > mlenn...@club.worldonline.be> wrote: > >> On 08/05/15 19:13, Jake Chila wrote: >> >>> Hey all, >>> >>> I am currently working with some landsat data in Grass 7.0.0 on windows >>> 7, and am trying to hone in on my study area (much smaller than the >>> whole scene). From what I can tell, the best way to do this is through >>> the 'g.region' command however, I am having significant problems getting >>> this module to run correctly. >>> >>> my input is: >>> >>> g.region n=5572425 s=5536865 e=655050 w=626350 res=30 >>> >>> One thing is that it runs in '0 seconds' so I think that is a little odd. >>> >> >> It's normal as the command just changes a few entries in a text file, so >> it is really fast. >> >> >>> When I use the 'g.region -d' command I can see that everything is set >>> properly, >>> >> >> Did you maybe mean g.region -p ? At least this is the command you should >> use to check current region settings. >> >> however when I update the map display nothing changes. Also, >>> when I export the file using 'r.out.gdal' it exports nothing. >>> >>> >>> ('r.out.gdal -t -f --overwrite input=LT5_2007_ATCORRCOMP@May_Project >>> output=C:\Users\Jacob\Desktop\GRASS_Trials\exportattempt5 format=GTiff >>> type=Uint16 nodata=0) >>> >> >> That should normally respect the region settings. >> >> What does >> >> r.info LT5_2007_ATCORRCOMP >> >> give you ? >> >> Moritz >> > > > This mail was received via Mail-SeCure System. > > > _______________________________________________ > grass-user mailing > listgrass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user > This mail was received via Mail-SeCure System. > > > > >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user