<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hey,<br></div><div class="gmail_default" style="font-family:monospace,monospace">gdal may not be the right tool for this.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">You may use Orfeo Tool Box (<a href="https://www.orfeo-toolbox.org/">https://www.orfeo-toolbox.org/</a>), <br></div><div class="gmail_default" style="font-family:monospace,monospace">which has been designed to process huge images with limited cpu and memory.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">Cheers,<br></div><div class="gmail_default" style="font-family:monospace,monospace">Rémi-C<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-23 14:36 GMT+02:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le jeudi 23 avril 2015 14:22:30, Paul Ramsey a écrit :<br>
> I have in the past, with other tool sets, not GDAL, approached this by<br>
> building out padded tiles as the first step. So for each tile, merge it<br>
> with it’s neighbors, then clip out the middle so you get a somewhat larger<br>
> tile. Give it a nice thick buffer.<br>
><br>
> Now all your tiles overlap. Process them all individually. Thanks to the<br>
> generous overlap they should, on the boundaries, come up w/ the same<br>
> answers. Once you have final results (hillshades, contours, etc) clip them<br>
> to the real tile boundary. In the case of contours you may need to finally<br>
> snap the ends together, but it should not be a huge snap, just a tiny one.<br>
><br>
<br>
</span>+1 for Paul's above workflow. Some answers to your questions below<br>
<span class=""><br>
> --<br>
> <a href="http://postgis.net" target="_blank">http://postgis.net</a><br>
> <a href="http://cleverelephant.ca" target="_blank">http://cleverelephant.ca</a><br>
><br>
> On April 23, 2015 at 3:01:45 AM, Marcos Dione (<a href="mailto:mdione@grulic.org.ar">mdione@grulic.org.ar</a>) wrote:<br>
> > I have SRTM's DEM 1x1 degree 30m resolution tiles for the whole Europe<br>
> > and I'm trying to generate several raster images based on<br>
> > that (elevation coloring, slopeshade and hillshade), but I'm not sure<br>
> > about the right approach to do it for that amount of data.<br>
> ><br>
> > The simplest approach is to stitch the DEMs and then process, but that<br>
> > takes ages, specially if I try to use uncompressed, tiled<br>
> > GeoTIFFs as output. The stitching can even be done using a virtual file,<br>
> > which saves space.<br>
> ><br>
> > If I process each tile individually, and then build a virtual file on<br>
> > top, I get shades on the edges of tiles. This shade is due<br>
> > to the tile ending and the shading algorithm assuming there's a 0<br>
> > elevation point right to it. So, question A) is that so?<br>
<br>
</span>Most gdaldem algorithms (except color-relief) need to compute some form of<br>
gradient (a 3x3 window around the pixel being computed), so you have edge<br>
effects. By default, they put a nodata value on the edges.<br>
If you specify -compute_edges, then they will interpolate extra values from<br>
the ones available so that the edge pixels can be computed. You could still<br>
see some discontinuity if the prediction isn't that great.<br>
<span class=""><br>
> ><br>
> > I think that getting the shade in the output is due to the algorithm for<br>
> > finding a pixel uses the first tile that has it.<br>
> > Question B) is that so?<br>
> ><br>
> > If so, C) could I simply avoid this by generating another vrt file that<br>
> > lists each tile as having a bbox of only the 1x1 degree<br>
> > instead of the 1x1 degree plus an extra pixel border? If I get the time,<br>
> > I'll try this this afternoon (I just thought of it).<br>
<br>
</span>For each tile, you could have a VRT of 3x3 tiles. Let's say that a tile if NxN<br>
pixel, then the VRT would be (N+2)*(N+2). And you would extract NxN pixels<br>
from the output of gdaldem on that VRT, keeping NxN pixels only. Well, this is<br>
basically Paul's approach using VRT to do the buffer.<br>
<div class="HOEnZb"><div class="h5"><br>
> ><br>
> > All this I can do more or less with the gdal command line tools, without<br>
> > much programming. Then comes a more programmatic way:<br>
> > either use gdaldem or use the GDAL API to process each tile, then cut the<br>
> > 1x1 degree image and save that; then stitch them/build a<br>
> > vrt file on top. As you can see, this is what I've been avoiding to do :)<br>
> ><br>
> > Finally, I would also like to generate contour lines for this. So far I<br>
> > managed to generate them for 5x5 tiles with 90m<br>
> > resolution, then I import them in postgis. When I render them, on the<br>
> > edges of such tiles I see the lines from one crossing the<br>
> > others, looking ugly. For instance:<br>
> ><br>
> > <a href="http://grulicueva.homenet.org/~mdione/Elevation/#14/45.0000/15.0000" target="_blank">http://grulicueva.homenet.org/~mdione/Elevation/#14/45.0000/15.0000</a><br>
> ><br>
> > I tried used a stitched file for the whole region but I ran out of memory<br>
> > with gdal_contour. Again, this was with 90m resolution<br>
> > tiles; now I have 30m, which means 9 times as much data. D) How could I<br>
> > properly process all that?<br>
> ><br>
> > Thanks in advance for any ideas,<br>
> ><br>
> > -- Marcos.<br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br></div>