On Jul 9, 2008, at 2:11 PM, Will wrote:
Hi Paul (and the rest of the GRASS dev list),
On Wed, Jul 9, 2008 at 12:11 PM, Paul Kelly <paul-
[EMAIL PROTECTED]> wrote:
Hello Will,
On Wed, 9 Jul 2008, Will wrote:
Hi Paul,
That all sounds good. I'll move r.terraflow and r.viewshed (I
decided to
take up the r.viewshed name) into that iostream directory that you
mentioned. Otherwise though, the code is working and ready to use.
That's great! I'm sure I can speak for the other developers in
saying that we're very grateful that you continued to work on this
even without the Google funding.
I am having a great time doing this work; I am funded from an
NSF grant that Laura has. Hopefully I'll be able to get funding
from Google next summer and contine working with GRASS.
Hi Will, it is really great that you are working on this -
the time improvement looks impressive.
You already got some answers to your questions, I have
one regarding the max distance - see below
I just have a couple of questions about details of the output.
Firstly, r.los has a lot of options, suchas observer elevation,
curviture of
the earth, and max distance to look at. Do you still want all or
some of
those in r.viewshed?
Max distance is IMHO only a requirement because of the extreme
inefficiency of r.los, where limiting the calculation to a circular
sub-region can reduce the running time significantly. I think if
r.viewshed performs well enough, it should be fine to leave it
calculating the viewshed over the whole of the current region.
max distance parameter is handy when you have limited visibility e.g.
due to smog, fog
or other atmospheric phenomena. It is also useful when planning
mapping e.g. with 3D
scanner that can measure only limited distance - e.g. 100m or 500m
the more expensive ones -
and you want to find the minimum number of locations from which to
get entire area mapped.
Of course, you can post process the visibility map to cut out just
the desired distance,
but it would be convenient to have it as output option.
Helena
I agree that max distance was only really necessary since r.los is
so inefficient, and r.viewshed is fast enough to do whole maps
quickly. Just to give a benchmark, a map that has ~1 million cells
takes r.los ~30 min on the machines we have here (Dual 2.5 GHz PPC
processors, 1 GB RAM). It takes r.viewshed ~1.6 seconds.
Observer elevation is a useful shortcut to have and especially
relevant for radio masts etc. Do you have a default observer
elevation in r.viewshed?
Observer elevation will not be too hard to implement, so I can put
it in. As of right now, the default observer elevation for
r.viewshed is ground level. For r.los, the default value is 1.75-
does anyone on the list have an opinion on if I should make 1.75
the default for r.viewshed, or if it should be a different value?
Earth curvature calculation would seem to be important when
covering a very large area, but I imagine it is not the simplest
thing to add so it may not be necessary immediately. I must confess
I have no idea how much of a difference it makes to the
calculation, nor what is the threshold when it starts to become an
important consideration. Perhaps someone else on the list can comment.
Looking at the r.los code, it doesn't seem to be too hard to put in
curvature, though like you I have no idea what effect it has or at
what threshold it becomes important.
It is done exactly the way you mentioned in the other email,
finding the radius of the elipsoid and reducing the elevatin of the
cell that you are looking at depending on the distance it is away
from the viewpoint. The way r.los does it is they have a flag that
you set if you want the curvature to be considered, though I can
impliment it for all calculations without a flag if we think that
will be better- any input from the list on this?
Secondly, r.los outputs a map that sets the value of each visible
point to
the vertical angle (in degrees) required to see those cells. Do
you want
this for r.viewshed, or something else? Right now, I just have it
output
the elevation of the visible points, but that can always change.
Perhaps there could be multiple output options, e.g. (a) elevation
of visible cell, (b) difference in elevation between observer and
visible cell, (c) angle between observer and visible cell... I'm
not sure on this though and again perhaps someone else has an opinion.
Whatever we think is best for the output, I will do, whether we
decide on one output format or multiple.
As soon as those issues are sorted out, I think its all done.
-Will
P.S. I can post this all to the mailing list if you want me to.
Laura Toma
has told me that I need to be approved or something like that to
post, and I
was wondering what I need to do to get approved.
You only need to be a subscribed, and I just checked and you are
already subscribed so all you should need to do is send a mail to
[EMAIL PROTECTED] I've copied this mail to the grass-dev
list already, so you can just reply to it to follow-up.
Paul
--
-Will
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
