[gdal-dev] RE: progressive rendering

Tamas Szekeres szekerest at gmail.com
Tue Aug 19 18:32:35 EDT 2008

2008/8/19 Norman Barker <nbarker at ittvis.com>:
> Tamas,
> Thanks for the input, much appreciated since I would like to get this
> interface defined.
> A streaming driver so JPIPKAK for example would need to register as its
> own driver to handle urls of the type jpip://, similarly ecwp would need
> its own driver if it were to use the same callback for streaming data.
> As such the management of GDALDataset::RasterIO and Band.RasterIO would
> be the implementors responsibility, most likely this could be defined
> with references back to the parent dataset as the controller thread.


Is this somewhat different as how the RasterIO is handled in the
current approach. The controller thread you mentioned would change the
synchronous behaviour of RarterIO into an asynchronous approach, yes?
In that case your callback would also denote the completion of the
overall process as well as to notify the user about a change in the
underlying data?
In any case I'd prefer a separate band/dataset level callback instead
of changing the current RasterIO signature.

The driver could also keep on the current mechanism like using the
thread of the caller to complete the RasterIO operation  in this case
the driver might want to provide that the client could re-enter into
the function from the callback in order to read out the intermediary
data from the buffers.

> The comment about raster x and y size is interesting, in the case of
> jpip raster x and y size is known as a result of the image metadata
> being transferred to the client in the initial request and can be
> handled as overviews, for other formats like MrSID, ECW then I defer to
> the better informed.
> JPIP does have a client cache, and this data is needed between requests,
> but I believe we can keep this data internal to the format driver.

I thing it's crucial how the progressive rendering capable driver
would represent the intermediary images. In case when different
buffers are used the client cannot use the same RasterIO to read out
the changes so some additional parameters/functions might have to be

Best regards,


More information about the gdal-dev mailing list