[GRASS-user] v.net.iso Performance

Hi all,

I’m using v.net.iso on a very large dataset (National Road Network for Ontario, Canada - 497879 lines) to determine drive-time ‘rings.’ I’m experiencing extremely long calculation times. Since it’s a very large dataset, I’m not entirely surprised. However, my initial tests were done using GRASS 6.3.0 under QGIS 0.11.0 and I stopped the process after 5 full days of running. After these 5 days, it was still at the “Building Graph” stage. I did a search, and found a thread here: http://trac.osgeo.org/grass/ticket/224 which seemed like a good fit.

Hoping that this was the solution, I downloaded GRASS 6.4.0RC3-2 via OSGeo4W, and ran the same command on the same dataset–this time it quickly proceeded to “Build Graphs” but got hung up on “Registering Arcs” where it sat for for 24 hours with no progress. Instead of waiting endlessly, I stopped the process, and am writing this in hopes of another solution.

My question–is the fix outlined in the thread above implemented in GRASS 6.4.0RC3-2 via OSGeo4W? If so, how long should such a process expect to take? If not, what is the easiest way to get the code with this fix? I’m not very experienced with building from source, versioning, etc. but willing to learn if necessary.

Current system:
Windowx XP Pro
Pentium 4 3.00GHz
2.49 GB of RAM

Darren Cope
http://dmcope.freeshell.org
http://bluesignweekly.blogspot.com/

Darren Cope wrote:

Hi all,

I'm using v.net.iso on a very large dataset (National Road Network for Ontario, Canada - 497879 lines) to determine drive-time 'rings.' I'm experiencing extremely long calculation times. Since it's a very large dataset, I'm not entirely surprised. However, my initial tests were done using GRASS 6.3.0 under QGIS 0.11.0 and I stopped the process after 5 full days of running. After these 5 days, it was still at the "Building Graph" stage. I did a search, and found a thread here: http://trac.osgeo.org/grass/ticket/224 which seemed like a good fit.

My question--is the fix outlined in the thread above implemented in GRASS 6.4.0RC3-2 via OSGeo4W?

Not yet, waiting for more testing. Currently it is only fixed in grass65 and grass7.

If so, how long should such a process expect to take?

Rather minutes than hours:-)

If not, what is the easiest way to get the code with this fix? I'm not very experienced with building from source, versioning, etc. but willing to learn if necessary.

Obtaining source for grass65 (and other versions) is described in
http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS6.5

grass65 is very similar to grass64

A good start is the wiki page on how to compile and install
http://grass.osgeo.org/wiki/Compile_and_Install#MS-Windows.2Fnative
see there also the links under MS-Windows/native -> Compile

I'm not using GRASS under Windows myself, so I can only point to some relevant documentation.

Good luck, and it would be great if you could report back if the results of v.net.iso are ok. One step closer to get the fix into grass64.

Markus M

On Thu, Mar 12, 2009 at 2:34 PM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Darren Cope wrote:

...

My question--is the fix outlined in the thread above implemented in GRASS
6.4.0RC3-2 via OSGeo4W?

Not yet, waiting for more testing. Currently it is only fixed in grass65 and
grass7.

If so, how long should such a process expect to take?

Rather minutes than hours:-)

I have made more tests today with LRS
http://www.grassbook.org/examples3rd_chapter6.php
and the results are identical to the pre-fix times.
So also the v.lrs.* which I suppose to use the dblib are
ok. And pretty fast now!

+1 for backporting of the dglib cache fix.

Markus

Markus Neteler wrote:

I have made more tests today with LRS
http://www.grassbook.org/examples3rd_chapter6.php
and the results are identical to the pre-fix times.
So also the v.lrs.* which I suppose to use the dblib are
ok. And pretty fast now!
  

AFAICT, the v.lrs.* modules don't use any of the Vect_net_* or Vect_graph_* functions. I could also not find usage of any of the dglib functions directly (dgl*). So to me it seems that v.lrs.* do not use the dglib. Did I miss something?

Markus M

On Fri, Mar 13, 2009 at 9:40 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Markus Neteler wrote:

I have made more tests today with LRS
http://www.grassbook.org/examples3rd_chapter6.php
and the results are identical to the pre-fix times.
So also the v.lrs.* which I suppose to use the dblib are
ok. And pretty fast now!

AFAICT, the v.lrs.* modules don't use any of the Vect_net_* or Vect_graph_*
functions. I could also not find usage of any of the dglib functions
directly (dgl*). So to me it seems that v.lrs.* do not use the dglib. Did I
miss something?

Uhm, I guess I missed something :slight_smile: Sorry for the noise.

Markus

Hi all,

Was unsuccessful in building Grass 6.5 on Windows (new at this!) and thus haven’t been able to test v.net.iso. I will try again at some point on an Ubuntu machine, and report back. However, it may be a while! When will 6.5 or newer be available as a package in OSGeo4W?

Cheers,

Darren Cope
http://dmcope.freeshell.org
http://bluesignweekly.blogspot.com/

On Fri, Mar 13, 2009 at 3:32 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Mar 12, 2009 at 2:34 PM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Darren Cope wrote:

My question–is the fix outlined in the thread above implemented in GRASS
6.4.0RC3-2 via OSGeo4W?

Not yet, waiting for more testing. Currently it is only fixed in grass65 and
grass7.

If so, how long should such a process expect to take?

Rather minutes than hours:-)

I have made more tests today with LRS
http://www.grassbook.org/examples3rd_chapter6.php
and the results are identical to the pre-fix times.
So also the v.lrs.* which I suppose to use the dblib are
ok. And pretty fast now!

+1 for backporting of the dglib cache fix.

Markus

Hi,

2009/3/18 Darren Cope <darrencope@gmail.com>:

Ubuntu machine, and report back. However, it may be a while! When will 6.5
or newer be available as a package in OSGeo4W?

no, only grass64 is available in OSGeo4W package.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Hi,

2009/3/18 Martin Landa <landa.martin@gmail.com>:

2009/3/18 Darren Cope <darrencope@gmail.com>:

Ubuntu machine, and report back. However, it may be a while! When will 6.5
or newer be available as a package in OSGeo4W?

no, only grass64 is available in OSGeo4W package.

sorry I should read more carefully. Well, AFAIK it's not decided.
First grass64 should be released, then we can include grass65 / grass7
as devel version.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Wed, Mar 18, 2009 at 9:59 AM, Darren Cope <darrencope@gmail.com> wrote:

Hi all,

Was unsuccessful in building Grass 6.5 on Windows (new at this!) and thus
haven't been able to test v.net.iso.

Colin and me have started to write up a step by step compilation document
(special thanks to Colin!):

http://trac.osgeo.org/grass/wiki/CompileOnWindows

which is still evolving but hopefully already helpful. Comment
or direct modifications welcome.

I will try again at some point on an
Ubuntu machine, and report back. However, it may be a while! When will 6.5
or newer be available as a package in OSGeo4W?

That's unlikely unless we find a volunteer.

Markus