Re: [GRASS-user] Installing grass add-ons (imagery and gipe) with GEM
Hi, Using Grass extension Manager to install imagery add ons I get the following the advice from: http://www.nabble.com/installing-add-ons-td15922472.html I get the following message: GRASS 6.3.0 (test_landsat):~/grass-addons/imagery/i.landsat.toar > gem6 --install=/home/maning/grass-addons/imagery/ i.landsat.acca/main.c Uncompressing files...mkdir: cannot create directory `/tmp/grass.extension.RyasEQ': Permission denied cp: cannot create regular file `/tmp/grass.extension.RyasEQ': Permission denied WARNING: file name not '.tar.gz', '.tgz', '.tar.bz2', '.tbz' or '.zip'. Assuming '.tgz'. tar (child): /tmp/grass.extension.RyasEQ/main.c: Cannot open: Permission denied tar (child): Error is not recoverable: exiting now gzip: stdin: unexpected end of file tar: Child returned status 2 tar: Error exit delayed from previous errors DONE. Segmentation fault (core dumped) GRASS 6.3.0 (test_landsat):~/grass-addons/imagery/i.landsat.toar > I'm using GRASS 6.3 under Cygwin. maning On Mon, Jun 2, 2008 at 3:08 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 5:33 AM, maning sambale > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I can't find the instructions on installing grass add-ons particularly >> imagery add-ons >> https://svn.osgeo.org/grass/grass-addons/imagery/ >> and >> >> except i.landsat.dehaze which is simply a script >> >> I'm using grass 6.3 on cygwin. > > Please take a look at > https://svn.osgeo.org/grass/grass-addons/README > -> Installation - Code Compilation > > If this is unclear, please help us to improve the wording. > > Markus > -- |-|--| | __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda | | '-._"7' |"Freedom is still the most radical idea of all" -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com| | _)_/LI |-|--| ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat color correction fails with "Segmentation fault" in GRASS 6.3
Hamish, Here are the outputs: 1. GRASS 6.3.0 (Romania):~ > r.univar -ge [EMAIL PROTECTED] perc=98 n=68587026 null_cells=3781910 min=58 max=255 range=197 mean=181.261 mean_of_abs=181.261 stddev=36.808 variance=1354.83 coeff_var=20.3067 sum=12432135110 Segmentation fault 2. GRASS 6.3.0 (Romania):~ > g.region -p projection: 99 (sterea) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: a=6378245 es=0.006693421622965943 north: 773383.051 south: 194663.051 west: 103791.364 east: 904111.364 nsres: 80 ewres: 80 rows: 7234 cols: 10004 cells: 72368936 3. After setting DEBUG=1 GRASS 6.3.0 (Romania):~ > i.landsat.rgb [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Processing <[EMAIL PROTECTED]> ... Segmentation fault D1/1: <[EMAIL PROTECTED]>: min=108 max= ERROR: bad rule (syntax error): white Processing <[EMAIL PROTECTED]> ... Segmentation fault D1/1: <[EMAIL PROTECTED]>: min=129 max= ERROR: bad rule (syntax error): white Processing <[EMAIL PROTECTED]> ... Segmentation fault D1/1: <[EMAIL PROTECTED]>: min=137 max= ERROR: bad rule (syntax error): white I am not sure why it says "datum: unknown," it's the "Dealul Piscului 1970" datum (using the EPSG 31700). I don't think it's related to the error though. Thanks for looking into it. Marius Hamish wrote: Marius Jigmond wrote: Have you run into this kind of errors: Nope. GRASS 6.3.0 (Romania):~> i.landsat.rgb [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Processing ... Segmentation fault ERROR: bad rule (syntax error): white Processing ... Segmentation fault ERROR: bad rule (syntax error): white Processing ... Segmentation fault ERROR: bad rule (syntax error): white It's a three band Landsat mosaic. I am running Ubuntu 8.04 with GRASS 6.3 from Jachym Cepicky's repo (http://les-ejk.cz/ubuntu/). I am not really sure where to start poking. It would seem that r.univar is failing in this part of the i.landsat.rgb script: for i in $RED $GREEN $BLUE ; do g.message "Processing <$i> ..." MIN=`r.univar -ge $i perc=2 | grep "^percentile_" | cut -d'=' -f2` MAX=`r.univar -ge $i perc=$BRIGHTNESS | grep "^percentile_" | cut -d'=' -f2` g.message -d message="<$i>: min=$MIN max=$MAX" r.colors $i col=rules << EOF 0% black $MIN black $MAX white 100% white EOF done so $MAX would be unset, and r.colors gets a color without a value, which is a bad rule. ??? can you try "r.univar -ge [EMAIL PROTECTED] perc=98" on the command line and see what happens? also, what does "g.region -p" look like? and finally can you rerun i.landsat.rgb with debug messages turned on? g.gisenv set="DEBUG=1" # to turn them back off set to 0 then the g.message info will be displayed. but why does r.colors not complain about "$MIN black" too? Hamish _ Make every e-mail and IM count. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: grass-user Digest, Vol 25, Issue 67
On Mon, Jun 2, 2008 at 11:42 AM, Otto Dassau <[EMAIL PROTECTED]> wrote: > Hi, > > good idea - we could update ./rpm/suse from time to time. I don't have svn > access for grass but I can send you the spec files, if you like. Who would be > the contact person, I can send the files to? Would that be ok? > > Attached you find the current spec file and the patch which comments the > wxpythion v.digit module for the grass 6.3. The same files are available in > the /src folder via the Application:/Geo/ repository. It works for OpenSuSE > 10.2, 10.3 and openSUSE_Factory. ... submitted to 6.4.svn Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interpolating intensity points & r.in.xy
Thanks for the great ideas. Those sound promising. I'll give them a whirl and report the results! Mark On Mon, Jun 2, 2008 at 4:56 AM, Hamish <[EMAIL PROTECTED]> wrote: > Mark wrote: > > I suspect the intensity data may be better for house extraction, > > because the roofs are mostly all uniform in intensity clusters > > values, where with RGB the roof shingles are far to varied for it > > to classify them cleanly without other classes of non-roofs appearing > > all over the map in scattered clusters. > > Hi, > > an idea about extracting roofs from LIDAR data- create a slope map from > r.in.xyz DEM and run i.cluster etc. on that to extract areas of constant > slope. Then threshold that to remove small area noise* (say under 25 sq-m) > and large areas (roads, etc). > > [*] in vectors this would be 'v.clean tool=rmarea', not quite sure about > cluster data, maybe r.grow/r.buffer the null cells then back the other > direction and use that as a mask?? > > Not sure how to separate "big box" Walmarts from parking lots, maybe if you > set high slopes to NULL you can turn flat areas into islands, then test each > island (r.to.vect areas?) for height departure from the surrounding DEM?? > perhaps something with r.neighbors? > > > Hamish > > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: grass-user Digest, Vol 25, Issue 67
Hi, good idea - we could update ./rpm/suse from time to time. I don't have svn access for grass but I can send you the spec files, if you like. Who would be the contact person, I can send the files to? Would that be ok? Attached you find the current spec file and the patch which comments the wxpythion v.digit module for the grass 6.3. The same files are available in the /src folder via the Application:/Geo/ repository. It works for OpenSuSE 10.2, 10.3 and openSUSE_Factory. regards, Otto On Fri, 30 May 2008 23:01:26 -0700 (PDT) Hamish <[EMAIL PROTECTED]> wrote: > Hamish: > > > I do not know if the SuSE packages are build using the > > spec from the GRASS source code, but you could check the > > rpm/ source code dir and submit any fixes you have. > > > > > > http://trac.osgeo.org/grass/browser/grass/trunk/rpm > > Richard Chirgwin wrote: > > I think you may be flattering my expertise if you think > > I'm competent for source code fixes! :-) > > I don't think it's quite as hard as you might think- just to look at the text file and see what's there. Anyway I encourage all to explore it even if you are not comfortable with making too many changes. > > The package dependency part of the spec file seems fairly clear. e.g.: > http://trac.osgeo.org/grass/browser/grass/trunk/rpm/suse/grass-6.1.cvs-1suse.spec > > Requires: gdal >= 1.3 > Requires: tcl >= 8.3 > Requires: tk >= 8.3 > Requires: proj >= 4.4.9 > > > adding another is just opening it up in a text editor and typing the line. > > But it is probably better to sync that with Otto's 6.3.0 version before doing any more, as the GRASS svn copy is way out of date. > > > I should however say, wrt YaST on OpenSuSE, that it's > > very ignorant of Grass and only returns a very ancient version > > (5.0.3-120). > > Hmm, maybe someone could work on getting Otto's OpenSuSE packages into that. > http://download.opensuse.org/repositories/Application:/Geo/ > > (no idea) > > > Hamish > > > > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user --- grass-6.3.0/gui/wxpython/Makefile 2008-04-16 15:31:47.0 +0200 +++ grass-6.3.0_new/gui/wxpython/Makefile 2008-04-19 14:06:28.0 +0200 @@ -4,11 +4,11 @@ include $(MODULE_TOPDIR)/include/Make/Platform.make -ifneq ($(USE_WXWIDGETS),) - ifneq ($(USE_PYTHON),) -SUBDIRS += vdigit - endif -endif +#ifneq ($(USE_WXWIDGETS),) +# ifneq ($(USE_PYTHON),) +#SUBDIRS += vdigit +# endif +#endif include $(MODULE_TOPDIR)/include/Make/Dir.make grass.spec Description: Binary data ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interpolating intensity points & r.in.xyz
Mark wrote: > I suspect the intensity data may be better for house extraction, > because the roofs are mostly all uniform in intensity clusters > values, where with RGB the roof shingles are far to varied for it > to classify them cleanly without other classes of non-roofs appearing > all over the map in scattered clusters. Hi, an idea about extracting roofs from LIDAR data- create a slope map from r.in.xyz DEM and run i.cluster etc. on that to extract areas of constant slope. Then threshold that to remove small area noise* (say under 25 sq-m) and large areas (roads, etc). [*] in vectors this would be 'v.clean tool=rmarea', not quite sure about cluster data, maybe r.grow/r.buffer the null cells then back the other direction and use that as a mask?? Not sure how to separate "big box" Walmarts from parking lots, maybe if you set high slopes to NULL you can turn flat areas into islands, then test each island (r.to.vect areas?) for height departure from the surrounding DEM?? perhaps something with r.neighbors? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Pre-processing LANDSAT TM Orthorectified images from GLCF
Markus, > AFAIK LANDSAT is sun-synchronous, it passes in the local morning time > (something like 10:30-11:00). > > Maybe this helps: > http://earthobservatory.nasa.gov/MissionControl/overpass.html Since it is an overpass predictor, it doesn't provide information on previous landsat overpass. Can I use this as a proxy to the hh:mm for i.atcorr (me thinks no)? Or set an arbitrary time say between 10:30 to 11:00? > i.atcorr is the sophisticated correction, i.landsat.dehaze only a simple > approach based on image statistics. > >> 3. correction for topographic/terrain effects (most of my study area >> are in maountainous regions) >> use book 2nd ed. (page 226) "cosine correction" >> using r.sunmask, r.mapcalc >> Problem: again, no image acquisition time > > (see above). "cosine correction" is a simple approach. See also > i.topo.corr (from GRASS AddOns). Thank you for this one. >> 4. removal of clouds >> use i.landsat.acca >> https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca/ > > Never tried, please report back. Will do, via wiki. > I have collected all this now in > http://grass.osgeo.org/wiki/Image_processing#Preprocessing > > Feel free to further improve that Wiki page. > Markus As usual, thank you very much. cheers, maning -- |-|--| | __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda | | '-._"7' |"Freedom is still the most radical idea of all" -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com| | _)_/LI |-|--| ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Pre-processing LANDSAT TM Orthorectified images from GLCF
On Mon, Jun 2, 2008 at 7:50 AM, maning sambale <[EMAIL PROTECTED]> wrote: > Hi, > > For a project I am involved with, we are conducting landcover > classification from LANDSAT TM (orthorectified) data downloaded from GLCF. > We are now in the process on pre-processing the image and then conduct > classification using i.smap. > > Following the GRASS book, we will be conducting the pre-processing > steps outlined: > > 1. calibration from DN to apparent radiance at sensor - gain/bias offsets > > following grass book 2nd ed. (page 222) > r.mapcalc "band.rad = ((LMAX - (LMIN))/(255.0 - 1.0)) * (band -1.0) + (LMIN)" > > or > > i.landsat.toar i.landsat.toar is the more sophisticated approach (or, easier since you don't need to write the formula manuallly). > 2. correction for atmospheric effects > > use i.atcorr > problem: the metadata supplied by GLCF does not indicate image acquisition > time > sample metadata: http://tinyurl.com/6oo428 > > or use > i.landsat.dehaze AFAIK LANDSAT is sun-synchronous, it passes in the local morning time (something like 10:30-11:00). Maybe this helps: http://earthobservatory.nasa.gov/MissionControl/overpass.html i.atcorr is the sophisticated correction, i.landsat.dehaze only a simple approach based on image statistics. > 3. correction for topographic/terrain effects (most of my study area > are in maountainous regions) > use book 2nd ed. (page 226) "cosine correction" > using r.sunmask, r.mapcalc > Problem: again, no image acquisition time (see above). "cosine correction" is a simple approach. See also i.topo.corr (from GRASS AddOns). > 4. removal of clouds > use i.landsat.acca > https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca/ Never tried, please report back. > The beauty with GRASS and the GRASS book is that it has the > tools/modules I need for this project, however, I find it difficult to > choose which one I should use (i.atcoor or i.landsat.dahaze?). Am I > following the steps in correct order? Or is it necessary to do all > this? Reading from GLCF documentation, they did orthrectification for > this image already. > > Any pointers would be very helpful. I have collected all this now in http://grass.osgeo.org/wiki/Image_processing#Preprocessing Feel free to further improve that Wiki page. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Installing grass add-ons (imagery and gipe)
On Mon, Jun 2, 2008 at 5:33 AM, maning sambale <[EMAIL PROTECTED]> wrote: > Hi, > > I can't find the instructions on installing grass add-ons particularly > imagery add-ons > https://svn.osgeo.org/grass/grass-addons/imagery/ > and > > except i.landsat.dehaze which is simply a script > > I'm using grass 6.3 on cygwin. Please take a look at https://svn.osgeo.org/grass/grass-addons/README -> Installation - Code Compilation If this is unclear, please help us to improve the wording. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
