<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
...or rasdaman, <a class="moz-txt-link-abbreviated" href="http://www.rasdaman.org">www.rasdaman.org</a>. 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).<br>
my 2 cents,<br>
Peter<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/23/15 15:03, Rémi Cura wrote:<br>
</div>
<blockquote
cite="mid:CAJvUf_ub560zibPWe2U-DwVZ7gwAMkuWJeiHLVPEyotWe+mSuQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" href="http://postgis.net"
target="_blank">http://postgis.net</a><br>
> <a moz-do-not-send="true"
href="http://cleverelephant.ca" target="_blank">http://cleverelephant.ca</a><br>
><br>
> On April 23, 2015 at 3:01:45 AM, Marcos Dione (<a
moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://grulicueva.homenet.org/%7Emdione/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 moz-do-not-send="true"
href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="80">--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
<a class="moz-txt-link-abbreviated" href="http://www.faculty.jacobs-university.de/pbaumann">www.faculty.jacobs-university.de/pbaumann</a>
mail: <a class="moz-txt-link-abbreviated" href="mailto:p.baumann@jacobs-university.de">p.baumann@jacobs-university.de</a>
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
<a class="moz-txt-link-abbreviated" href="http://www.rasdaman.com">www.rasdaman.com</a>, mail: <a class="moz-txt-link-abbreviated" href="mailto:baumann@rasdaman.com">baumann@rasdaman.com</a>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
</pre>
</body>
</html>