[Qgis-developer] Raster providers
Radim Blazek
radim.blazek at gmail.com
Tue Mar 1 04:04:48 EST 2011
Hi,
I have to do the code cleanup definitely in the branch + wms fix.
Then I'll let you know before merge.
Radim
On Tue, Mar 1, 2011 at 9:27 AM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> wrote:
> Hi Radim, Tim
>
>> That being the case, I would suggest we poll Marco and other devs to
>> see if it can move into trunk so that it can be more broadly tested
>
> I briefly tested the raster provider branch today and it works great. The
> performance seems to be fast now even with reprojection turned on. The only
> thing with my test rasters that didn't work was the 'zoom to best resolution'
> function. However, this is a detail and I'm in favor of merging the branch to
> trunk soon and fixing the minor issues there.
>
> Regards,
> Marco
>
> Am Montag, 28. Februar 2011, um 10.59:21 schrieb Tim Sutton:
>> Hi
>>
>> On Mon, Feb 28, 2011 at 10:01 AM, Radim Blazek <radim.blazek at gmail.com>
> wrote:
>> > On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton <lists at linfiniti.com> wrote:
>> >> Do you have anything else left on your todo list before you can merge to
>> >> trunk?
>> >
>> > It looks like this:
>> > qgsrasterprojector.* qgsrasterdataprovider.* raster/qgsrasterlayer.* : 60
>> > TODOs qgsgdalprovider.*: 11 TODOs
>> > qgsgrassrasterprovider.*: 8 TODOs
>> > qgswmsprovider.*: 53 TODOs
>> >
>> > But all those TODOs are not really problem, IIRC, before the merge I have
>> > to add only fall back to precise reprojection if approximation fails
>> > (easy) and code cleanup.
>> >
>> > The problem with data reloading on update (G. Manghi reported) I would
>> > like to solve in trunk
>> > because it may need QgsLayer and renderer modifications.
>> >
>> > Then, there are some places, usually constants which have
>> > to be checked better (e.g. max error, in reprojection, minimum source
>> > resolution etc.)
>> > That can still be done in trunk, I think.
>>
>> That being the case, I would suggest we poll Marco and other devs to
>> see if it can move into trunk so that it can be more broadly tested
>> before the release - I don't think it will be good to merge it at the
>> last minute before the release for this reason.
>>
>> > BTW: The approximate reprojection could may be used also for vectors?
>>
>> Hmm interesting. Is there a summary of the logic you have used to do
>> this somewhere?
>>
>> Regards
>>
>> Tim
>>
>> > Radim
>> >
>> >> +1 from me to merge when you are ready
>> >>
>> >> I would like to make some cleanups to the raster properties dialog
>> >> after you are done...hopefully I can do the ui clean upsin time for
>> >> 1.7....
>> >>
>> >> Regards
>> >>
>> >> Tim
>> >>
>> >> --
>> >> Tim Sutton - QGIS Project Steering Committee Member (Release Manager)
>> >> ==============================================
>> >> Please do not email me off-list with technical
>> >> support questions. Using the lists will gain
>> >> more exposure for your issues and the knowledge
>> >> surrounding your issue will be shared with all.
>> >>
>> >> Visit http://linfiniti.com to find out about:
>> >> * QGIS programming and support services
>> >> * Mapserver and PostGIS based hosting plans
>> >> * FOSS Consulting Services
>> >> Skype: timlinux
>> >> Irc: timlinux on #qgis at freenode.net
>> >> ==============================================
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole - Linux & Open Source Solutions
> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
More information about the Qgis-developer
mailing list