*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 > ****************************************** >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
