[gdal-dev] Fast Pixel Access

David Baker (Geoscience) david.m.baker at chk.com
Mon Feb 3 10:48:59 PST 2014


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).


More information about the gdal-dev mailing list