<b>Hi Andres,</b><div><br></div><div>You just copy the <a href="http://r.hazard.flood.py">r.hazard.flood.py</a> 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 <b>r.hazard.flood</b> contains-</div>
<div><br></div><div><div><b>@"%GRASS_SH%" "%GISBASE%/scripts/ <a href="http://r.hazard.flood.py">r.hazard.flood.py</a>" %* </b></div><div><br></div><div>in the C:\OSGeo4W\apps\grass\grass-6.5.svn\bin directory</div>
<div><br></div><div>For help file just copy the <b>r.hazard.flood.py.html </b>file in the C:\OSGeo4W\apps\grass\grass-6.5.svn\docs\html directory</div><div><br></div><div>You are then able to execute the <b>Hazard Flood</b> by calling <b>r.hazard.flood in the </b>Grass command console.</div>
<div><br></div><div><b>Thanks & Regards,</b></div><div><b><br></b></div><div><b>Swapan</b></div><div><br></div><br><div class="gmail_quote">On Fri, Nov 23, 2012 at 10:06 PM, <span dir="ltr"><<a href="mailto:grass-user-request@lists.osgeo.org" target="_blank">grass-user-request@lists.osgeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send grass-user mailing list submissions to<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:grass-user-request@lists.osgeo.org">grass-user-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:grass-user-owner@lists.osgeo.org">grass-user-owner@lists.osgeo.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of grass-user digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Does v.kernel have to take 16+ hours? (Markus Metz)<br>
2. Problem with r.hazard.flood (Andres Fock Kunstmann)<br>
3. Re: Problem with r.hazard.flood (Martin Landa)<br>
4. Re: Does v.kernel have to take 16+ hours? (Aren Cambre)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 23 Nov 2012 14:32:11 +0100<br>
From: Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
To: Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>><br>
Cc: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?<br>
Message-ID:<br>
<CAG+h=<a href="mailto:FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ@mail.gmail.com">FGmLkJeSZrwjVMVOQ6bp2Bqs9iozd-H7fw6CUfFaNAuZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>> wrote:<br>
> Isn't taking about 10,000% too much time considered a bug? :-)<br>
<br>
Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and<br>
r53983, respectively.<br>
<br>
Markus M<br>
<br>
><br>
> On Nov 23, 2012 5:11 AM, "Markus Metz" <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>> wrote:<br>
>> > I'm able to reproduce reliably here. I'll email you details privately.<br>
>><br>
>> Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with<br>
>> the settings provided by you. It does not crash, however.<br>
>><br>
>> I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead<br>
>> of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4<br>
>> because by now only bugs should be fixed.<br>
>><br>
>> Markus M<br>
>><br>
>> ><br>
>> > Aren<br>
>> ><br>
>> ><br>
>> > On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz<br>
>> > <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>><br>
>> >> wrote:<br>
>> >> > I have a dataset of just over 700,000 incidents that happened in<br>
>> >> > square-ish<br>
>> >> > Texas county that's about 30 miles on each side.<br>
>> >> ><br>
>> >> > Here's the parameters reported by v.kernel as it's executing:<br>
>> >> ><br>
>> >> > STDDEV: 1000.000000<br>
>> >> > RES: 111.419043 ROWS: 458 COLS: 447<br>
>> >> ><br>
>> >> > Writing output raster map using smooth parameter=1000.000000.<br>
>> >> ><br>
>> >> > Normalising factor=6482635.018778.<br>
>> >> ><br>
>> >> ><br>
>> >> > I am running this on a Windows 7 x64 machine with 8 GB RAM and an<br>
>> >> > Intel<br>
>> >> > Core<br>
>> >> > i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not<br>
>> >> > multithreaded,<br>
>> >> > only using 1 core.<br>
>> >> ><br>
>> >> > It takes about 16 hours to complete. Is this correct? I'd like to use<br>
>> >> > this<br>
>> >> > on a dataset with closer to 5 million records, and I'm really<br>
>> >> > concerned<br>
>> >> > how<br>
>> >> > long it may take.<br>
>> >><br>
>> >> The time required by v.kernel is a function of the number of cells and<br>
>> >> the input parameter stddeviation. The larger any of these values is,<br>
>> >> the more time v.kernel will need. Nevertheless, I think that the 16+<br>
>> >> hours are not correct. I tested with a vector with 3 million points<br>
>> >> for a grid with 2700 rows and 1087 columns, magnitudes larger than the<br>
>> >> grid used by you. v.kernel completes in just over one minute.<br>
>> >><br>
>> >> ><br>
>> >> > I posted my question about the 16+ hours at<br>
>> >> ><br>
>> >> ><br>
>> >> > <a href="http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/" target="_blank">http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/</a>.<br>
>> >> > Bill Huber, who si apparently knowledgeable about kernel density<br>
>> >> > calculations in general, posted a response, and he felt like a kernel<br>
>> >> > density map shouldn't take much time at all. But digging more deeply,<br>
>> >> > turns<br>
>> >> > out he had come up with a kernel density calculation method over a<br>
>> >> > decade<br>
>> >> > ago using Fourier transforms. See<br>
>> >> > <a href="http://www.directionsmag.com/features/convolution/129753" target="_blank">http://www.directionsmag.com/features/convolution/129753</a> and the next<br>
>> >> > two<br>
>> >> > articles linked to it (they are short articles). Apparently this<br>
>> >> > transforms<br>
>> >> > it from an O(n^2) problem to an O(n ln n) complexity problem.<br>
>> >><br>
>> >> The approach of Bill Huber is raster-based, not vector based, making<br>
>> >> some things easier, at the cost of precision. The coordinate<br>
>> >> precision, however, is only needed for kernel functions other than<br>
>> >> uniform. In GRASS, you could get something like a raster-based density<br>
>> >> map by<br>
>> >><br>
>> >> - exporting the points with v.out.ascii<br>
>> >> - re-importing the points with r.in.xyz method=n to get the number of<br>
>> >> points per cell<br>
>> >> - running a neighborhood analysis using a circular window with<br>
>> >> r.neighbors method=sum -c<br>
>> >><br>
>> >> Optionally you could use the gauss option of r.neighbors to get an<br>
>> >> equivalent to v.kernel kernel=gaussian<br>
>> >><br>
>> >> HTH,<br>
>> >><br>
>> >> Markus M<br>
>> >><br>
>> >> ><br>
>> >> > I inspected v.kernel's main.c<br>
>> >> ><br>
>> >> ><br>
>> >> > (<a href="http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c" target="_blank">http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c</a>),<br>
>> >> > and looks like v.kernel uses an output-centric method (using Bill's<br>
>> >> > wording)<br>
>> >> > of calculating the output, which seems like O(n^2) complexity.<br>
>> >> ><br>
>> >> > So I guess what I'm getting at is it appears to me that the algorithm<br>
>> >> > behind<br>
>> >> > GRASS GIS's v.kernel is straightforward but is a greedy algorithm<br>
>> >> > (<a href="http://en.wikipedia.org/wiki/Greedy_algorithm" target="_blank">http://en.wikipedia.org/wiki/Greedy_algorithm</a>), which is fine, but<br>
>> >> > it<br>
>> >> > make<br>
>> >> > take a while to execute. Is this true?<br>
>> >> ><br>
>> >> > Is there not spatial indexing I could add to the dataset? I've done<br>
>> >> > various<br>
>> >> > Google searches on that and can't come up with anything clear.<br>
>> >> ><br>
>> >> > Aren<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > grass-user mailing list<br>
>> >> > <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
>> >> > <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
>> >> ><br>
>> ><br>
>> ><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 23 Nov 2012 11:15:55 -0300<br>
From: Andres Fock Kunstmann <<a href="mailto:anfock@gmail.com">anfock@gmail.com</a>><br>
To: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
Subject: [GRASS-user] Problem with r.hazard.flood<br>
Message-ID:<br>
<CAAV04rQZNw2Q=Baxg2b4D4fdUw6Q1e=<a href="mailto:Wotah-mXLaiiHq3Esjg@mail.gmail.com">Wotah-mXLaiiHq3Esjg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi guys.<br>
<br>
I'm trying to install the r.hazard.flood module but I get this error when I<br>
run g.extension<br>
<br>
(Wed Nov 21 21:56:54 2012)<br>
<br>
<a href="http://g.extension.py" target="_blank">g.extension.py</a> extension=r.hazard.flood svnurl=<br>
<a href="http://svn.osgeo.org/grass/grass-addons/grass6" target="_blank">http://svn.osgeo.org/grass/grass-addons/grass6</a><br>
Fetching <r.hazard.flood> from GRASS-Addons SVN (be patient)...<br>
Compiling...<br>
Makefile:5: /usr/lib/grass64/include/Make/Script.make: No<br>
such file or directory<br>
make: *** No rule to make target<br>
`/usr/lib/grass64/include/Make/Script.make'. Stop.<br>
ERROR: Compilation failed, sorry. Please check above error messages.<br>
(Wed Nov 21 21:57:00 2012) Command finished (5 sec)<br>
<br>
When I look into<br>
<a href="https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/" target="_blank">https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/</a>, the<br>
folder has the following files:<br>
<br>
<br>
- Makefile<<a href="https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/Makefile" target="_blank">https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/Makefile</a>><br>
- description.html<<a href="https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/description.html" target="_blank">https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/description.html</a>><br>
- <a href="http://r.hazard.flood.py" target="_blank">r.hazard.flood.py</a><<a href="https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py" target="_blank">https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py</a>><br>
<br>
I need to run the makefile or I just need to copy the<br>
r.hazard.flood.pyscript into a specific folder? I'm currently using<br>
ubuntu 12.10 and<br>
installed grass via apt-get with the ubuntugis package.<br>
<br>
Thank you in advance!<br>
<br>
--<br>
Andr?s Fock Kunstmann<br>
Ge?logo - Mag?ster en Ciencias<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/49e2f3e3/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/49e2f3e3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 23 Nov 2012 15:25:06 +0100<br>
From: Martin Landa <<a href="mailto:landa.martin@gmail.com">landa.martin@gmail.com</a>><br>
To: Andres Fock Kunstmann <<a href="mailto:anfock@gmail.com">anfock@gmail.com</a>><br>
Cc: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
Subject: Re: [GRASS-user] Problem with r.hazard.flood<br>
Message-ID:<br>
<CA+Ei1Oe8UgyV-ysVMWj4YGEvQa1h-a3CF9Hhm=<a href="mailto:aqOzAEANm9og@mail.gmail.com">aqOzAEANm9og@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi,<br>
<br>
2012/11/23 Andres Fock Kunstmann <<a href="mailto:anfock@gmail.com">anfock@gmail.com</a>>:<br>
> I'm trying to install the r.hazard.flood module but I get this error when I<br>
> run g.extension<br>
><br>
> (Wed Nov 21 21:56:54 2012)<br>
><br>
> <a href="http://g.extension.py" target="_blank">g.extension.py</a> extension=r.hazard.flood<br>
> svnurl=<a href="http://svn.osgeo.org/grass/grass-addons/grass6" target="_blank">http://svn.osgeo.org/grass/grass-addons/grass6</a><br>
> Fetching <r.hazard.flood> from GRASS-Addons SVN (be patient)...<br>
> Compiling...<br>
> Makefile:5: /usr/lib/grass64/include/Make/Script.make: No<br>
> such file or directory<br>
<br>
try to install `grass-dev` package. Martin<br>
<br>
--<br>
Martin Landa <landa.martin <a href="http://gmail.com" target="_blank">gmail.com</a>> * <a href="http://geo.fsv.cvut.cz/~landa" target="_blank">http://geo.fsv.cvut.cz/~landa</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 23 Nov 2012 10:35:45 -0600<br>
From: Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>><br>
To: Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
Cc: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours?<br>
Message-ID:<br>
<<a href="mailto:CAA1mBrohSzDyiVG_rQtsmz%2BXxWg_ysHgBQ-D_uHbRp2dyEA8oA@mail.gmail.com">CAA1mBrohSzDyiVG_rQtsmz+XxWg_ysHgBQ-D_uHbRp2dyEA8oA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Thanks!<br>
<br>
I am not familiar with GRASS's release customs. Will this become part of a<br>
binary release soon, or should I just pull down the latest release in the<br>
6.4.2 trunk? I'm assuming this has been merged into the trunk...<br>
<br>
Aren<br>
<br>
On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz<br>
<<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>>wrote:<br>
<br>
> On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>> wrote:<br>
> > Isn't taking about 10,000% too much time considered a bug? :-)<br>
><br>
> Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and<br>
> r53983, respectively.<br>
><br>
> Markus M<br>
><br>
> ><br>
> > On Nov 23, 2012 5:11 AM, "Markus Metz" <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
> > wrote:<br>
> >><br>
> >> On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>><br>
> wrote:<br>
> >> > I'm able to reproduce reliably here. I'll email you details privately.<br>
> >><br>
> >> Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with<br>
> >> the settings provided by you. It does not crash, however.<br>
> >><br>
> >> I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead<br>
> >> of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4<br>
> >> because by now only bugs should be fixed.<br>
> >><br>
> >> Markus M<br>
> >><br>
> >> ><br>
> >> > Aren<br>
> >> ><br>
> >> ><br>
> >> > On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz<br>
> >> > <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>
> >> > wrote:<br>
> >> >><br>
> >> >> On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre <<a href="mailto:aren@arencambre.com">aren@arencambre.com</a>><br>
> >> >> wrote:<br>
> >> >> > I have a dataset of just over 700,000 incidents that happened in<br>
> >> >> > square-ish<br>
> >> >> > Texas county that's about 30 miles on each side.<br>
> >> >> ><br>
> >> >> > Here's the parameters reported by v.kernel as it's executing:<br>
> >> >> ><br>
> >> >> > STDDEV: 1000.000000<br>
> >> >> > RES: 111.419043 ROWS: 458 COLS: 447<br>
> >> >> ><br>
> >> >> > Writing output raster map using smooth parameter=1000.000000.<br>
> >> >> ><br>
> >> >> > Normalising factor=6482635.018778.<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > I am running this on a Windows 7 x64 machine with 8 GB RAM and an<br>
> >> >> > Intel<br>
> >> >> > Core<br>
> >> >> > i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not<br>
> >> >> > multithreaded,<br>
> >> >> > only using 1 core.<br>
> >> >> ><br>
> >> >> > It takes about 16 hours to complete. Is this correct? I'd like to<br>
> use<br>
> >> >> > this<br>
> >> >> > on a dataset with closer to 5 million records, and I'm really<br>
> >> >> > concerned<br>
> >> >> > how<br>
> >> >> > long it may take.<br>
> >> >><br>
> >> >> The time required by v.kernel is a function of the number of cells<br>
> and<br>
> >> >> the input parameter stddeviation. The larger any of these values is,<br>
> >> >> the more time v.kernel will need. Nevertheless, I think that the 16+<br>
> >> >> hours are not correct. I tested with a vector with 3 million points<br>
> >> >> for a grid with 2700 rows and 1087 columns, magnitudes larger than<br>
> the<br>
> >> >> grid used by you. v.kernel completes in just over one minute.<br>
> >> >><br>
> >> >> ><br>
> >> >> > I posted my question about the 16+ hours at<br>
> >> >> ><br>
> >> >> ><br>
> >> >> ><br>
> <a href="http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/" target="_blank">http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/</a><br>
> .<br>
> >> >> > Bill Huber, who si apparently knowledgeable about kernel density<br>
> >> >> > calculations in general, posted a response, and he felt like a<br>
> kernel<br>
> >> >> > density map shouldn't take much time at all. But digging more<br>
> deeply,<br>
> >> >> > turns<br>
> >> >> > out he had come up with a kernel density calculation method over a<br>
> >> >> > decade<br>
> >> >> > ago using Fourier transforms. See<br>
> >> >> > <a href="http://www.directionsmag.com/features/convolution/129753" target="_blank">http://www.directionsmag.com/features/convolution/129753</a> and the<br>
> next<br>
> >> >> > two<br>
> >> >> > articles linked to it (they are short articles). Apparently this<br>
> >> >> > transforms<br>
> >> >> > it from an O(n^2) problem to an O(n ln n) complexity problem.<br>
> >> >><br>
> >> >> The approach of Bill Huber is raster-based, not vector based, making<br>
> >> >> some things easier, at the cost of precision. The coordinate<br>
> >> >> precision, however, is only needed for kernel functions other than<br>
> >> >> uniform. In GRASS, you could get something like a raster-based<br>
> density<br>
> >> >> map by<br>
> >> >><br>
> >> >> - exporting the points with v.out.ascii<br>
> >> >> - re-importing the points with r.in.xyz method=n to get the number of<br>
> >> >> points per cell<br>
> >> >> - running a neighborhood analysis using a circular window with<br>
> >> >> r.neighbors method=sum -c<br>
> >> >><br>
> >> >> Optionally you could use the gauss option of r.neighbors to get an<br>
> >> >> equivalent to v.kernel kernel=gaussian<br>
> >> >><br>
> >> >> HTH,<br>
> >> >><br>
> >> >> Markus M<br>
> >> >><br>
> >> >> ><br>
> >> >> > I inspected v.kernel's main.c<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > (<br>
> <a href="http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c" target="_blank">http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c</a>),<br>
> >> >> > and looks like v.kernel uses an output-centric method (using Bill's<br>
> >> >> > wording)<br>
> >> >> > of calculating the output, which seems like O(n^2) complexity.<br>
> >> >> ><br>
> >> >> > So I guess what I'm getting at is it appears to me that the<br>
> algorithm<br>
> >> >> > behind<br>
> >> >> > GRASS GIS's v.kernel is straightforward but is a greedy algorithm<br>
> >> >> > (<a href="http://en.wikipedia.org/wiki/Greedy_algorithm" target="_blank">http://en.wikipedia.org/wiki/Greedy_algorithm</a>), which is fine,<br>
> but<br>
> >> >> > it<br>
> >> >> > make<br>
> >> >> > take a while to execute. Is this true?<br>
> >> >> ><br>
> >> >> > Is there not spatial indexing I could add to the dataset? I've done<br>
> >> >> > various<br>
> >> >> > Google searches on that and can't come up with anything clear.<br>
> >> >> ><br>
> >> >> > Aren<br>
> >> >> ><br>
> >> >> > _______________________________________________<br>
> >> >> > grass-user mailing list<br>
> >> >> > <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
> >> >> > <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
> >> >> ><br>
> >> ><br>
> >> ><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/25712075/attachment.html" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20121123/25712075/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
<br>
<br>
End of grass-user Digest, Vol 79, Issue 41<br>
******************************************<br>
</blockquote></div><br></div>