, Markus Metz wrote:
Hi Laura,
Laura Toma wrote:
Hi Markus,
Processing a grid of 312 M cells takes about 8 x 312M = 2GB of RAM,
That is only true for r.terracost with numtiles=1, because r.terracost
stores costs as float. Is it possible that there is a bug in
r.terracost
when using numtiles
or better 512MB of RAM. There
is no way around it. Just try it, it is easy to do. I run
experiments like this all the time.
-Laura
On Nov 14, 2009, at 6:51 AM, Markus Metz wrote:
Hi Laura,
Laura Toma wrote:
my experience is that , if you want to see how an application would
behave
Hi Markus,
How much memory was available on the machine?
8 GB
If the machine had more than 512MB RAM, it is not fair to run
terracost running with mem=400MB, and compare it with an algorithm
that can use more memory.
I don't understand, both modules can use more than 400MB of memory. I
Good idea, and this should cause no problem for the rest.
-Laura
Message: 6
Date: Fri, 7 Aug 2009 16:09:42 -0400
From: Andrew Danner adan...@cs.swarthmore.edu
Subject: Re: [GRASS-dev] r.terraflow broken
To: GRASS developers list grass-dev@lists.osgeo.org
Message-ID:
The problem is that it attempts to set the memory manager limit to 0
(see below: limit=0B), and the first line in
MM_register::set_memory_limit(size_t new_limit)
is
assert(new_limit0).
Therefore the problem.
So the question is, why does it try to set the memory limit to 0?
Unless the
default: /var/tmp
Even though main.cc explicitly executes a setenv, it did not work
for me. I had to explicitly run from the shell:
export STREAM_DIR=/var/tmp/
-Laura
On Jul 15, 2009, at 12:49 PM, Moritz Lennert wrote:
On 15/07/09 15:40, Laura Toma wrote:
Hi Moritz,
Terracost runs
,
On 15/07/09 00:01, Laura Toma wrote:
Hi Markus, Moritz,
I could reproduce the problem. It was happening because the cost of
the source points were incorrectly assigned to be zero, instead of
the actual cost of the points. Because of this, the immediate
neighbors of the source points had half
On Jun 10, 2009, at 11:14 PM, Hamish wrote:
GRASS 6.4.0RC4
(northamericaSRTM3):~/gis/DATA/SRTM/SRTM-V2-
frome0srp01u.ecs.nasa.gov/SRTM3/north_america
does it really extend from 180 lon to 180 lon? (ie include asia)
It is SRTM3 data grouped by continents loaded from
Hi,
I imported a large SRTM grid with r.in.gdal; when starting grass64
with this location there is an error.
Some part of Grass seems to work despite this error, except d.rast
shows a blank screen. The east and west (see below) have the same
value, except E/W. Could this cause troubles?
( -0.000, 35.500) ( 0d 0'0.00W, 35d30'0.00N)
Band 1 Block=432001x1 Type=Int16, ColorInterp=Gray
NoData Value=-32768
[lt...@dover:~/gis/DATA/SRTM/SRTM-V2-frome0srp01u.ecs.nasa.gov/SRTM3/
north_america]$
On Jun 10, 2009, at 4:10 PM, Markus GRASS wrote:
Laura Toma wrote:
Hi,
I
Hi,
If you need a faster module for computing shortest paths , I have
uploaded a module called r.terracost in grass-addons.
It runs Dijkstra algorithm, which is the standard algorithm for SP
(all costs need to be non-negative). The user specifies the input
and output grid, the grid of
Andy,
Thanks for looking at this. I am downloading the grass-trunk right
now, and I'll be able to compile shortly.
-Laura
On Apr 8, 2009, at 2:16 PM, Andrew Danner wrote:
Markus Neteler wrote:
On Thu, Apr 2, 2009 at 7:08 PM, Laura Toma lt...@bowdoin.edu wrote:
If you're looking
If you're looking for a fast version of r.cost, try r.terracost.I
think I put it at some point in the add-ons repository. Otherwise it's
available from my website. Depending on the amount of memory you
specify on the command line, it runs in memory (an optimized CPU
algorithm)
I remember we replaced the fseek() with an fseeko() because we ran
into a bug where we were trying to seek to a large offset (in
r.terracost).
No objection to removing the 2 includes, given that it still compiles
w/o them on other platforms.
-Laura
On Oct 6, 2008, at 9:18 PM, [EMAIL
Unfortunately I cannot reproduce the compile errors, so I cannot be
of much help.
I added r.viewshed in grass_trunk/raster/. It compiles and works for
me. Looking forward to comments.
-Laura
On Aug 10, 2008, at 3:29 PM, Martin Landa wrote:
Hi,
2008/8/10 Paul Kelly [EMAIL PROTECTED]:
I added r.viewshed in grass_trunk/raster/. It compiles and works
for me. Looking forward to comments.
Should it maybe go in grass-addons rather than trunk for now?
I could not get it to compile in the add-ons (probably i need to set
up some grass parameters, etc).My understanding
I added r.viewshed to grass-addons, and deleted it from the trunk.
-Laura
On Aug 13, 2008, at 4:47 PM, Paul Kelly wrote:
On Wed, 13 Aug 2008, Laura Toma wrote:
Unfortunately I cannot reproduce the compile errors, so I cannot
be of much help.
I wondered if you might be able to help
Hi Paul,
There should be no rtimer in viewshed, only in the library. I was
planning to upload the most recent version as soon as I get access
to the svn.
-Laura
On Aug 7, 2008, at 7:00 PM, Paul Kelly wrote:
Hi Laura,
On Tue, 5 Aug 2008, Laura Toma wrote:
I have merged these changes
Hi Paul,
PEARL is off (not defined) when compiling, so it is not
significant. Two libraries is definitely ugly. We'll try to get
r.viewshed to work with the iostream version in GRASS.
Until then, thanks for all the help.
-Laura
On Aug 5, 2008, at 12:45 PM, Paul Kelly wrote:
On
On Jul 9, 2008, at 12:40 PM, Paul Kelly wrote:
Regarding the output: my suggestion was to output, for every
cell that is
visible, its height (or slope) *above* the line of sight; this
will give
an indication of how visible the point is. Similarly, for the
cells that
are *not*
20 matches
Mail list logo
