Klokan, This looks like it could work. This would be accessed with the GDAL_WCS driver? If so, I see that there it requires Curl, and I have a Curl directory in my install, but I get an error when I try and access the data.
David David M. Baker Senior Advisor - Geoscience Technology Chesapeake Energy Corporation 405-935-3715 office 405-496-5373 cell david.m.ba...@chk.com<mailto:david.m.ba...@chk.com> From: klo...@gmail.com [mailto:klo...@gmail.com] On Behalf Of Klokan Petr Pridal Sent: Monday, February 03, 2014 1:38 PM To: David Baker (Geoscience) Cc: Rahkonen Jukka (Tike); gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Fast Pixel Access 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.ba...@chk.com<mailto:david.m.ba...@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-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org> [mailto:gdal-dev-boun...@lists.osgeo.org<mailto:gdal-dev-boun...@lists.osgeo.org>] On Behalf Of Rahkonen Jukka (Tike) Sent: Monday, February 03, 2014 11:37 AM To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@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 [r...@winkey.org<mailto:r...@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<http://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@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@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@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> http://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://blog.klokan.cz/ http://www.maptiler.org/ http://www.oldmapsonline.org/ ________________________________ 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
