[GRASS-user] Problem with r.hazard.flood

GRASS GRASS user
1

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@lists.osgeo.org> wrote:

Send grass-user mailing list submissions to
grass-user@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@lists.osgeo.org

You can reach the person managing the list at
grass-user-owner@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@gmail.com>
To: Aren Cambre <aren@arencambre.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAG+h=FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@gmail.com>
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e=Wotah-mXLaiiHq3Esjg@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:

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@gmail.com>
To: Andres Fock Kunstmann <anfock@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm=aqOzAEANm9og@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2012/11/23 Andres Fock Kunstmann <anfock@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@arencambre.com>
To: Markus Metz <markus.metz.giswork@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAA1mBrohSzDyiVG_rQtsmz+XxWg_ysHgBQ-D_uHbRp2dyEA8oA@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@gmail.com>wrote:

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

End of grass-user Digest, Vol 79, Issue 41

2

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@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@lists.osgeo.org> wrote:

Send grass-user mailing list submissions to
grass-user@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@lists.osgeo.org

You can reach the person managing the list at
grass-user-owner@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@gmail.com>
To: Aren Cambre <aren@arencambre.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAG+h=FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@gmail.com>
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e=Wotah-mXLaiiHq3Esjg@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:

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@gmail.com>
To: Andres Fock Kunstmann <anfock@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm=aqOzAEANm9og@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2012/11/23 Andres Fock Kunstmann <anfock@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@arencambre.com>
To: Markus Metz <markus.metz.giswork@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAA1mBrohSzDyiVG_rQtsmz+XxWg_ysHgBQ-D_uHbRp2dyEA8oA@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@gmail.com>wrote:

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@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@gmail.com
(56-9)-81576063 - (56-2)-2744097

3

Ok thanks.

Cheers,

Swapan

···

2012/11/24 SWAPAN GHOSH <swap.ghsh@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@lists.osgeo.org> wrote:

Send grass-user mailing list submissions to
grass-user@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@lists.osgeo.org

You can reach the person managing the list at
grass-user-owner@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@gmail.com>
To: Aren Cambre <aren@arencambre.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAG+h=FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@gmail.com>
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e=Wotah-mXLaiiHq3Esjg@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:

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@gmail.com>
To: Andres Fock Kunstmann <anfock@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Problem with r.hazard.flood
Message-ID:
<CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm=aqOzAEANm9og@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2012/11/23 Andres Fock Kunstmann <anfock@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@arencambre.com>
To: Markus Metz <markus.metz.giswork@gmail.com>
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?
Message-ID:
<CAA1mBrohSzDyiVG_rQtsmz+XxWg_ysHgBQ-D_uHbRp2dyEA8oA@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@gmail.com>wrote:

On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <aren@arencambre.com> wrote:

Isn’t taking about 10,000% too much time considered a bug? :slight_smile:

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@gmail.com>
wrote:

On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <aren@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@gmail.com>
wrote:

On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <aren@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@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@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@gmail.com
(56-9)-81576063 - (56-2)-2744097