Ok thanks. Cheers,
Swapan On Wed, Nov 28, 2012 at 3:16 AM, Andres Fock Kunstmann <[email protected]>wrote: > 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
