[Qgis-developer] Re: Raster providers

[John C. Tull]

Hi Radim,

Turning off python bindings got it to build. Jürgen pointed out this patch from last month that fixed that particular build problem:
http://trac.osgeo.org/qgis/changeset/14988

You might want to sync the branch to current trunk, although that could create new problems I suppose. I applied the patch because I was interested in seeing if the branch handles the openlayer plugin for transforms from the Google Mercator projection. I'm happy to report that it worked just fine. This will be a great boon to work that I and many others do, I'm sure.

Not surprisingly, the raster transforms can be very costly with large datasets. A hillside of mine that is 26828 × 28695 with 30m resolution takes several minutes to load in full view. When zoomed in considerably, performance is quite acceptable. (This particular file does not have pyramids built. It is noteworthy that the option to build pyramids is no longer available in the raster provider branch. A dialog saying the file type is not supported for pyramid building is shown. In trunk, the pyramid build option works for the same file.)

Comparing the load time of this raster when the project CRS is the same as the raster (i.e., no transform should be occurring), the load time still requires several minutes. This is true whether or not I have enabled on the fly reprojection in the project options. In contrast, the same file takes several seconds to load in trunk. Perhaps there needs to be a CRS check on rasters to bypass whatever is happening to consume so many cpu cycles when transforms are unnecessary?

All told, this is excellent work. I look forward to whatever efficiency improvements might make it into the code based on the conversations occurring in this thread. I also look forward to this moving into the main branch so everyone can benefit from your work.

Regards,
John


On Jan 10, 2011, at 1:09 PM, Radim Blazek wrote:

> Thanks for testing and sorry for inconvenience,
> indeed , the callback function was left in raster layer, I have
> commited temporary fix.
> Later we have to add signals to providers.
> 
> Radim
> 
> On Mon, Jan 10, 2011 at 8:16 PM, Alexander Bruy
> <alexander.bruy at gmail.com> wrote:
>> Hi Radim,
>> 
>> I try to build raster providers branch on Windows with MSVC Express 2008
>> against dependencies from OSGeo4W (gdal 1.7.3) and get next error:
>> 
>> Linking...
>>   Creating library D:\devel\raster\build\src\providers\gdal\RelWithDebInfo\gdalprovider.lib and object D:\devel\raster\build\src\providers\gdal\RelWithDebInfo\gdalprovider.exp
>> qgsgdalprovider.obj : error LNK2019: unresolved external symbol "int __stdcall progressCallback(double,char const *,void *)" (?progressCallback@@YGHNPBDPAX at Z) referenced in function "public: virtual void __thiscall QgsGdalProvider::populateHistogram(int,class QgsRasterBandStats &,int,bool,bool)" (?populateHistogram at QgsGdalProvider@@UAEXHAAVQgsRasterBandStats@@H_N1 at Z)
>> D:\devel\raster\build\src\providers\gdal\RelWithDebInfo\gdalprovider.dll : fatal error LNK1120: 1 unresolved externals
>> 
>> Any hints on this?
>> 
>> Thanks
>> 
>> On Sat, 8 Jan 2011 20:26:24 +0100
>> Radim Blazek <radim.blazek at gmail.com> wrote:
>> 
>>> Hi all,
>>> new raster providers are ready for testing. The work is not yet
>>> finished but all the old functionality should be available. Current
>>> status:
>>> 
>>> - GDAL: on-the-fly reprojection via gdal warp, quite slow, I have not
>>> yet implemented the trick used in Mapserver Marco pointed me to.
>>> Please let me know, if you consider the speed at least acceptable for
>>> real work. The speed depends especially on output display size.
>>> 
>>> - GRASS: all the old functionality is back, the data are provided
>>> instead of just a picture so that it is possible to assign a style in
>>> QGIS like it was possible with GRASS via GDAL, reprojection is not yet
>>> implemented
>>> 
>>> - WMS: should work like before, the requested SRS does not yet follow
>>> current project projection
>>> 
>>> Please test the raster providers branch and let me know about problems:
>>> 
>>> svn co https://svn.osgeo.org/qgis/branches/raster-providers
>>> 
>>> I would like to merge the branch to trunk and continue the work in trunk.
>>> 
>>> Radim
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> 
>> 
>> --
>> Alexander Bruy
>> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer