<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi Jukka, David and others,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
We were rendering in the past the elevation data into Mercator tiles with <a href="http://www.maptiler.com/" target="_blank">http://www.maptiler.com/</a>, the follower of my GDAL2Tiles.py script - for extremely fast pixel access to the elevation values at given geographic location - without a need for server software for hosting such data. We made the tiles for CGIAR 90m DEM for whole world.<br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>In fact the raw elevation was mapped into RGB space for this purpose. Decoding on the client side is then very easy and you have precise elevation values for the whole near area preloaded.</div>
<div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px"><div>You may need to do something similar if you want to implement very fast client side hill-shading in web browser canvas (similar to <a href="http://dev.klokantech.com/klokan/hillshading/" target="_blank">http://dev.klokantech.com/klokan/hillshading/</a>), or dynamic elevation profile drawn while moving the mouse over a map, and many other tasks with data loaded in the client directly. </div>
<div><br></div><div><div>The visualisation of the tiles is possible also in 3D, see: <a href="http://vimeo.com/29605292" target="_blank">http://vimeo.com/29605292</a></div><div>For WebGL there are now more efficient ways (direct binary data structures instead of images).<br>
</div></div><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">See:</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="http://dev.klokantech.com/srtm/srtm_decode.html" target="_blank">http://dev.klokantech.com/srtm/srtm_decode.html</a><br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="http://www.klokantech.com/labs/dem-color-encoding/" target="_blank">http://www.klokantech.com/labs/dem-color-encoding/</a><br></div><div style="font-family:arial,sans-serif;font-size:13px">
<a href="http://dev.klokantech.com/srtm/googlemaps.html" target="_blank">http://dev.klokantech.com/srtm/googlemaps.html</a><br></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
There is a source code of the GDAL utility for encoding elevation data into RGB available online:</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://github.com/webglearth/gdaldem_web" target="_blank">https://github.com/webglearth/gdaldem_web</a></div>
<div style="font-family:arial,sans-serif;font-size:13px">but you may not need it, if direct reading via JavaScript in the web browser is not required for your application.<br></div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">Regards,<br></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Klokan Petr Pridal</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 7:48 PM, David Baker (Geoscience) <span dir="ltr"><<a href="mailto:david.m.baker@chk.com" target="_blank">david.m.baker@chk.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jukka,<br>
<br>
No matter the endpoint the user uses to access the data, behind the scenes, there must be fast pixel access, correct?  Or are you saying that at WFS would do it quickly out of the box?<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="im HOEnZb"><br>
-----Original Message-----<br>
From: <a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:gdal-dev-bounces@lists.osgeo.org">gdal-dev-bounces@lists.osgeo.org</a>] On Behalf Of Rahkonen Jukka (Tike)<br>

Sent: Monday, February 03, 2014 11:37 AM<br>
To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
Subject: Re: [gdal-dev] Fast Pixel Access<br>
<br>
</div><div class="HOEnZb"><div class="h5">Hi,<br>
<br>
Perhaps, but in this game the rule was not to have any GIS servers. Myself I would rather consider WFS. It could send heights from single points but also a profile along a line or all values within a polygon.<br>
<br>
-Jukka-<br>
<br>
Brian Case [<a href="mailto:rush@winkey.org">rush@winkey.org</a>] wrote:<br>
<br>
> -Jukka<br>
<br>
> tileindex, mapserver, and the gdal wms driver<br>
<br>
<br>
<br>
> On Mon, 2014-02-03 at 17:20 +0000, Jukka Rahkonen wrote:<br>
>> Luke Roth <roth.luke <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
><br>
> ><br>
>> > Another thing that might speed up access is setting the config<br>
>> option GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment<br>
>> variable or on the command line.  That should help with GDAL reading the<br>
>> directory each time it opens a dataset.  I have an application which reads<br>
>> one value from each of a large number of datasets and setting this option<br>
>> made it run about 3 times faster.<br>
><br>
><br>
> Hi,<br>
><br>
> You are right. This config option makes GDAL to skip the reading of the<br>
> remote directory and saves a lot of bandwidth:<br>
><br>
> VRT case:<br>
> Bytes Received:  4 244 509 (of which the vrt file: 4 192 577)<br>
> Sequence (clock) duration:    00:00:09.9996000<br>
> Was:<br>
> Bytes Received:  6 459 443<br>
> Sequence (clock) duration:    00:00:37.8130000<br>
><br>
> BigTIFF case:<br>
> Bytes Received:  2 158 917<br>
> Sequence (clock) duration:    00:00:04.4368000<br>
> Was:<br>
> Bytes Received:  4 374 137<br>
> Sequence (clock) duration:    00:00:30.9192000<br>
><br>
><br>
> Conclusion:<br>
> Both options are unsuitable for serious use while amusing to play with.<br>
> Reading the BigTIFF tile offset index (or whatever it is) seems to mean<br>
> about 2 MB of compultory payload traffic. Reading the VRT file means in this<br>
> example 4 MB of payload. If this sort of net access to a large directory of<br>
> raster files should be important for someone there should be a way to find<br>
> the right raster file and righ data range in that file with minimum amount<br>
> of bytes. Perhaps some kind of rtree indexed vrt file? First aid might be to<br>
> keep the vrt file on the client side.<br>
><br>
> -Jukka Rahkonen-<br>
><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>
<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><div class="im HOEnZb">________________________________<br>
<br>
This email (and attachments if any) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is confidential or privileged and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email and destroy all copies of the email (and attachments if any).<br>

</div><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><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://blog.klokan.cz/" target="_blank">http://blog.klokan.cz/</a><br><a href="http://www.maptiler.org/" target="_blank">http://www.maptiler.org/</a><br>
<a href="http://www.oldmapsonline.org/" target="_blank">http://www.oldmapsonline.org/</a>
</div>