Hi again.
I tried a workaround, which is not perfect, but at least allows me to get
the CSV file, which is my main interest by now.
I commented the lines that calls r.width.funct in the r.basin script, so
lines 344-347 looks like this.
#grass.message( "--" )
#
Hi Margherita and thanks for your reply.
In attention to your comment, I delved a little deeper in the issue. What I
found is that many other subbasins have a "normally" placed outlet. Below I
include an example of such a situation (the subbasin is depicted in pink,
and the black dot stands for th
Jose,
could you try if r73602 makes some difference?
On Tue, Oct 23, 2018 at 8:25 AM Margherita Di Leo
wrote:
> Hi Jose,
>
> Have you checked the cases where r.basin fails? Are they all cases of
> outlet falling in isolated pixels? R.basin can’t handle those, however it’s
> important to underst
Hi Jose,
Have you checked the cases where r.basin fails? Are they all cases of
outlet falling in isolated pixels? R.basin can’t handle those, however it’s
important to understand if there are other problems. Please check a sample
of the failing cases. Try also to move the outlet of some pixels and
Thanks.
I think the same as you, that the problem arises in r.width.funct.
Unfortunately, I don't have a finer DEM for this region.
I appreciate your help.
Best regards.
Jose
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
pelempito wrote
> Thanks Helmut for your reply.
>
> Certainly having two areas is not a desirable result, but I am not sure if
> there is a problem with the DEM. One of the areas encompasses an isolated
> pixel, which in fact is the basin outlet. This polygon is connected
> diagonally with the oth
Thanks Helmut for your reply.
Certainly having two areas is not a desirable result, but I am not sure if
there is a problem with the DEM. One of the areas encompasses an isolated
pixel, which in fact is the basin outlet. This polygon is connected
diagonally with the other one, which is the main ar
pelempito wrote
> Hi.
>
> I tryed to run the r.basin addon for almost 4000 basins. Approximately 10%
> of the basins end without the .csv parameters file. Digging deeper into
> the
> command output, I spotted the following error at the end of the log from
> r.basin:
>
>
> Traceback (most recent
Hi.
I tryed to run the r.basin addon for almost 4000 basins. Approximately 10%
of the basins end without the .csv parameters file. Digging deeper into the
command output, I spotted the following error at the end of the log from
r.basin:
Traceback (most recent call last):
File "/home/jr/.grass7
Anyway I'll add some controls to let it crash more graciously whenever a
dependency is missing. Many thanks for your feedback.
On Tue, Dec 4, 2012 at 5:18 PM, kapo coulibaly wrote:
> You are right. installing the r.stream.* seems to have taken care of it.
> thanks
>
>
> On Tue, Dec 4, 2012 at 10
You are right. installing the r.stream.* seems to have taken care of it.
thanks
On Tue, Dec 4, 2012 at 10:47 AM, Margherita Di Leo wrote:
> Hi,
>
> On Tue, Dec 4, 2012 at 3:19 PM, kapo coulibaly wrote:
>
>> The command using NC data on OSGEOLive 6.0 is attached. Thanks
>> (Tue Dec 4 14:13:38
>>
Hi,
On Tue, Dec 4, 2012 at 3:19 PM, kapo coulibaly wrote:
> The command using NC data on OSGEOLive 6.0 is attached. Thanks
> (Tue Dec 4 14:13:38
> 2012)
> r.basin -a map=elevation@PERMANENT prefix=ncbasin easting=641154
> northing=222423
Thank you, I'll check it later this evening and let you
The command using NC data on OSGEOLive 6.0 is attached. Thanks
(Tue Dec 4 14:13:38
2012)
r.basin -a map=elevation@PERMANENT prefix=ncbasin easting=641154
northing=222423
SECTION 1a (of 4): Initiating Memory.
SECTION 1b (of 4): Determining Offmap Flow.
SECTION 2: A * Search.
SECTION 3: Accumulating
Hi,
On Wed, Nov 28, 2012 at 8:46 PM, kapo coulibaly wrote:
> I'm trying to run r.basin and I get the following error:
> SECTION 1a (of 4): Initiating Memory.
> SECTION 1b (of 4): Determining Offmap Flow.
> SECTION 2: A * Search.
> SECTION 3: Accumulating Surface Flow with SFD.
> SECTION 4: Closi
On Wed, 28 Nov 2012, kapo coulibaly wrote:
File "/usr/lib/grass64/etc/python/grass/script/core.py",
File "/usr/lib/python2.7/subprocess.py", line 1249, in
These are python errors. do you have core.py and subprocess.py on your
systems? I'm still running python-2.6 on my Slackware hosts so i
I'm trying to run r.basin and I get the following error:
SECTION 1a (of 4): Initiating Memory.
SECTION 1b (of 4): Determining Offmap Flow.
SECTION 2: A * Search.
SECTION 3: Accumulating Surface Flow with SFD.
SECTION 4: Closing Maps.
Writing out only positive flow accumulation values.
Cells with a
Hi,
On Tue, Nov 13, 2012 at 6:17 AM, kapo coulibaly wrote:
> inside /usr/local/grass-6.4.2/tools/g.html2man there is a file called
> g.html2man. I moved it outside and deleted the folder with the same name.
> After that r.basin installed without error. But when I try to run it get:
>
> GRASS 6.4
inside /usr/local/grass-6.4.2/tools/g.html2man there is a file called
g.html2man. I moved it outside and deleted the folder with the same name.
After that r.basin installed without error. But when I try to run it get:
GRASS 6.4.2 (test):/usr/local/grass-6.4.2/tools > r.basin
/root/.grass6/addons/r
On Mon, Nov 12, 2012 at 7:01 PM, kapo coulibaly wrote:
> I'm trying to install r.basin addon and I'm getting the following error:
> GRASS_PERL=/usr/bin/perl VERSION_NUMBER=6.4.2 sh
> /usr/local/grass-6.4.2/tools/g.html2man
> /root//test/scratch/.tmp/fmtslack64/26418.0/dist.x86_64-slackware-linux-g
I'm trying to install r.basin addon and I'm getting the following error:
GRASS_PERL=/usr/bin/perl VERSION_NUMBER=6.4.2 sh
/usr/local/grass-6.4.2/tools/g.html2man
/root//test/scratch/.tmp/fmtslack64/26418.0/dist.x86_64-slackware-linux-gnu/docs/html/r.basin.py.html
/root//test/scratch/.tmp/fmtslack64
20 matches
Mail list logo
