On Thu, Apr 23, 2015 at 02:36:35PM +0200, Even Rouault wrote:
> Most gdaldem algorithms (except color-relief) need to compute some form of
> gradient (a 3x3 window around the pixel being computed), so you have edge
> effects. By default, they put a nodata value on the edges.
> If you specify -com
...or rasdaman, www.rasdaman.org. It allows to establish a single seamless map
on which you can run algorithms in a high-level language. The system takes care
of borders etc. Prefab VM is available on request (production not yet
automated).
my 2 cents,
Peter
On 04/23/15 15:03, Rémi Cura wrote:
>
Hey,
gdal may not be the right tool for this.
You may use Orfeo Tool Box (https://www.orfeo-toolbox.org/),
which has been designed to process huge images with limited cpu and memory.
Cheers,
Rémi-C
2015-04-23 14:36 GMT+02:00 Even Rouault :
> Le jeudi 23 avril 2015 14:22:30, Paul Ramsey a écrit
Le jeudi 23 avril 2015 14:22:30, Paul Ramsey a écrit :
> I have in the past, with other tool sets, not GDAL, approached this by
> building out padded tiles as the first step. So for each tile, merge it
> with it’s neighbors, then clip out the middle so you get a somewhat larger
> tile. Give it a ni
I have in the past, with other tool sets, not GDAL, approached this by building
out padded tiles as the first step. So for each tile, merge it with it’s
neighbors, then clip out the middle so you get a somewhat larger tile. Give it
a nice thick buffer.
Now all your tiles overlap. Process them a
I have SRTM's DEM 1x1 degree 30m resolution tiles for the whole Europe and
I'm trying to generate several raster images based on
that (elevation coloring, slopeshade and hillshade), but I'm not sure about the
right approach to do it for that amount of data.
The simplest approach is to
