[GRASS-user] Mac 6.4.1-3 Update Problems

2011-05-31 Thread Dave Kent
I updated today to Mr. Kyngesburye's most recent binaries.  

I updated the revised frameworks (GDAL complete 1.8, FreeType and Cairo) and 
then the application 6.4.1-3 (SnowLeopard) as per website.

I get the following error when launching wxpython.  On start up Grass asks for 
mapset then provides following:


GRASS 6.4.1 > Traceback (most recent call last):
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line 
1611, in 
sys.exit(main())
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line 
1604, in main
app = GMApp(workspaceFile)
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line 
1514, in __init__
wx.App.__init__(self, False)
  File 
"/Users/Shared/unix/wxpython-snow/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py",
 line 7981, in __init__
  File 
"/Users/Shared/unix/wxpython-snow/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py",
 line 7555, in _BootstrapApp
  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line 
1528, in OnInit
introBmp   = introImage.ConvertToBitmap()
  File 
"/Users/Shared/unix/wxpython-snow/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py",
 line 3369, in ConvertToBitmap
wx._core.PyAssertionError: C++ assertion "image.Ok()" failed at 
../src/mac/carbon/bitmap.cpp(1286) in wxBitmap(): invalid image

I am using most recent snow Leopard and the snow Leopard binaries.

tcltk works.  



Have I missed something?

Thanks
Dave






___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Hardware config/limits

2011-05-31 Thread Glynn Clements

nunosousa84 wrote:

> I've noticed that i have serious problems dealing with large raster maps and
> some GRASS commands in Grass plugin, like r.surf.contour, shaded relief,
> some raster calcs, etc... Im using 1 by 1 resolution, maybe it is a bit
> exagerated, but even at 5 by 5 the calculation process is very slow. Im
> using a Intel Core 2 Duo E8400 and 4Gb 8500mhz DDR2 Memory. Im about to do
> an upgrade, should i opt for 8Gb memory, or i better opt for a good CPU
> (maybe quad core)? Whats your experience dictates to improve performance?

Multiple cores won't help; GRASS modules are single-threaded.

> The strange thing is that Ubuntu System Monitor says only one core is at
> 100% full capacity but the other is only 20%.

That's to be expected.

> Ans memory usage is only 700Mb, so whats causing all this lag and
> slow calc, the bar almost dont moves?

> I just run the r.surf.contour command and it takes infinite
> time

r.surf.contour is the problem. The documentation says:

The running of r.surf.contour is very sensitive to the
resolution of rasterized vector map. If multiple contour lines
go through the same raster, slight anomalies may occur. The
speed of r.surf.contour is dependent on how far "apart" the
contour lines are from each other (as measured in raster
cells). Since a flood fill algorithm is used, the program's
running time will grow exponentially with the distance between
contour lines.

Maybe there's a faster approach along the lines of r.grow.distance?

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Using r.resamp.stats

2011-05-31 Thread Glynn Clements

Jenny Turner wrote:

> I have one question regarding null values: I'm using r.resamp.stats with
> method average. My question is, if I have a Target pixel based on 10 null
> values and 1 non-null value, the target pixel will be based only on valid
> pixel? I mean, it only requires at least 1 value to produce an output value?

Without -n, the aggregate is computed over the non-null values; if all
values are null, the result will be null.

With -n, if any value is null, the result will be null.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: r.param.scale curvatures formulas

2011-05-31 Thread Alexander Muriy
2011/5/31, grass-user-requ...@lists.osgeo.org
:
>
> Sorry to resurrect a reasonably old topic (following my mail), but I
> have two questions on the r.param.scale module:
>
> 1 - I share Jasiewicz's concerns, the formula do not match the
> litterature I got [0]

Formulas for this module were investigated by Jo Wood in his work
http://www.soi.city.ac.uk/~jwo/phd/
So there can be some special cases..

> I know other modules, such as v.surf.rst, offer to compute the
> tangential curvature, but I'd be glad to generate the different
> curvatures I need using only one command.

Also as an idea: it's possible to write custom script (shell, python),
which would be compute different types of curvatures by calling
different modules (r.param.scale, r.slope.aspect,v.surf.rst)
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: Hardware config/limits

2011-05-31 Thread nunosousa84
im not very sure. I just run the r.surf.contour command and it takes infinite
time, in fact it doesent go past 0% processing. If i change the resolution
to 5by5 it responds better and 10by10 it is indeed faster (takes around 5
minutes to complete). Whats interesting is when i use the 10by10 resolution
the 2 CPU cores are used 100%. It seems when using 1by1 res the CPU is not
able to address correctly the calc parameters (it enters a kind of stall).
Maybe im beeing to picky about the res. This is what i get with 10by10 res:

http://osgeo-org.1803224.n2.nabble.com/file/n6424348/shaded.jpg 
Shaded relief map

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Hardware-config-limits-tp6423485p6424348.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] IDF Curves

2011-05-31 Thread Rich Shepard

  I have 3 years' daily rainfall data for a specific station and would like
to create a plot of Intensity-Duration-Frequency (IDF) curves. Can this be
done within GRASS?

TIA,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: Hardware config/limits

2011-05-31 Thread Markus Neteler
On Tue, May 31, 2011 at 8:55 PM, nunosousa84
 wrote:
> Well its not that extreme at all, hehehe. In fact its just a small
> portion/region of my country (Portugal). I would say its about 20 square
> kilometers (topo chart scale 1:25000). The command give this info:
>
> projection: 99 (Transverse Mercator)
> zone:       0
> datum:      ** unknown (default: WGS84) **
> ellipsoid:  international
> north:      440001.79599872
> south:      425994.35467597
> west:       223993.6587145
> east:       241010.36970949
> nsres:      1.3151
> ewres:      0.8302

Hint: if you use the -a flag along with the res parameter ff g.region, you can
get the precise 1.0m resolution which is likely better:

g.region res=1.0 -ap

> rows:       14007
> cols:       17017
> cells:      238357119

In fact, not too much.

On Tue, May 31, 2011 at 6:25 PM, nunosousa84
 wrote:
> Hi,
>
> I've noticed that i have serious problems dealing with large raster maps and
> some GRASS commands in Grass plugin, like r.surf.contour, shaded relief,
> some raster calcs, etc...

What problems do you exactly have?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: Hardware config/limits

2011-05-31 Thread nunosousa84
Well its not that extreme at all, hehehe. In fact its just a small
portion/region of my country (Portugal). I would say its about 20 square
kilometers (topo chart scale 1:25000). The command give this info:

projection: 99 (Transverse Mercator)
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  international
north:  440001.79599872
south:  425994.35467597
west:   223993.6587145
east:   241010.36970949
nsres:  1.3151
ewres:  0.8302
rows:   14007
cols:   17017
cells:  238357119



--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Hardware-config-limits-tp6423485p6424098.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Hardware config/limits

2011-05-31 Thread Markus Neteler
On Tue, May 31, 2011 at 6:25 PM, nunosousa84
 wrote:
> Hi,
>
> I've noticed that i have serious problems dealing with large raster maps and
> some GRASS commands in Grass plugin, like r.surf.contour, shaded relief,
> some raster calcs, etc... Im using 1 by 1 resolution, maybe it is a bit
> exagerated,

Please post how many rows and columns you have:

g.region -p

If you try, say, Eurasia at 1m resolution this will be demanding :)
So, without this information we cannot suggest much.

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Using r.resamp.stats

2011-05-31 Thread Jenny Turner
I have one question regarding null values: I'm using r.resamp.stats with
method average. My question is, if I have a Target pixel based on 10 null
values and 1 non-null value, the target pixel will be based only on valid
pixel? I mean, it only requires at least 1 value to produce an output value?

Thanks
Jenny
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] gradient (slope) of a road

2011-05-31 Thread Dylan Beaudette
On Tue, May 31, 2011 at 8:54 AM, Markus Neteler  wrote:
> On Tue, May 31, 2011 at 9:22 AM, Francisco Calzada
>  wrote:
>> Dear list,
>> I'm new to this list and I wonder if you could help me.
>
> Welcome!
>
>> I need to calculate the gradient (slope) of a road. I have a fine DEM to do
>> it. The problem is when I run r.slope.aspect the resulting slope map have
>> extremelly and odd high values. I don't know why. Do you? Anyway, could you
>> tell me how do you calculate the slope of a road?
>
> First use v.drape to drape the 2D road map over the DEM:
> http://grass.osgeo.org/grass64/manuals/html64_user/v.drape.html
>
> Then use the resulting 3D vector map to calculate the slope for
> the vector segments using the "slope" method, results go into
> the attribute table:
> http://grass.osgeo.org/grass64/manuals/html64_user/v.to.db.html
>
> Hope this helps
> Markus

Markus' suggestion is the simplest. If you need more than slope,
consider densifying your line segments and sampling the raster of
interest along the new, shorter, segments. Here is the outline:

http://casoilresource.lawr.ucdavis.edu/drupal/node/698

Cheers,
Dylan
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] grass + OpenMP

2011-05-31 Thread Olavo Borges D'Antonio

Hello,

I was looking for informations about grass and distributed computing and 
found a pdf on the subject. However I have a question:


The Grass 6 has some modules that can be compiled with the OpenMP 
option, the other modules would have to be rebuild so they can run with 
this option?


thanks,
Olavo D'Antonio

--
http://www.monsterhuntercommunity.com/license/nynxs


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Hardware config/limits

2011-05-31 Thread nunosousa84
Hi,

I've noticed that i have serious problems dealing with large raster maps and
some GRASS commands in Grass plugin, like r.surf.contour, shaded relief,
some raster calcs, etc... Im using 1 by 1 resolution, maybe it is a bit
exagerated, but even at 5 by 5 the calculation process is very slow. Im
using a Intel Core 2 Duo E8400 and 4Gb 8500mhz DDR2 Memory. Im about to do
an upgrade, should i opt for 8Gb memory, or i better opt for a good CPU
(maybe quad core)? Whats your experience dictates to improve performance?
The strange thing is that Ubuntu System Monitor says only one core is at
100% full capacity but the other is only 20%. Ans memory usage is only
700Mb, so whats causing all this lag and slow calc, the bar almost dont
moves? Im using Ubuntu 10.04 32bits.

Thank you
Nuno

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Hardware-config-limits-tp6423485p6423485.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] 1st Greek GRASS meeting

2011-05-31 Thread Nikos Alexandris
Dear grassers,

the 1st Greek GRASS-GIS meeting will become reality in June (17 to 19). 
Anybody within or near Greece that would like to join?

I would be more than happy to host and help anyone willing to visit Greece for 
the days of the meeting but my current situation prohibits this as well as 
being on-line and following the lists and all the rest of the grassy-stuff 
going on.

Tip: the landscapes in which the meeting will be held (in Pilio) are amazing!

Please pass the message to friends and colleauges that might be interested.
All the best, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] gradient (slope) of a road

2011-05-31 Thread Markus Neteler
On Tue, May 31, 2011 at 9:22 AM, Francisco Calzada
 wrote:
> Dear list,
> I'm new to this list and I wonder if you could help me.

Welcome!

> I need to calculate the gradient (slope) of a road. I have a fine DEM to do
> it. The problem is when I run r.slope.aspect the resulting slope map have
> extremelly and odd high values. I don't know why. Do you? Anyway, could you
> tell me how do you calculate the slope of a road?

First use v.drape to drape the 2D road map over the DEM:
http://grass.osgeo.org/grass64/manuals/html64_user/v.drape.html

Then use the resulting 3D vector map to calculate the slope for
the vector segments using the "slope" method, results go into
the attribute table:
http://grass.osgeo.org/grass64/manuals/html64_user/v.to.db.html

Hope this helps
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Limits on computation

2011-05-31 Thread Glynn Clements

Monica Buescu wrote:

> Just one question aboht that limit of number of cells: is that limit
> applicable to CELL or DCELL?

Both.

The few modules which read an entire map into memory will also be
limited by available memory and address space, which will affect DCELL
more than CELL or FCELL. However:

1. Memory consumption is determined by whether the module reads the
data as CELL/FCELL/DCELL, not how it's stored on disk.

2. Such modules tend to be algorithmically complex, so execution time
becomes an issue long before memory availability does.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: i.atcorr returns all NULL values

2011-05-31 Thread Daniel Victoria
I'll have to check but I believe I used constant visibility for the 6S
correction but, I did use an elevation map from SRTM. Of course the
area is rather flat (a wetland).

Daniel

On Tue, May 31, 2011 at 11:35 AM, Markus Metz
 wrote:
> On Sun, May 29, 2011 at 8:16 PM, Daniel Victoria
>  wrote:
>> I'm also struggling with i.atcorr for Landsat. A friend of my
>> corrected some TM images using the Flash module in ENVI (based on
>> modtran) and I tried to correct the same images using 6S in grass
>> (i.atcorr). We both used the same radiance images that had some
>> problems with a few negative values in water areas. I set the negative
>> values to 0.
>>
>> After correcting the TM images in Grass I created 6000 random point in
>> order to compare the images (flash vs. 6s). The attached graph shows
>> the density plot (~histogram) for each band (band 6 is actually TM
>> band7). For all images, value have been scaled from 0 to 1. Black line
>> is radiance, red is 6S and blue is flash. What we see is that for
>> bands 4, 5 and 7 there are no big differences but, for bands 1, 2 and
>> 3, the correction done by flash is more pronounced.
>>
>> Now, what I don't know:
>> 1) Is this type of analysis (looking at the image histogram) OK?
>> 2) Should atmospheric correction change the histogram?
>> 3) For i.atcorr I get a sort of "linear" relation between radiance &
>> reflectance. That is, for each radiance there is only one value for
>> reflectance. But the flash correction gives a point cloud when I
>> compare radiance & reflectance (more than one reflectance value for
>> the same radiance). What is the expected behavior?
>
> If you use global values for elevation and visibility, you will only
> one output value for each input value. If you use an elevation and/or
> visibility map as additional input (granted that the values in these
> maps are not constants), you may get point clouds, i.e. several
> different output values for the same input value if this input value
> occurs more than once and either elevation or visibility differ
> between the occurences.
>
> Markus M
>
>>
>> I'm using Grass 7 svn from about 2 weeks ago. The images are from the
>> Pantanal wetland in Brazil in the dry period (still lots of water
>> there). For 6S the settings are: Tropical atmosphere, continental
>> aerosol mode, 20km visibility.
>>
>> Thanks and cheers
>> Daniel
>>
>>
>> On Fri, May 27, 2011 at 7:34 PM, Juan Benavides Duque  
>> wrote:
>>> I'm sending the code I used to run the i.atcorr module (including the
>>> i.landsat.toar transformation)
>>>
>>> (I also used the code sent by Yann Chemin (May 23) with the same results)
>>>
>>> Of two files attached one has the code and other one the  univariate stats
>>> output of the band 1 TOAR raster  for one of the 1986 scenes
>>>
>>> A copy of the original landsat used have been  placed temporarily at the
>>> following location " assets "
>>>
>>> hope somebody can help
>>>
>>>
>>> thanks
>>>
>>> juan
>>>
>>>
>>> I'm using a desktop running Ubuntu 10.10 with a 64bit  Intel(R) Core(TM) i7
>>> CPU 860  @ 2.80GHz
>>>
>>>
>>>
>>>
>>> 2011/5/27 Gaspar Reyes Póndigo 

 I had same problem, i.atcorr not work with landsat 5TM band 1, 2 and
 sometimes with band 3
 I tried i.atcorr in different versions of grass, this is my results:

 1. GRASS-6.4.1-2 under Mac Snow-Leopard 10.6.7: Not work band 1, 2, and
 sometimes with band 3 (for years 1992, 1993, 1995 and 1997).
 2. GRASS-6.5. revision 46428 compiled in Mac Snow-Leopard 10.6.7: Not work
 band 1, 2, and sometimes with band 3 (for years 1992, 1993, 1995 and 1997)
 3. GRASS-6.5svn45719(2011) under Microsoft Windows Xp sp3: All the bands
 work,THIS IS VERY RARE

 My images landsat 5 TM are from Tonameca, Oaxaca, México of years 1985 to
 1999, and 2010 to 2011 (one image series for year), i am work with AOD and
 visibility value,  and convert manually DN to radiance (a).

 (a) Lλ = [(LMAXλ − LMINλ) / (Qcalmax − Qcalmin)] (Qcal − Qcalmin) + LMINλ

 Gaspar Reyes Póndigo
 Universidad del Mar, Oaxaca, México
 Campus Puerto-Ángel
 Carretera principal Puerto Ángel Zipolite km 1.5
 C.P. 70902

 ---

 Message: 1

 Date: Fri, 27 May 2011 08:53:32 +0530

 From: "Chemin, Yann (IWMI)" 

 Subject: RE: [GRASS-user] Re: i.atcorr returns all NULL values

 To: "Juan Benavides Duque" ,

 

 Cc: Markus Metz , Elena Mezzini

 

 Message-ID:

 <001f233294ea894387cfdaadab87de2508506...@iwmix.iwmi.cgiarad.org>

 Content-Type: text/plain; charset="us-ascii"

 Hi Juan,



 Can you please give the download link for your images,

 Could you also check the output of i.landsat.toar for them and tell if

 reflectance ranges are valid/logic.



 Thank you,

 Yann

>>>

Re: [GRASS-user] Re: i.atcorr returns all NULL values

2011-05-31 Thread Markus Metz
On Sun, May 29, 2011 at 8:16 PM, Daniel Victoria
 wrote:
> I'm also struggling with i.atcorr for Landsat. A friend of my
> corrected some TM images using the Flash module in ENVI (based on
> modtran) and I tried to correct the same images using 6S in grass
> (i.atcorr). We both used the same radiance images that had some
> problems with a few negative values in water areas. I set the negative
> values to 0.
>
> After correcting the TM images in Grass I created 6000 random point in
> order to compare the images (flash vs. 6s). The attached graph shows
> the density plot (~histogram) for each band (band 6 is actually TM
> band7). For all images, value have been scaled from 0 to 1. Black line
> is radiance, red is 6S and blue is flash. What we see is that for
> bands 4, 5 and 7 there are no big differences but, for bands 1, 2 and
> 3, the correction done by flash is more pronounced.
>
> Now, what I don't know:
> 1) Is this type of analysis (looking at the image histogram) OK?
> 2) Should atmospheric correction change the histogram?
> 3) For i.atcorr I get a sort of "linear" relation between radiance &
> reflectance. That is, for each radiance there is only one value for
> reflectance. But the flash correction gives a point cloud when I
> compare radiance & reflectance (more than one reflectance value for
> the same radiance). What is the expected behavior?

If you use global values for elevation and visibility, you will only
one output value for each input value. If you use an elevation and/or
visibility map as additional input (granted that the values in these
maps are not constants), you may get point clouds, i.e. several
different output values for the same input value if this input value
occurs more than once and either elevation or visibility differ
between the occurences.

Markus M

>
> I'm using Grass 7 svn from about 2 weeks ago. The images are from the
> Pantanal wetland in Brazil in the dry period (still lots of water
> there). For 6S the settings are: Tropical atmosphere, continental
> aerosol mode, 20km visibility.
>
> Thanks and cheers
> Daniel
>
>
> On Fri, May 27, 2011 at 7:34 PM, Juan Benavides Duque  
> wrote:
>> I'm sending the code I used to run the i.atcorr module (including the
>> i.landsat.toar transformation)
>>
>> (I also used the code sent by Yann Chemin (May 23) with the same results)
>>
>> Of two files attached one has the code and other one the  univariate stats
>> output of the band 1 TOAR raster  for one of the 1986 scenes
>>
>> A copy of the original landsat used have been  placed temporarily at the
>> following location " assets "
>>
>> hope somebody can help
>>
>>
>> thanks
>>
>> juan
>>
>>
>> I'm using a desktop running Ubuntu 10.10 with a 64bit  Intel(R) Core(TM) i7
>> CPU 860  @ 2.80GHz
>>
>>
>>
>>
>> 2011/5/27 Gaspar Reyes Póndigo 
>>>
>>> I had same problem, i.atcorr not work with landsat 5TM band 1, 2 and
>>> sometimes with band 3
>>> I tried i.atcorr in different versions of grass, this is my results:
>>>
>>> 1. GRASS-6.4.1-2 under Mac Snow-Leopard 10.6.7: Not work band 1, 2, and
>>> sometimes with band 3 (for years 1992, 1993, 1995 and 1997).
>>> 2. GRASS-6.5. revision 46428 compiled in Mac Snow-Leopard 10.6.7: Not work
>>> band 1, 2, and sometimes with band 3 (for years 1992, 1993, 1995 and 1997)
>>> 3. GRASS-6.5svn45719(2011) under Microsoft Windows Xp sp3: All the bands
>>> work,THIS IS VERY RARE
>>>
>>> My images landsat 5 TM are from Tonameca, Oaxaca, México of years 1985 to
>>> 1999, and 2010 to 2011 (one image series for year), i am work with AOD and
>>> visibility value,  and convert manually DN to radiance (a).
>>>
>>> (a) Lλ = [(LMAXλ − LMINλ) / (Qcalmax − Qcalmin)] (Qcal − Qcalmin) + LMINλ
>>>
>>> Gaspar Reyes Póndigo
>>> Universidad del Mar, Oaxaca, México
>>> Campus Puerto-Ángel
>>> Carretera principal Puerto Ángel Zipolite km 1.5
>>> C.P. 70902
>>>
>>> ---
>>>
>>> Message: 1
>>>
>>> Date: Fri, 27 May 2011 08:53:32 +0530
>>>
>>> From: "Chemin, Yann (IWMI)" 
>>>
>>> Subject: RE: [GRASS-user] Re: i.atcorr returns all NULL values
>>>
>>> To: "Juan Benavides Duque" ,
>>>
>>> 
>>>
>>> Cc: Markus Metz , Elena Mezzini
>>>
>>> 
>>>
>>> Message-ID:
>>>
>>> <001f233294ea894387cfdaadab87de2508506...@iwmix.iwmi.cgiarad.org>
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi Juan,
>>>
>>>
>>>
>>> Can you please give the download link for your images,
>>>
>>> Could you also check the output of i.landsat.toar for them and tell if
>>>
>>> reflectance ranges are valid/logic.
>>>
>>>
>>>
>>> Thank you,
>>>
>>> Yann
>>>
>>>
>>>
>>> From: Juan Benavides Duque [mailto:jbena...@siu.edu]
>>>
>>> Sent: Thursday, May 26, 2011 11:38 PM
>>>
>>> To: Chemin, Yann (IWMI)
>>>
>>> Cc: Markus Metz; Elena Mezzini
>>>
>>> Subject: Re: [GRASS-user] Re: i.atcorr returns all NULL values
>>>
>>>
>>>
>>>
>>> I tried Yann's code for the i.atcorr on some Landsat TM5 images
>>>
>>> It worked very nice for images taken afte

Re: [GRASS-user] Re: i.atcorr returns all NULL values

2011-05-31 Thread Daniel Victoria
Hi Martin,

That's the problem that I'm facing now. Since I'm no expert in
atmospheric correction I don't know which results should I rely on:
Flaash or 6S?

Daniel

On Tue, May 31, 2011 at 6:56 AM, Martin Brandt
 wrote:
> Daniel,
>
> this is really interesting, because the different correction methods can
> influence the results
>
> I really would be interested if these strange results of the flaash method
> are normal..
>
> -
> Department of Geography and
> Regional Research
> UZA II, Althanstr. 14
> 1090 Wien, AUSTRIA
> http://geooekologie.univie.ac.at
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/i-atcorr-returns-all-NULL-values-tp4975543p6422066.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] query values within different angles

2011-05-31 Thread Hamish
Tim wrote:
> I need to query raster values around a city for different
> angles. The result I am aiming at should be the amount of
> landcover surrounding the city within 10 degrees angles and
> different distances to the city.
> 
> So far I tried r.buffer and v.buffer but that are not
> providing what I am lookin for. Using r.mapcalc and
> addressing each pixel separately would be an option but I
> hope that GRASS combined with perhaps PGSQL and Postgis
> functions provides an easier way to achieve that.
> 
> I would highly appreciate any hints how to derive buffers
> for specific angles only.

Hi,

in years past I had a version of r.los for GRASS 5.0 where instead
of reporting the vertical angle to the source point I had it
report horizontal compass heading. I'm sure it's on an old hard
drive somewhere, but in hindsight using r.mapcalc and some simple
trig would be a heck of a lot easier and more efficient than
anything else. No other tools are needed beyond that one amazing
module.


#spearfish
g.region -d
g.region -c
  center easting:  599490.00
  center northing: 4920855.00

Ce=599490
Cn=4920855
 
r.mapcalc "angle_to_pt.cartesian = atan(x() - $Ce, y() - $Cn)"
r.mapcalc "angle_to_pt.compass.1 = 90 - angle_to_pt.cartesian"
r.mapcalc "angle_to_pt.compass = if(angle_to_pt.compass.1 < 0, \
   angle_to_pt.compass.1 + 360, angle_to_pt.compass.1)"
g.remove angle_to_pt.compass.1


MIN_ANGLE=0
MAX_ANGLE=10

r.mapcalc "MASK = if(angle_to_pt.compass >= $MIN_ANGLE \
   && angle_to_pt.compass < $MAX_ANGLE, 1, null() )"

d.redraw




Hamish

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: i.atcorr returns all NULL values

2011-05-31 Thread Martin Brandt
Daniel, 

this is really interesting, because the different correction methods can
influence the results 

I really would be interested if these strange results of the flaash method
are normal..

-
Department of Geography and
Regional Research
UZA II, Althanstr. 14
1090 Wien, AUSTRIA
http://geooekologie.univie.ac.at
--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/i-atcorr-returns-all-NULL-values-tp4975543p6422066.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] query values within different angles

2011-05-31 Thread Tim Besser

Dear GRASS users,

I need to query raster values around a city for different angles. The 
result I am aiming at should be the amount of landcover surrounding the 
city within 10 degrees angles and different distances to the city.


So far I tried r.buffer and v.buffer but that are not providing what I 
am lookin for. Using r.mapcalc and addressing each pixel separately 
would be an option but I hope that GRASS combined with perhaps PGSQL and 
Postgis functions provides an easier way to achieve that.


I would highly appreciate any hints how to derive buffers for specific 
angles only.


kind regards, Tim

P.S.: using GRASS 6.4.1. under Windows, QGIS 1.6.0 and the newest R version
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] gradient (slope) of a road

2011-05-31 Thread Francisco Calzada
Dear list,
I'm new to this list and I wonder if you could help me.
I need to calculate the gradient (slope) of a road. I have a fine DEM to do
it. The problem is when I run r.slope.aspect the resulting slope map have
extremelly and odd high values. I don't know why. Do you? Anyway, could you
tell me how do you calculate the slope of a road?
Thank you in advance.
Paco
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user