Hi Michael, > r.mapcalc doesn't have local variables - is that right ? The page at > http://grass.itc.it/grass64/manuals/html64_user/r.mapcalc.html doesn't > mention them and all the vars in the examples refer to maps. > > I like the whole map statements such as "mymap = 10" or "mymap = map1 > + map2". Reminds me of using ARCGRID early last century. I plan to > put that into jiffle in some way.
mapcalc has that one. I paste you a small piece of the shaded.relief module of GRASS, which is a bash script with a nice mapcalc example in its middle: r.mapcalc << EOF $elev_out = eval( \\ x=($zmult*$elev[-1,-1] + 2*$zmult*$elev[0,-1] + $zmult*$elev[1,-1] \\ -$zmult*$elev[-1,1] - 2*$zmult*$elev[0,1] - $zmult*$elev[1,1])/(8.*ewres()*$scale) , \\ y=($zmult*$elev[-1,-1] + 2*$zmult*$elev[-1,0] + $zmult*$elev[-1,1] \\ -$zmult*$elev[1,-1] - 2*$zmult*$elev[1,0] - $zmult*$elev[1,1])/(8.*nsres()*$scale) , \\ slope=90.-atan(sqrt(x*x + y*y)), \\ a=round(atan(x,y)), \\ a=if(isnull(a),1,a), \\ aspect=if(x!=0||y!=0,if(a,a,360.)), \\ cang = sin($alt)*sin(slope) + cos($alt)*cos(slope) * cos($az-aspect), \\ if(cang < 0.,0.,100.*cang), \\ if(isnull(cang), null(), 100.*cang)) EOF as you might note, there are variables that are used, apart of the $vars that come from the script. For example the variable 'a' is used to create variable 'aspect' which is used for variable 'cang'. Is that what you were asking for? > After you left last night Simone was talking about the importance of > keeping a clear division between the image domain and the map / > geospatial domain with all this stuff. That's very much my feeling > too. I don't think that presents any obstacles for compatibility with > r.mapcalc but it means that some things will be kept separate from the > core interpreter. > > A little pre-processor could take care of grass-specific things like > the m...@mapset notation. Other features of r.mapcalc such as allowing > division by 0 and inverse-trig functions return results in degrees > could also be handled by the pre-processor or perhaps by setting some > options on the interpreter. > > At this early stage it seems that it should be feasible to get jiffle > (+pre-processor or whatever) to handle r.mapcalc scripts. It's a nice > thing to aim for :) And there will be some additional elements in > jiffle so that can be used for new scripts. That sounds very nice to me. I guess I might put effort and knowledge to keep GRASS compatibility, but I am very glad if this one is able to do more :), you can bet on that. Andrea > > Michael > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
