[GRASS-dev] Re: Line of Sight Update

GRASS GRASS developer
1

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 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.

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?

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.

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.

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 grass-dev@lists.osgeo.org. I've copied this mail to the grass-dev list already, so you can just reply to it to follow-up.

Paul

2

Hi Paul (and the rest of the GRASS dev list),

On Wed, Jul 9, 2008 at 12:11 PM, Paul Kelly <paul-grass@stjohnspoint.co.uk> 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.

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.

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 grass-dev@lists.osgeo.org. I’ve copied this mail to the grass-dev list already, so you can just reply to it to follow-up.

Paul

–
-Will

3

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-grass@stjohnspoint.co.uk> 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 grass-dev@lists.osgeo.org. 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

4

Sorry for the late reply to this -- too caught up in other things
at the moment.

Earth curvature correction and other generic issues involved in LOS
application design are detailed nicely here:

http://www.scs.org/PUBs/jdms/vol1num1/article04.pdf

The article talks about using an approximation instead of a precise
correction, which should be good enough in most cases and kick in
beyond a range of ca. 3 kilometers.

A redesign of the GRASS LOS tool is certainly a great thing. Would be
good to try and keep the actual LOS core nice and simply and cleanly separated from the other program logics.

That way, we can later easily build up on this and add things like
cumulative visibility, probabilistic viewsheds and visiblity fall-off
curves to account for things like atmospheric effects.

Cheers,

Ben

Paul Kelly 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 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.

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?

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.

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.

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 grass-dev@lists.osgeo.org. I've copied this mail to the grass-dev list already, so you can just reply to it to follow-up.

Paul
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

5

Hi Will,

On Wed, Jul 9, 2008 at 8:11 PM, Will <willster3021@gmail.com> wrote:

On Wed, Jul 9, 2008 at 12:11 PM, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Wed, 9 Jul 2008, Will wrote:

...

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.

this is great and much appreciated!

...

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?

Since it is rather arbitrary, please keep it for backward compatibility.

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 important - please, if not too hard (I ported it from r.cva to
r.los, wasn't
so hard) add it. It makes a difference... I have an ongoing "batlle" with
an ex colleague if we can see the sea from our mountain here or not,
r.los and his algorithm do not agree. :slight_smile:

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?

I would keep the flag if there aren't too many.

Benjamin provided a useful link in his mail.

Markus

6

Markus Neteler wrote:

It is important - please, if not too hard (I ported it from r.cva to
r.los, wasn't
so hard) add it. It makes a difference... I have an ongoing "batlle" with
an ex colleague if we can see the sea from our mountain here or not,
r.los and his algorithm do not agree. :slight_smile:

Interesting, I remember putting that into r.cva years ago (I used the
approximation in the paper I mailed about before), but never really
had any time to test it very well (which is why I marked it as
untested in the HTML page for r.cva).

Does it produce plausible results with your data?

Curious,

Ben

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

7

On Wed, 23 Jul 2008, Markus Neteler wrote:

On Wed, Jul 9, 2008 at 8:11 PM, Will <willster3021@gmail.com> wrote:

[...]

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?

I would keep the flag if there aren't too many.

Yes, agreed it should be optional - someone might want to use the module in an XY environment without large-scale real-world considerations such as earth curvature.

Paul

8

All of that is already in place and working. (Well, I don’t know if curvature is working - all the data I have here is in the wrong projection to work with curvature, but i ported the code from r.los, so hopefully it should work as expected) Right now, I’m having some issues with it determining correctly which mode it should be in (internal memory, external memory, or a variant of external memory where we distribute sectors) but I have been running a lot of tests, and hopefully this will be one of the last bugs to work out.

  • Will

On Wed, Jul 23, 2008 at 6:35 AM, Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Wed, 23 Jul 2008, Markus Neteler wrote:

On Wed, Jul 9, 2008 at 8:11 PM, Will <willster3021@gmail.com> wrote:

[…]

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?

I would keep the flag if there aren’t too many.

Yes, agreed it should be optional - someone might want to use the module in an XY environment without large-scale real-world considerations such as earth curvature.

Paul

–
-Will

9

On Wed, Jul 23, 2008 at 12:21 PM, Benjamin Ducke
<benjamin.ducke@oxfordarch.co.uk> wrote:

Markus Neteler wrote:

It is important - please, if not too hard (I ported it from r.cva to
r.los, wasn't
so hard) add it. It makes a difference... I have an ongoing "batlle" with
an ex colleague if we can see the sea from our mountain here or not,
r.los and his algorithm do not agree. :slight_smile:

Interesting, I remember putting that into r.cva years ago (I used the
approximation in the paper I mailed about before), but never really
had any time to test it very well (which is why I marked it as
untested in the HTML page for r.cva).

Does it produce plausible results with your data?

Good question:
http://www.grassbook.org/neteler/tmp/

- r.los from two adjacent mountain peaks (LAEA projection, SRTM 250m)
- "marmota" [1] algorithm from one of the peaks (the viewshed I don't
have, LatLong,
    SRTM 250m)

Additionally:
- "Sitting" in Google Earth on Monte Bondone does *not* show the sea
   near Venice (but they use a sphere). If I increase the flight height a bit,
   I see the sea...

It's rather complicated (for me).

Markus

[1] http://tev.fbk.eu/TeV/Research/vem.html <- very cool