Hi, I have installed grass-dev, and I solved the issue following these steps:
1) If I run g.extension from the GUI (Settings--> install extension from addons) doesn't work. 2) If I run g.extension r.hazard.flood from the console works with no problem, so now it works. Thanks for the support! 2012/11/24 SWAPAN GHOSH <[email protected]> > *Hi Andres,* > > You just copy the r.hazard.flood.py from the r.hazard.flood folder to > anwhere in your grass directory.It is better if you copy this to as for > example like C:\OSGeo4W\apps\grass\grass-6.5.svn\scripts directory. And > then write batch file named *r.hazard.flood* contains- > > *@"%GRASS_SH%" "%GISBASE%/scripts/ r.hazard.flood.py" %* * > > in the C:\OSGeo4W\apps\grass\grass-6.5.svn\bin directory > > For help file just copy the *r.hazard.flood.py.html *file in > the C:\OSGeo4W\apps\grass\grass-6.5.svn\docs\html directory > > You are then able to execute the *Hazard Flood* by calling *r.hazard.flood > in the *Grass command console. > > *Thanks & Regards,* > * > * > *Swapan* > > > On Fri, Nov 23, 2012 at 10:06 PM, <[email protected]>wrote: > >> Send grass-user mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.osgeo.org/mailman/listinfo/grass-user >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of grass-user digest..." >> >> >> Today's Topics: >> >> 1. Re: Does v.kernel have to take 16+ hours? (Markus Metz) >> 2. Problem with r.hazard.flood (Andres Fock Kunstmann) >> 3. Re: Problem with r.hazard.flood (Martin Landa) >> 4. Re: Does v.kernel have to take 16+ hours? (Aren Cambre) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 23 Nov 2012 14:32:11 +0100 >> From: Markus Metz <[email protected]> >> To: Aren Cambre <[email protected]> >> Cc: [email protected] >> Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours? >> Message-ID: >> <CAG+h= >> [email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <[email protected]> wrote: >> > Isn't taking about 10,000% too much time considered a bug? :-) >> >> Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and >> r53983, respectively. >> >> Markus M >> >> > >> > On Nov 23, 2012 5:11 AM, "Markus Metz" <[email protected]> >> > wrote: >> >> >> >> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <[email protected]> >> wrote: >> >> > I'm able to reproduce reliably here. I'll email you details >> privately. >> >> >> >> Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with >> >> the settings provided by you. It does not crash, however. >> >> >> >> I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead >> >> of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 >> >> because by now only bugs should be fixed. >> >> >> >> Markus M >> >> >> >> > >> >> > Aren >> >> > >> >> > >> >> > On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <[email protected]> >> >> >> wrote: >> >> >> > I have a dataset of just over 700,000 incidents that happened in >> >> >> > square-ish >> >> >> > Texas county that's about 30 miles on each side. >> >> >> > >> >> >> > Here's the parameters reported by v.kernel as it's executing: >> >> >> > >> >> >> > STDDEV: 1000.000000 >> >> >> > RES: 111.419043 ROWS: 458 COLS: 447 >> >> >> > >> >> >> > Writing output raster map using smooth parameter=1000.000000. >> >> >> > >> >> >> > Normalising factor=6482635.018778. >> >> >> > >> >> >> > >> >> >> > I am running this on a Windows 7 x64 machine with 8 GB RAM and an >> >> >> > Intel >> >> >> > Core >> >> >> > i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not >> >> >> > multithreaded, >> >> >> > only using 1 core. >> >> >> > >> >> >> > It takes about 16 hours to complete. Is this correct? I'd like to >> use >> >> >> > this >> >> >> > on a dataset with closer to 5 million records, and I'm really >> >> >> > concerned >> >> >> > how >> >> >> > long it may take. >> >> >> >> >> >> The time required by v.kernel is a function of the number of cells >> and >> >> >> the input parameter stddeviation. The larger any of these values is, >> >> >> the more time v.kernel will need. Nevertheless, I think that the 16+ >> >> >> hours are not correct. I tested with a vector with 3 million points >> >> >> for a grid with 2700 rows and 1087 columns, magnitudes larger than >> the >> >> >> grid used by you. v.kernel completes in just over one minute. >> >> >> >> >> >> > >> >> >> > I posted my question about the 16+ hours at >> >> >> > >> >> >> > >> >> >> > >> http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/ >> . >> >> >> > Bill Huber, who si apparently knowledgeable about kernel density >> >> >> > calculations in general, posted a response, and he felt like a >> kernel >> >> >> > density map shouldn't take much time at all. But digging more >> deeply, >> >> >> > turns >> >> >> > out he had come up with a kernel density calculation method over a >> >> >> > decade >> >> >> > ago using Fourier transforms. See >> >> >> > http://www.directionsmag.com/features/convolution/129753 and the >> next >> >> >> > two >> >> >> > articles linked to it (they are short articles). Apparently this >> >> >> > transforms >> >> >> > it from an O(n^2) problem to an O(n ln n) complexity problem. >> >> >> >> >> >> The approach of Bill Huber is raster-based, not vector based, making >> >> >> some things easier, at the cost of precision. The coordinate >> >> >> precision, however, is only needed for kernel functions other than >> >> >> uniform. In GRASS, you could get something like a raster-based >> density >> >> >> map by >> >> >> >> >> >> - exporting the points with v.out.ascii >> >> >> - re-importing the points with r.in.xyz method=n to get the number >> of >> >> >> points per cell >> >> >> - running a neighborhood analysis using a circular window with >> >> >> r.neighbors method=sum -c >> >> >> >> >> >> Optionally you could use the gauss option of r.neighbors to get an >> >> >> equivalent to v.kernel kernel=gaussian >> >> >> >> >> >> HTH, >> >> >> >> >> >> Markus M >> >> >> >> >> >> > >> >> >> > I inspected v.kernel's main.c >> >> >> > >> >> >> > >> >> >> > ( >> http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c), >> >> >> > and looks like v.kernel uses an output-centric method (using >> Bill's >> >> >> > wording) >> >> >> > of calculating the output, which seems like O(n^2) complexity. >> >> >> > >> >> >> > So I guess what I'm getting at is it appears to me that the >> algorithm >> >> >> > behind >> >> >> > GRASS GIS's v.kernel is straightforward but is a greedy algorithm >> >> >> > (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, >> but >> >> >> > it >> >> >> > make >> >> >> > take a while to execute. Is this true? >> >> >> > >> >> >> > Is there not spatial indexing I could add to the dataset? I've >> done >> >> >> > various >> >> >> > Google searches on that and can't come up with anything clear. >> >> >> > >> >> >> > Aren >> >> >> > >> >> >> > _______________________________________________ >> >> >> > grass-user mailing list >> >> >> > [email protected] >> >> >> > http://lists.osgeo.org/mailman/listinfo/grass-user >> >> >> > >> >> > >> >> > >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 23 Nov 2012 11:15:55 -0300 >> From: Andres Fock Kunstmann <[email protected]> >> To: [email protected] >> Subject: [GRASS-user] Problem with r.hazard.flood >> Message-ID: >> <CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e= >> [email protected]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi guys. >> >> >> I'm trying to install the r.hazard.flood module but I get this error when >> I >> run g.extension >> >> (Wed Nov 21 21:56:54 2012) >> >> g.extension.py extension=r.hazard.flood svnurl= >> http://svn.osgeo.org/grass/grass-addons/grass6 >> Fetching <r.hazard.flood> from GRASS-Addons SVN (be patient)... >> Compiling... >> Makefile:5: /usr/lib/grass64/include/Make/Script.make: No >> such file or directory >> make: *** No rule to make target >> `/usr/lib/grass64/include/Make/Script.make'. Stop. >> ERROR: Compilation failed, sorry. Please check above error messages. >> (Wed Nov 21 21:57:00 2012) Command finished (5 sec) >> >> When I look into >> https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/, >> the >> folder has the following files: >> >> >> - Makefile< >> https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/Makefile >> > >> - description.html< >> https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/description.html >> > >> - r.hazard.flood.py< >> https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py >> > >> >> >> I need to run the makefile or I just need to copy the >> r.hazard.flood.pyscript into a specific folder? I'm currently using >> >> ubuntu 12.10 and >> installed grass via apt-get with the ubuntugis package. >> >> Thank you in advance! >> >> -- >> Andr?s Fock Kunstmann >> Ge?logo - Mag?ster en Ciencias >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/49e2f3e3/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 23 Nov 2012 15:25:06 +0100 >> From: Martin Landa <[email protected]> >> To: Andres Fock Kunstmann <[email protected]> >> Cc: [email protected] >> Subject: Re: [GRASS-user] Problem with r.hazard.flood >> Message-ID: >> <CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm= >> [email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> Hi, >> >> 2012/11/23 Andres Fock Kunstmann <[email protected]>: >> > I'm trying to install the r.hazard.flood module but I get this error >> when I >> > run g.extension >> > >> > (Wed Nov 21 21:56:54 2012) >> > >> > g.extension.py extension=r.hazard.flood >> > svnurl=http://svn.osgeo.org/grass/grass-addons/grass6 >> > Fetching <r.hazard.flood> from GRASS-Addons SVN (be patient)... >> > Compiling... >> > Makefile:5: /usr/lib/grass64/include/Make/Script.make: No >> > such file or directory >> >> try to install `grass-dev` package. Martin >> >> -- >> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 23 Nov 2012 10:35:45 -0600 >> From: Aren Cambre <[email protected]> >> To: Markus Metz <[email protected]> >> Cc: [email protected] >> Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours? >> Message-ID: >> < >> caa1mbrohszdyivg_rqtsmz+xxwg_yshgbq-d_uhbrp2dyea...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Thanks! >> >> I am not familiar with GRASS's release customs. Will this become part of a >> binary release soon, or should I just pull down the latest release in the >> 6.4.2 trunk? I'm assuming this has been merged into the trunk... >> >> Aren >> >> On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz >> <[email protected]>wrote: >> >> > On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <[email protected]> >> wrote: >> > > Isn't taking about 10,000% too much time considered a bug? :-) >> > >> > Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and >> > r53983, respectively. >> > >> > Markus M >> > >> > > >> > > On Nov 23, 2012 5:11 AM, "Markus Metz" <[email protected] >> > >> > > wrote: >> > >> >> > >> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <[email protected]> >> > wrote: >> > >> > I'm able to reproduce reliably here. I'll email you details >> privately. >> > >> >> > >> Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with >> > >> the settings provided by you. It does not crash, however. >> > >> >> > >> I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead >> > >> of 16+ hours, but I am not sure if this fix can/will go into GRASS >> 6.4 >> > >> because by now only bugs should be fixed. >> > >> >> > >> Markus M >> > >> >> > >> > >> > >> > Aren >> > >> > >> > >> > >> > >> > On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz >> > >> > <[email protected]> >> > >> > wrote: >> > >> >> >> > >> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <[email protected] >> > >> > >> >> wrote: >> > >> >> > I have a dataset of just over 700,000 incidents that happened in >> > >> >> > square-ish >> > >> >> > Texas county that's about 30 miles on each side. >> > >> >> > >> > >> >> > Here's the parameters reported by v.kernel as it's executing: >> > >> >> > >> > >> >> > STDDEV: 1000.000000 >> > >> >> > RES: 111.419043 ROWS: 458 COLS: 447 >> > >> >> > >> > >> >> > Writing output raster map using smooth parameter=1000.000000. >> > >> >> > >> > >> >> > Normalising factor=6482635.018778. >> > >> >> > >> > >> >> > >> > >> >> > I am running this on a Windows 7 x64 machine with 8 GB RAM and >> an >> > >> >> > Intel >> > >> >> > Core >> > >> >> > i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not >> > >> >> > multithreaded, >> > >> >> > only using 1 core. >> > >> >> > >> > >> >> > It takes about 16 hours to complete. Is this correct? I'd like >> to >> > use >> > >> >> > this >> > >> >> > on a dataset with closer to 5 million records, and I'm really >> > >> >> > concerned >> > >> >> > how >> > >> >> > long it may take. >> > >> >> >> > >> >> The time required by v.kernel is a function of the number of cells >> > and >> > >> >> the input parameter stddeviation. The larger any of these values >> is, >> > >> >> the more time v.kernel will need. Nevertheless, I think that the >> 16+ >> > >> >> hours are not correct. I tested with a vector with 3 million >> points >> > >> >> for a grid with 2700 rows and 1087 columns, magnitudes larger than >> > the >> > >> >> grid used by you. v.kernel completes in just over one minute. >> > >> >> >> > >> >> > >> > >> >> > I posted my question about the 16+ hours at >> > >> >> > >> > >> >> > >> > >> >> > >> > >> http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/ >> > . >> > >> >> > Bill Huber, who si apparently knowledgeable about kernel density >> > >> >> > calculations in general, posted a response, and he felt like a >> > kernel >> > >> >> > density map shouldn't take much time at all. But digging more >> > deeply, >> > >> >> > turns >> > >> >> > out he had come up with a kernel density calculation method >> over a >> > >> >> > decade >> > >> >> > ago using Fourier transforms. See >> > >> >> > http://www.directionsmag.com/features/convolution/129753 and >> the >> > next >> > >> >> > two >> > >> >> > articles linked to it (they are short articles). Apparently this >> > >> >> > transforms >> > >> >> > it from an O(n^2) problem to an O(n ln n) complexity problem. >> > >> >> >> > >> >> The approach of Bill Huber is raster-based, not vector based, >> making >> > >> >> some things easier, at the cost of precision. The coordinate >> > >> >> precision, however, is only needed for kernel functions other than >> > >> >> uniform. In GRASS, you could get something like a raster-based >> > density >> > >> >> map by >> > >> >> >> > >> >> - exporting the points with v.out.ascii >> > >> >> - re-importing the points with r.in.xyz method=n to get the >> number of >> > >> >> points per cell >> > >> >> - running a neighborhood analysis using a circular window with >> > >> >> r.neighbors method=sum -c >> > >> >> >> > >> >> Optionally you could use the gauss option of r.neighbors to get an >> > >> >> equivalent to v.kernel kernel=gaussian >> > >> >> >> > >> >> HTH, >> > >> >> >> > >> >> Markus M >> > >> >> >> > >> >> > >> > >> >> > I inspected v.kernel's main.c >> > >> >> > >> > >> >> > >> > >> >> > ( >> > http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c >> ), >> > >> >> > and looks like v.kernel uses an output-centric method (using >> Bill's >> > >> >> > wording) >> > >> >> > of calculating the output, which seems like O(n^2) complexity. >> > >> >> > >> > >> >> > So I guess what I'm getting at is it appears to me that the >> > algorithm >> > >> >> > behind >> > >> >> > GRASS GIS's v.kernel is straightforward but is a greedy >> algorithm >> > >> >> > (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, >> > but >> > >> >> > it >> > >> >> > make >> > >> >> > take a while to execute. Is this true? >> > >> >> > >> > >> >> > Is there not spatial indexing I could add to the dataset? I've >> done >> > >> >> > various >> > >> >> > Google searches on that and can't come up with anything clear. >> > >> >> > >> > >> >> > Aren >> > >> >> > >> > >> >> > _______________________________________________ >> > >> >> > grass-user mailing list >> > >> >> > [email protected] >> > >> >> > http://lists.osgeo.org/mailman/listinfo/grass-user >> > >> >> > >> > >> > >> > >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/25712075/attachment.html >> > >> >> ------------------------------ >> >> _______________________________________________ >> grass-user mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> >> End of grass-user Digest, Vol 79, Issue 41 >> ****************************************** >> > > -- Andrés Fock Kunstmann Geólogo - Magíster en Ciencias [email protected] (56-9)-81576063 - (56-2)-2744097
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
