2008/8/19 Norman Barker <[EMAIL PROTECTED]>: > 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. >
Norman, 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 introduced. Best regards, Tamas _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
