[gdal-dev] Fast Pixel Access

Mon Feb 3 11:37:35 PST 2014

Hi Jukka, David and others,

We were rendering in the past the elevation data into Mercator tiles with
http://www.maptiler.com/, 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.

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.

You may need to do something similar if you want to implement very fast
client side hill-shading in web browser canvas (similar to
http://dev.klokantech.com/klokan/hillshading/), or dynamic elevation
profile drawn while moving the mouse over a map, and many other tasks with
data loaded in the client directly.

The visualisation of the tiles is possible also in 3D, see:
http://vimeo.com/29605292
For WebGL there are now more efficient ways (direct binary data structures
instead of images).

See:
http://dev.klokantech.com/srtm/srtm_decode.html
http://www.klokantech.com/labs/dem-color-encoding/
http://dev.klokantech.com/srtm/googlemaps.html

There is a source code of the GDAL utility for encoding elevation data into
RGB available online:
https://github.com/webglearth/gdaldem_web
but you may not need it, if direct reading via JavaScript in the web
browser is not required for your application.

Regards,

Klokan Petr Pridal

On Mon, Feb 3, 2014 at 7:48 PM, David Baker (Geoscience) <
david.m.baker at chk.com> wrote:

> Jukka,
>
> 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?
>
> David
>
> -----Original Message-----
> From: gdal-dev-bounces at lists.osgeo.org [mailto:
> gdal-dev-bounces at lists.osgeo.org] On Behalf Of Rahkonen Jukka (Tike)
> Sent: Monday, February 03, 2014 11:37 AM
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Fast Pixel Access
>
> Hi,
>
> 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.
>
> -Jukka-
>
> Brian Case [rush at winkey.org] wrote:
>
> > -Jukka
>
> > tileindex, mapserver, and the gdal wms driver
>
>
>
> > On Mon, 2014-02-03 at 17:20 +0000, Jukka Rahkonen wrote:
> >> Luke Roth <roth.luke <at> gmail.com> writes:
> >
> > >
> >> > Another thing that might speed up access is setting the config
> >> option GDAL_DISABLE_READDIR_ON_OPEN = TRUE, either as an environment
> >> variable or on the command line.  That should help with GDAL reading the
> >> directory each time it opens a dataset.  I have an application which
> reads
> >> one value from each of a large number of datasets and setting this
> option
> >> made it run about 3 times faster.
> >
> >
> > Hi,
> >
> > You are right. This config option makes GDAL to skip the reading of the
> > remote directory and saves a lot of bandwidth:
> >
> > VRT case:
> > Bytes Received:  4 244 509 (of which the vrt file: 4 192 577)
> > Sequence (clock) duration:    00:00:09.9996000
> > Was:
> > Bytes Received:  6 459 443
> > Sequence (clock) duration:    00:00:37.8130000
> >
> > BigTIFF case:
> > Bytes Received:  2 158 917
> > Sequence (clock) duration:    00:00:04.4368000
> > Was:
> > Bytes Received:  4 374 137
> > Sequence (clock) duration:    00:00:30.9192000
> >
> >
> > Conclusion:
> > Both options are unsuitable for serious use while amusing to play with.
> > Reading the BigTIFF tile offset index (or whatever it is) seems to mean
> > about 2 MB of compultory payload traffic. Reading the VRT file means in
> this
> > example 4 MB of payload. If this sort of net access to a large directory
> of
> > raster files should be important for someone there should be a way to
> find
> > the right raster file and righ data range in that file with minimum
> amount
> > of bytes. Perhaps some kind of rtree indexed vrt file? First aid might
> be to
> > keep the vrt file on the client side.
> >
> > -Jukka Rahkonen-
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ________________________________
>
> 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).
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
http://blog.klokan.cz/
http://www.maptiler.org/
http://www.oldmapsonline.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140203/6c08e2f7/attachment-0001.html>