[GRASS-user] Problem with r.hazard.flood
SWAPAN GHOSH
swap.ghsh at gmail.com
Fri Nov 23 21:16:11 PST 2012
*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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20121124/f9dc40ff/attachment-0001.html>
More information about the grass-user
mailing list