I am running viewsheds using the GridModule on 4 tiles. It runs, but the result has some artificial gaps, see the attached picture (black is the correct viewshed as vector and red and blue are wrong results). The problem must be in the patching of the 4 tiles, because the tiles alone are fine. I tried to run the same viewshed couple of times and it seems to behave randomly, sometimes I get correct result, sometimes I get a gap. Any idea what could be wrong? Maybe some bug in the pygrass raster library?
On Tue, Nov 10, 2015 at 7:58 PM, Anna Petrášová <kratochanna@gmail.com> wrote:
Hi,
I am running viewsheds using the GridModule on 4 tiles. It runs, but the
result has some artificial gaps, see the attached picture (black is the
correct viewshed as vector and red and blue are wrong results). The problem
must be in the patching of the 4 tiles, because the tiles alone are fine. I
tried to run the same viewshed couple of times and it seems to behave
randomly, sometimes I get correct result, sometimes I get a gap. Any idea
what could be wrong?
Can you adjust the number of cores being used? To see if it influences it?
On Mon, Nov 16, 2015 at 8:28 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Nov 10, 2015 at 7:58 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:
> Hi,
>
> I am running viewsheds using the GridModule on 4 tiles. It runs, but the
> result has some artificial gaps, see the attached picture (black is the
> correct viewshed as vector and red and blue are wrong results). The
problem
> must be in the patching of the 4 tiles, because the tiles alone are
fine. I
> tried to run the same viewshed couple of times and it seems to behave
> randomly, sometimes I get correct result, sometimes I get a gap. Any idea
> what could be wrong?
Can you adjust the number of cores being used? To see if it influences it?
I can't test right now, maybe later.
> Maybe some bug in the pygrass raster library?
Looks like a race condition?
I don't understand why would that happen, the patching done with pygrass
raster library is not running in parallel.
A workaround I currently use is to patch the rasters using r.patch, which
is in the case of viewsheds OK (the overlaps are the same), however in
other cases such as interpolation, the overlaps are different and r.patch
won't patch the rasters as desired, that's why the GridModule is using
pygrass raster library I assume.
On Mon, Nov 16, 2015 at 3:23 PM, Anna Petrášová <kratochanna@gmail.com> wrote:
On Mon, Nov 16, 2015 at 8:28 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Nov 10, 2015 at 7:58 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:
> Maybe some bug in the pygrass raster library?
Looks like a race condition?
I don't understand why would that happen, the patching done with pygrass
raster library is not running in parallel.
Yes I have to investigate more on this to understand what it is not working...
A workaround I currently use is to patch the rasters using r.patch, which is
in the case of viewsheds OK (the overlaps are the same), however in other
cases such as interpolation, the overlaps are different and r.patch won't
patch the rasters as desired, that's why the GridModule is using pygrass
raster library I assume.
I've modified r.tile to split and merge using an optional parameter
for the overlap (perhaps I should create just a new module r.untile
instead of adding a new flag in r.tile...).
The approach it is much faster than the actual implementation of
r.patch because minimize reading disk operations since we are not
merging general raster maps with undefined bboxes but well known
tiles...
Unfortunately the implementation still experimental and has some
problems. I will not able to work on this before next year... maybe I
can put the modified version of r.tile in the sandbox repo.
I don’t understand why would that happen, the patching done with pygrass
raster library is not running in parallel.
Yes I have to investigate more on this to understand what it is not working…
A workaround I currently use is to patch the rasters using r.patch, which is
in the case of viewsheds OK (the overlaps are the same), however in other
cases such as interpolation, the overlaps are different and r.patch won’t
patch the rasters as desired, that’s why the GridModule is using pygrass
raster library I assume.
I’ve modified r.tile to split and merge using an optional parameter
for the overlap (perhaps I should create just a new module r.untile
instead of adding a new flag in r.tile…).
The approach it is much faster than the actual implementation of
r.patch because minimize reading disk operations since we are not
merging general raster maps with undefined bboxes but well known
tiles…
Unfortunately the implementation still experimental and has some
problems. I will not able to work on this before next year… maybe I
can put the modified version of r.tile in the sandbox repo.
That would be great addition, I think I would keep it in r.tile, r.untile sounds a little weird. I don’t think I would have time to look at it either, but please put it in sandbox, so that it’s somewhere.
I am also having problem that sometimes I am getting
RuntimeError “Execution of subprocesses was not successful”
it appears randomly, once or twice in 100 runs, but it causes quite a bit of trouble. On Windows I was getting this in half of the cases (but with different data and use case so it’s difficult to compare). I think the GridModule is great and makes parallelization so much easier, so I would love to see it working more reliably. It’s clear to me that you don’t have time to look at it now, neither do I, so I am mainly reporting these issues…
