[GRASS-user] Problem with r.hazard.flood
SWAPAN GHOSH
swap.ghsh at gmail.com
Tue Nov 27 22:13:21 PST 2012
Ok thanks.
Cheers,
Swapan
On Wed, Nov 28, 2012 at 3:16 AM, Andres Fock Kunstmann <anfock at gmail.com>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 <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/20121128/0caf586b/attachment-0001.html>
More information about the grass-user
mailing list