On Thu, May 26, 2011 at 12:26 PM, Benjamin Ducke <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
