[GRASS-dev] New GRASS 7 addon: v.lidar.mcc

Dear all, Today I uploaded a new GRASS 7 addon to SVN. The Python-script „v.lidar.mcc“ aims at removing vegetation returns from LiDAR point-clouds. It is a modified implementation if Evans Hudak`s (2007) multiscale curvature classification (mcc) algorith. Compared to the original, the GRASS

[GRASS-dev] r.stats output

I am trying to use r.stats to print out a text file with x and y coordinates as well as the area (or cell count). However, it seems any choice is mutually exclusive. If I choose to print the grid coordinates and to print the area, what I get is the coordinates with the category number. If I select

[GRASS-dev] Floating and integer numbers in r.mapcalc

I have the following function (to calculate cell area) PI=3.1415926536 RES=0.0008333 R=6371007 r.mapcalc test3 = (sin(y()+$RES/2) - sin(y()-$RES/2)) * ($RES * $PI/180) * $R^2 This will give me a wrong results, apparently because R is an integer value. If I adapt the formula: r.mapcalc test3 =

Re: [GRASS-dev] r.stats output

On 24/09/14 10:00, Paulo van Breugel wrote: I am trying to use r.stats to print out a text file with x and y coordinates as well as the area (or cell count). However, it seems any choice is mutually exclusive. If I choose to print the grid coordinates and to print the area, what I get is the

Re: [GRASS-dev] r.stats output

Paulo van Breugel: I am trying to use r.stats to print out a text file with x and y coordinates as well as the area (or cell count). However, it seems any choice is mutually exclusive. If I choose to print the grid coordinates and to print the area, what I get is the coordinates with the

Re: [GRASS-dev] [GRASS-user] New GRASS 7 addon: v.lidar.mcc

Thanks for this contribution. I look forward to trying this when I have time. Mark On Wed, Sep 24, 2014 at 3:49 AM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Dear all, Today I uploaded a new GRASS 7 addon to SVN. The Python-script „v.lidar.mcc“ aims at removing vegetation

Re: [GRASS-dev] r.stats output

On Wed, Sep 24, 2014 at 1:12 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/09/14 10:00, Paulo van Breugel wrote: I am trying to use r.stats to print out a text file with x and y coordinates as well as the area (or cell count). However, it seems any choice is mutually

Re: [GRASS-dev] r.stats output

On 24/09/14 14:08, Paulo van Breugel wrote: On Wed, Sep 24, 2014 at 1:12 PM, Moritz Lennert It thus does not make sense to provide coordinates for count or area: which coordinates would you use if you have cells with the same category all over your map ? It makes sense if each

Re: [GRASS-dev] r.stats output

On Wed, Sep 24, 2014 at 2:43 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/09/14 14:08, Paulo van Breugel wrote: On Wed, Sep 24, 2014 at 1:12 PM, Moritz Lennert It thus does not make sense to provide coordinates for count or area: which coordinates would you use if

Re: [GRASS-dev] [GRASS GIS] #2431: vector_what fails with multiple layer/cat

#2431: vector_what fails with multiple layer/cat -+-- Reporter: artegion | Owner: grass-dev@… Type: defect | Status: new Priority: major|

[GRASS-dev] [GRASS GIS] #2432: g.list -f ignores mapset parameter

#2432: g.list -f ignores mapset parameter -+-- Reporter: peifer | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone:

[GRASS-dev] grass71 css changes

Hi, I like changes in the style of the manual which have been recently applied in GRASS 7.1 [1]. Only one thing which I am not sure is a width on the page, it seems to be too narrow [1] to me compared to GRASS 7.0 manual [2]. What about changing width to `width of page` - 2 * `width of toc`?

Re: [GRASS-dev] grass71 css changes

2014-09-24 20:42 GMT+02:00 Martin Landa landa.mar...@gmail.com: width on the page, it seems to be too narrow [1] to me compared to look eg. at [1] where some of examples overflow the border. Martin [1] http://grass.osgeo.org/grass71/manuals/v.in.ascii.html -- Martin Landa *

Re: [GRASS-dev] grass71 css changes

Hi Martin, I'm glad you like it. I was just discussing this with Markus who requested the narrower fixed layout, so I don't want to write it again, so here is the conversation. About the examples, we can add horizontal scroll bar, example is here:

Re: [GRASS-dev] Floating and integer numbers in r.mapcalc

Paulo van Breugel wrote: I have the following function (to calculate cell area) PI=3.1415926536 RES=0.0008333 R=6371007 r.mapcalc test3 = (sin(y()+$RES/2) - sin(y()-$RES/2)) * ($RES * $PI/180) * $R^2 This will give me a wrong results, apparently because R is an integer value. If I

[GRASS-dev] significant change in g.parser behavior for GRASS 7

I just learned that using upper case characters for a GRASS 7 module option means that g.parser will not recognize it. That is for module. “r.foo with options “Abc” and “def”, the command r.foo Abc=1 def=2 will return an error Abd=1 is not a valid option. GRASS 6 does not produce an error in

Re: [GRASS-dev] significant change in g.parser behavior for GRASS 7

On Wed, Sep 24, 2014 at 7:53 PM, Michael Barton michael.bar...@asu.edu wrote: I just learned that using upper case characters for a GRASS 7 module option means that g.parser will not recognize it. That is for module. “r.foo with options “Abc” and “def”, the command r.foo Abc=1 def=2

Re: [GRASS-dev] significant change in g.parser behavior for GRASS 7

The issue is not about whether upper or lower case (or other characters) are good programming form or not in on language or another. This varies from context to context. The issue is about a change in behavior of how GRASS scripts and modules are parsed between GRASS 6 and 7 that can cause