Oh and is there a reason why we can not put r.cva in CVS and replace r.los
with it, perhaps renaming it to r.los? I recall there being some discussion on
the list about that but can't remember the outcome. Was there some objection
from the author? IIRC r.cva fixed a few bugs in r.los as well as greatly
increasing the functionality. Had some very nice documentation too.
Paul
-------------------------------------------- Managed by Request Tracker
I can confirm that it crashes on Windows when higher values for
max_dist are used. E.g. in spearfish it is OK with max_dist=2500 but
crashes for max_dist=3000. I remember from looking in depth at r.los a
few years ago that the code was quite a mess and really inefficient
and, well, I'd rather re-write it than try to fix it.
I looked at it in the past as well and came to much the same conclusion.
(I modified it to output azimuth angle instead of elevation angle)
Oh and is there a reason why we can not put r.cva in CVS and replace
r.los with it, perhaps renaming it to r.los? I recall there being some
discussion on the list about that but can't remember the outcome. Was
there some objection from the author? IIRC r.cva fixed a few bugs in
r.los as well as greatly increasing the functionality. Had some very
nice documentation too.
AFAIK the author was in favour of this, but stuck in protracted
negotiations with his employer (a university) WRT releasing the code as
GPL or public domain. Perhaps we can help by preparing a Wiki page
highlighting contributions from other high-profile corporate entities
(e.g. USACE/CERL, Duke Univ, US EPA, Lockheed Martin, UC Berkeley, USGS,
...). For r.cva examples of other U.K. institutions gaining prestige by
contributing to well known open source projects would be good.
e.g. (sort of) http://gpsd.berlios.de/for-vendors.html
I can confirm the same problem with r.cva (based on r.los).
It crashes on Windows (cross compiled on a linux box).
I could locate the problem in the functions that were taken
from the original r.los code, so this is probably the same
bug.
It seems to me that the Win32 memory manager is more picky
than those on Unix systems. There is probably some dirty
memory allocation somewhere which does no harm but makes
the Windows mem manager choke nevertheless.
The effects of the inefficient LOS routines are multiplied
in a cumulative viewshed analysis with r.cva, resulting
in ridiculously long computation times. It's a pitty, because
r.cva is much more flexible than any other GIS viewshed module
I have ssen so far.
Oh and is there a reason why we can not put r.cva in CVS and replace r.los
with it, perhaps renaming it to r.los? I recall there being some discussion on
the list about that but can't remember the outcome. Was there some objection
from the author? IIRC r.cva fixed a few bugs in r.los as well as greatly
increasing the functionality. Had some very nice documentation too.
Paul
-------------------------------------------- Managed by Request Tracker
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany