[GRASS-user] GRASS & earth curvature correction (viewsheds, LOS)

Hm-hm. Citing from the website:
"The problem is that the ratio of change due to air to curvature is
not 1:7 (0.13), as the standard refraction coefficient suggests. It is
0.325.

As far as I can tell, this is a mis-understanding. The value "0.325"
applies to radio waves. Visible light is very close to 1:7.
You can read up on the arguments here:

http://forums.esri.com/Thread.asp?c=3&f=40&t=161962#474778

There is also some more information in that forum thread
regarding more realistic modelling of refraction under
different atmospheric conditions.

I realize the whole discourse is somewhat "clouded". But I don't
have access to most of the relevant literature for the time
being, nor do I have the necessary scientific background
-- so any fresh input will be much appreciated!

Btw.: using r.ecurv.comp, one can freely specify the
atmospheric correction factor.

[...]
>
>> But given that most DEMs have an inherent vertical error that
>> is greater than the influence of these effects,
>
> can we quantify that? for example what's STRM 95% confidence
> accuracy?

From Farr et al. 2007:

Summary of SRTM performance. All quantities represent 90% errors in
meters.

Africa Australia Eurasia Islands N. America S. America
Absolute Geolocation Error 11.9 7.2 8.8 9 12.6 9
Absolute Height Error 5.6 6 6.2 8 9 6.2
Relative Height Error 9.8 4.7 8.7 6.2 7 5.5
Long Wavelength Height Error 3.1 6 2.6 3.7 4 4.9

[sorry for the ugly format, it's tab separated]

What I wold love to see is a method for probabilistic
viewsheds, which adds random +/- offsets (within the
vertical error range) to the elevation model cells,
runs the viewshed computations several times, each time
with new random offsets, then outputs the average visibility
of each cell after "n" runs (not sure how best to determine
"n"). That would be much more realistic than those over-
confident 0/1 viewsheds.

Such a method could even take into account roughly modelled
blocks of vegetation or other obstacles for which height
is hard to quantify precisely.

-- shouldn't be too hard to implement in a little script.

Ben

>
>> I am not sure it's worth spending too much time on (it might
>> be for very long distance visibility -- I just don't know).
>
> it would be good for us to do a rough back of the envelope calc
> to justify that before fully forgetting about it.
>
> I guess for the worst case scenario we could try the views from
> Mt. Everest and/or Olympus Mons and see what difference it makes.

No need to go into mountains, just increase observer elevation offset,
preferably in a moderately flat area to get really far views. Using
correction for earth curvature only, max is a bit more than 100 km
with 3km observation offset. 200km is impossible without leaving
earth's atmosphere.

Markus M

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

On Thu, May 26, 2011 at 12:26 PM, Benjamin Ducke
<benjamin.ducke@oxfordarch.co.uk> wrote:

Hm-hm. Citing from the website:
"The problem is that the ratio of change due to air to curvature is
not 1:7 (0.13), as the standard refraction coefficient suggests. It is
0.325.

As far as I can tell, this is a mis-understanding. The value "0.325"
applies to radio waves. Visible light is very close to 1:7.

What if I am interested in radio waves, not visible light, e.g. for
antenna relay positions? IMHO, that refraction coefficient should not
be hard-coded.

I realize the whole discourse is somewhat "clouded". But I don't
have access to most of the relevant literature for the time
being, nor do I have the necessary scientific background

Me neither. But any correction should take into account that the
observer is not necessarily a human without optical equipment
(telescope etc), but can also be some technical device, e.g. a sender
or receiver of whatever signals.

my .2c

Markus M

-- so any fresh input will be much appreciated!

Btw.: using r.ecurv.comp, one can freely specify the
atmospheric correction factor.

[...]
>
>> But given that most DEMs have an inherent vertical error that
>> is greater than the influence of these effects,
>
> can we quantify that? for example what's STRM 95% confidence
> accuracy?

From Farr et al. 2007:

Summary of SRTM performance. All quantities represent 90% errors in
meters.

Africa Australia Eurasia Islands N. America S. America
Absolute Geolocation Error 11.9 7.2 8.8 9 12.6 9
Absolute Height Error 5.6 6 6.2 8 9 6.2
Relative Height Error 9.8 4.7 8.7 6.2 7 5.5
Long Wavelength Height Error 3.1 6 2.6 3.7 4 4.9

[sorry for the ugly format, it's tab separated]

What I wold love to see is a method for probabilistic
viewsheds, which adds random +/- offsets (within the
vertical error range) to the elevation model cells,
runs the viewshed computations several times, each time
with new random offsets, then outputs the average visibility
of each cell after "n" runs (not sure how best to determine
"n"). That would be much more realistic than those over-
confident 0/1 viewsheds.

Such a method could even take into account roughly modelled
blocks of vegetation or other obstacles for which height
is hard to quantify precisely.

-- shouldn't be too hard to implement in a little script.

Ben

>
>> I am not sure it's worth spending too much time on (it might
>> be for very long distance visibility -- I just don't know).
>
> it would be good for us to do a rough back of the envelope calc
> to justify that before fully forgetting about it.
>
> I guess for the worst case scenario we could try the views from
> Mt. Everest and/or Olympus Mons and see what difference it makes.

No need to go into mountains, just increase observer elevation offset,
preferably in a moderately flat area to get really far views. Using
correction for earth curvature only, max is a bit more than 100 km
with 3km observation offset. 200km is impossible without leaving
earth's atmosphere.

Markus M

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

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