[GRASS-user] Problem with r.hazard.flood
Andres Fock Kunstmann
anfock at gmail.com
Tue Nov 27 13:46:32 PST 2012
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 <swap.ghsh at gmail.com>
> *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, <grass-user-request at lists.osgeo.org>wrote:
>
>> Send grass-user mailing list submissions to
>> grass-user at lists.osgeo.org
>>
>> 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
>> grass-user-request at lists.osgeo.org
>>
>> You can reach the person managing the list at
>> grass-user-owner at lists.osgeo.org
>>
>> 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 <markus.metz.giswork at gmail.com>
>> To: Aren Cambre <aren at arencambre.com>
>> Cc: grass-user at lists.osgeo.org
>> Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
>> Message-ID:
>> <CAG+h=
>> FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren at arencambre.com> 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" <markus.metz.giswork at gmail.com>
>> > wrote:
>> >>
>> >> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren at arencambre.com>
>> 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
>> >> > <markus.metz.giswork at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren at arencambre.com>
>> >> >> 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
>> >> >> > grass-user at lists.osgeo.org
>> >> >> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >> >> >
>> >> >
>> >> >
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 23 Nov 2012 11:15:55 -0300
>> From: Andres Fock Kunstmann <anfock at gmail.com>
>> To: grass-user at lists.osgeo.org
>> Subject: [GRASS-user] Problem with r.hazard.flood
>> Message-ID:
>> <CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e=
>> Wotah-mXLaiiHq3Esjg at mail.gmail.com>
>> 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 <landa.martin at gmail.com>
>> To: Andres Fock Kunstmann <anfock at gmail.com>
>> Cc: grass-user at lists.osgeo.org
>> Subject: Re: [GRASS-user] Problem with r.hazard.flood
>> Message-ID:
>> <CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm=
>> aqOzAEANm9og at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> Hi,
>>
>> 2012/11/23 Andres Fock Kunstmann <anfock at gmail.com>:
>> > 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 <aren at arencambre.com>
>> To: Markus Metz <markus.metz.giswork at gmail.com>
>> Cc: grass-user at lists.osgeo.org
>> Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
>> Message-ID:
>> <
>> CAA1mBrohSzDyiVG_rQtsmz+XxWg_ysHgBQ-D_uHbRp2dyEA8oA at 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
>> <markus.metz.giswork at gmail.com>wrote:
>>
>> > On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren at arencambre.com>
>> 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" <markus.metz.giswork at gmail.com
>> >
>> > > wrote:
>> > >>
>> > >> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren at arencambre.com>
>> > 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
>> > >> > <markus.metz.giswork at gmail.com>
>> > >> > wrote:
>> > >> >>
>> > >> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren at arencambre.com
>> >
>> > >> >> 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
>> > >> >> > grass-user at lists.osgeo.org
>> > >> >> > 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
>> grass-user at lists.osgeo.org
>> 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
anfock at gmail.com
(56-9)-81576063 - (56-2)-2744097
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20121127/96981a71/attachment-0001.html>
More information about the grass-user
mailing list