Details Ticket 1370


Comment | Reply | Take | Resolve


Serial Number 1370
Subject r.los should show progress
Area wish
Queue grass
Requestors jidanni@dman.ddts.net
Owner none
Status open
Last User Contact Thu Nov 28 09:02:08 2002 (6 yr ago)
Current Priority 20
Final Priority 70
Due No date assigned
Last Action Fri Nov 29 03:49:12 2002 (6 yr ago)
Created Tue Oct 22 23:49:06 2002 (6 yr ago)

Transaction History Ticket 1370


Tue, Oct 22 2002 23:49:06    Request created by guest  
Subject: r.los should show progress

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.0pre1

Because r.los takes such a long time for large areas,
it should send out occasional progress reports to the
screen so we know it is not stuck in a loop, etc.

For instance, d.rast makes many messages to the screen while
drawing, even thouht it just takes seconds.  Why not a few
messges from r.los?
Mon, Nov 25 2002 10:58:53    Mail sent by guest  
> Because r.los takes such a long time for large areas,
> it should send out occasional progress reports to the
> screen so we know it is not stuck in a loop, etc.


It does:
Line 301 of main.c from GRASS 5.0.0 (or close to):

for(segment_no=1;segment_no<=16;segment_no++){
	G_percent(segment_no, 16, 5);

So it does spit out a % done. (and do I see it when running r.los)

BUT that G_percent should be at the end of the for loop not the beginning. The
first thing it does it say 6% done, and after it reports 100% you still have
to wait a long time for the 16th iteration to run ... it should be moved to
line 339.

I don't know if G_percent's can be meaningfully placed in segment.c to run for
each of the 16 segments..?


NB: r.los computational time seems to go up much much faster than just by the
number of cells. 500x500 cells seems to get along pretty well (~13min on a
PIII 550mHz, 20% screen 'dark' by los), while 707x707 might have to run
overnight. I'll let you know how that goes.
I modified my r.los to do other things, so my times may or may not be typical.
NB2: setting a MASK seems to have no effect on this module! bummer.


r.cva seems to use a few sub-sampling strategies and multiple masks to work
around this problem.
http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html



Hamish
ihatejunkyabastards at yahoo dot com
Wed, Nov 27 2002 19:07:03    Mail sent by jidanni@dman.ddts.net  
Return-Path <jidanni@dman.ddts.net>
Delivered-To grass-bugs@lists.intevation.de
To guest user via RT <grass-bugs@intevation.de>
Cc mark.lake@ucl.ac.uk, ihatejunkyabastards@yahoo.com
Subject Re: [bug #1370] (grass) r.los
References <20021125095854.630BE13A19@lists.intevation.de>
In-Reply-To <20021125095854.630BE13A19@lists.intevation.de>
From Dan Jacobson <jidanni@dman.ddts.net>
User-Agent Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Date 28 Nov 2002 02:03:52 +0800
Message-ID <87smxm99fb.fsf@jidanni.org>
Lines 36
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Spam-Status No, hits=-2.6 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43
X-Spam-Level
>> Because r.los takes such a long time for large areas,
>> it should send out occasional progress reports to the
>> screen so we know it is not stuck in a loop, etc.

RT> It does:
RT> Line 301 of main.c from GRASS 5.0.0 (or close to):
Oh, I was using "pre1"

RT> NB: r.los computational time seems to go up much much faster than just by
the
RT> number of cells.

and pie slice shaped patt_maps dont help.  it seems rlos and r.cva
should accept a parameter azimuth_ranges=11-33,45-66,... to quickly
specify what part of the horizon one is interested in.  Seems as
important as max_dist.

RT> r.cva seems to use a few sub-sampling strategies and multiple masks to work
RT> around this problem.
RT> http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html

on his man page it says
AUTHOR
Mark Lake, Institute of Archaeology, University College London.
so one has to look hard to find mark.lake@ucl.ac.uk on his website...

RT> Hamish
RT> ihatejunkyabastards at yahoo dot com

Anyway, as I run debian, and compiling grass 5.0.0 proved beyond me, I will
wait for the .deb, but unless r.cva is included, I bet one will not be
able to easily add new parts on their own, without the same problems
of compiling the whole grass... shame: premier free GIS hard to
install on premier free OS distribution.  Also as a '56k' modem user,
no fun doing trial and error...
-- 
http://jidanni.org/ Taiwan(04)25854780


Thu, Nov 28 2002 09:02:08    Mail sent by guest  
> and pie slice shaped patt_maps dont help.  it seems rlos and r.cva
> should accept a parameter azimuth_ranges=11-33,45-66,... to quickly
> specify what part of the horizon one is interested in.  Seems as
> important as max_dist.

Lines 309, 310 (or nearby) of the Grass 5.0.0 version of r.los:

/*
DO LOS ANALYSIS FOR SIXTEEN SEGMENTS		*/
for(segment_no=1;segment_no<=16;segment_no++){

where segments are 22.5 degree wedges. As far as I can tell, segment 1 runs
from 270-292.5 degrees (just north of west), segment 5 runs from 0 to 22.5
degrees (just E of N), etc., on to segment 16 which runs from 247.5 to 270
degrees. I could be wildy mistaken though.

So you could easily limit the search to segments 5 through 7 if you were only
interested in 11-66 degrees by editing the for-statement to be
for(segment_no=5; segment_no<=7; segment_no++){

and maybe the same for the second loop somewhere around line 349, and
recompile with gmake5. (and install the new module)


This certainly isn't a proper solution, and there is a good chance it will
break r.los, but it might help you with your problem.

If it does work, with a little front end work it might be possible to add a
command line option to do what you wish: only search active segments.



> Anyway, as I run debian, and compiling grass 5.0.0 proved beyond me,
> I will wait for the .deb,

FYI:
For the debian package of 5.0pre4, see http://packages.debian.org/grass

For more about fetching the .debs from testing if you run stable, see:
http://op.gfz-potsdam.de/GRASS-List/Archive/msg07267.html


For some notes on compiling GRASS for debian, see:
http://bambi.otago.ac.nz/public/general/grass/compile_reqs_debian.txt
and
http://bambi.otago.ac.nz/public/general/grass/compile_5.0.0_debian.txt

Read the INSTALL file in the source package and search the grass mailing list
for 'debian' ... the process really isn't hard at all once you get the
./configure line right and have all the required packages. Figuring that out
is the hard part. (and is spelled out in the above links to bambi.otago.ac.nz)
g'luck,
Hamish
ihatejunkyabastards at yahoo dot com
Fri, Nov 29 2002 03:49:12    Mail sent by jidanni@dman.ddts.net  
Return-Path <jidanni@dman.ddts.net>
Delivered-To grass-bugs@lists.intevation.de
To guest user via RT <grass-bugs@intevation.de>
Subject Re: [bug #1370] (grass) Transaction (guest)
References <20021128080208.D8AF213A19@lists.intevation.de>
In-Reply-To <20021128080208.D8AF213A19@lists.intevation.de>
From Dan Jacobson <jidanni@dman.ddts.net>
Date 29 Nov 2002 07:49:06 +0800
Message-ID <87fztl8dcd.fsf@jidanni.org>
Lines 26
User-Agent Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Spam-Status No, hits=-3.1 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_GNUS_UA version=2.43
X-Spam-Level
>> and pie slice shaped patt_maps dont help.  it seems rlos and r.cva
>> should accept a parameter azimuth_ranges=11-33,45-66,... to quickly
>> specify what part of the horizon one is interested in.  Seems as
>> important as max_dist.

H> Lines 309, 310 (or nearby) of the Grass 5.0.0 version of r.los:

H> /*
H> DO LOS ANALYSIS FOR SIXTEEN SEGMENTS		*/
H> for(segment_no=1;segment_no<=16;segment_no++){

H> where segments are 22.5 degree wedges [.]it might be possible to
H> add a command line option to do what you wish: only search active
H> segments.

i didn't look at the source, but as the program probably would take
several days to run if one doesn't restrict anything [uses 99999 meter
diameter, etc.], then allowing control to which segments are run from
the command line seems only fair.  Also perhaps allow custom segment
sizes.

Indeed, "if it let me choose just segment 5, then I wouldn't have to
make patt_map, which was in fact the same shape as segment 5, but
didn't cause the program to speed up."
-- 
http://jidanni.org/ Taiwan(04)25854780


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request