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. 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. Would it be possible to add this callback function as a stub method? Thanks, Norman -----Original Message----- From: Tamas Szekeres [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 4:03 PM To: Norman Barker Cc: [email protected] Subject: Re: [gdal-dev] RE: progressive rendering Norman, It seems like adding a GDALProgressFunc like parameter to RasterIO would be a solution but I'm not totally sure about the negaive effects of this change since these functions are frequently used. Most of the drivers are doing band based rasterIO so you should also deal with Band.RasterIO in addition. The default implementation of GDALDataset::IRasterIO is calling the band based rasterIO functions of the drivers. In such cases how the progress func. of the band based raserIO would be bound to the progress func of the outer dataset? I would also be curious to know how the underlying intermediary data should be stored and would vary between the subsequent progress reports. For example would the raster X and Y size be different or would it be handed as a temporary buffers and datasets or bands (like overviews) for example? Best regards, Tamas _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
