On Thu, Jan 13, 2011 at 7:06 PM, John C. Tull <jct...@gmail.com> wrote: > You might want to sync the branch to current trunk, although that could > create new problems I suppose.
You are right, I should merge trunk more frequently. > 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.) Pyramids are not yet enabled, at moment I pay attention to correct basic rendering of all data types in all providers. > 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? I cannot say if gdal warp is always slow or it could be speed up by changing init params, I see however that the approximate reprojection is necessary, so that will be the next step. Radim _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
