Doug wrote:
I appreciate the effort.
(me too :)
Working with large rasters, this will make a big difference!
with respect to r.hozion, I'm still trying to understand where
the best use case for it is.
the idea as I understand it (which is not completely) is that
it precomutes some of what
It's been a while, but I think one motivating factor is the limiting GPU RAM.
If we can't fit everything on the GPU, then it needs to be tiled. The only way
to accurately tile is to make each tile independent of its surroundings. This
can be done arbitrarily small with pre computed horizons.
I
Seth,
I appreciate the effort. Working with large rasters, this will make a big
difference!
Doug
On Sun, Feb 10, 2013 at 9:18 PM, Seth Price s...@pricepages.org wrote:
They should. I didn't really make any changes to the calculations, I just
rearranged the code to make it more processor
They should. I didn't really make any changes to the calculations, I just
rearranged the code to make it more processor and compiler friendly.
~Seth
via iPhone
On Feb 9, 2013, at 3:27 PM, Newcomb, Doug doug_newc...@fws.gov wrote:
Seth,
I finally got a chance to patch your enhancements from
Seth,
I finally got a chance to patch your enhancements from the GRASS 70 svn
code I pulled last night.
I compiled with these options:
./configure --with-gdal --with-freetype
--with-freetype-includes=/usr/include/freetype2 --with-proj --with-sqlite
--enable-largefile --with-cxx --enable-64bit
A while ago I made some simple, but significant, enhancements and submitted
them to trac. They haven't been picked up, so I wanted to point them out so
someone can commit them before they diverge from the trunk.
http://trac.osgeo.org/grass/ticket/1624
This has had some activity recently, but
