Re: [Qgis-developer] CAPS GIS Desktop Application

2011-08-04 Thread Alexander Bruy
Hi Bob,

2011/8/3 Bob English bobe...@gmail.com:
 I've noticed that the QgsRasterLayer class included with the  QGIS Stable
 1.0 API that came with my QGIS Copiapo installation does not have MrSID
 support, although the Copiapo application itself does open MrSID files.  I
 suppose it isn't possible to add MrSID support by changing the GDAL version
 in the API in code because GDAL is compiled in?  Does the API that comes
 with Wroclaw have MrSID support? If not, I guess I could use the Python
 bindings for GDAL to create a workaround?

QgsRasterLayer don't have any raster support at all. Reading rasters
is responsibility
of the raster provider (GDAL). So you need to build GDAL with MrSID
support and then
build QGIS with this new GDAL.

Hope this helps


-- 
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Running QGIS from build directory

2011-08-04 Thread Martin Dobias
Hi Tim

On Thu, Aug 4, 2011 at 10:12 AM, Tim Sutton li...@linfiniti.com wrote:

 Cool stuff! Next we can try to make our unit tests run from there. If
 I try to manually run a test e.g.

 output/bin/qgis_rasterlayertest

 it doesnt pick up any providers. I notice also that the binaries
 placed in the output dir still will pick up system qgis libs e.g.:

 [bin] ldd qgis_rasterlayertest
 libqgis_core.so.1.8.0 = /usr/local/lib/libqgis_core.so.1.8.0
 (0x7f6305787000)

 Though for QGIS they are correct:

 [bin] ldd qgis | grep core
        libqgis_core.so.1.8.0 =
 /home/timlinux/dev/cpp/Quantum-GIS/build-master-qtcreator/output/lib/libqgis_core.so.1.8.0
 (0x7fccd97c3000)

Oh, I forgot to fix unit tests :-)

By default CMake adds RPATH to binaries that are produced so that they
will reach the libraries within build directory. Later when doing
'make install' it removes the RPATH, otherwise the binaries would
still pick up the libraries from build directory.

Looking at the ADD_QGIS_TEST macro I see that we explicitly disable
RPATH because until now also the tests would need to be installed to
work correctly. I am not at the dev box right now, but removing
SKIP_BUILD_RPATH property from the macro should fix that.

With the support for running qgis from build path I think we should
not install the tests anymore...


Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Running QGIS from build directory

2011-08-04 Thread Tim Sutton
Hi

On Thu, Aug 4, 2011 at 10:38 AM, Martin Dobias wonder...@gmail.com wrote:
 Hi Tim

 On Thu, Aug 4, 2011 at 10:12 AM, Tim Sutton li...@linfiniti.com wrote:

 Cool stuff! Next we can try to make our unit tests run from there. If
 I try to manually run a test e.g.

 output/bin/qgis_rasterlayertest

 it doesnt pick up any providers. I notice also that the binaries
 placed in the output dir still will pick up system qgis libs e.g.:

 [bin] ldd qgis_rasterlayertest
 libqgis_core.so.1.8.0 = /usr/local/lib/libqgis_core.so.1.8.0
 (0x7f6305787000)

 Though for QGIS they are correct:

 [bin] ldd qgis | grep core
        libqgis_core.so.1.8.0 =
 /home/timlinux/dev/cpp/Quantum-GIS/build-master-qtcreator/output/lib/libqgis_core.so.1.8.0
 (0x7fccd97c3000)

 Oh, I forgot to fix unit tests :-)

 By default CMake adds RPATH to binaries that are produced so that they
 will reach the libraries within build directory. Later when doing
 'make install' it removes the RPATH, otherwise the binaries would
 still pick up the libraries from build directory.

 Looking at the ADD_QGIS_TEST macro I see that we explicitly disable
 RPATH because until now also the tests would need to be installed to
 work correctly. I am not at the dev box right now, but removing
 SKIP_BUILD_RPATH property from the macro should fix that.


Ok cool, I will try that.

 With the support for running qgis from build path I think we should
 not install the tests anymore...


Agreed.

Thanks Martin,

Regards

Tim


 Martin




-- 
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
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Provider native raster band stats

2011-08-04 Thread Tim Sutton
Hi

For all interested, I have applied the first changes to master (see
http://linfiniti.com/2011/08/improvements-to-raster-performance-in-qgis-master/)and
with a unit test! :-)

I still need to apply Etienne's patch for progress bar support which I
hope to do in this week.

regards

Tim

On Thu, Aug 4, 2011 at 9:40 AM, Tim Sutton li...@linfiniti.com wrote:
 Hi

 On Wed, Aug 3, 2011 at 7:38 PM, Etienne etienne...@yahoo.com wrote:
 Hi, I'm glad I can help!

 1) regarding the histogram caching:
 GDAL does this automatically, it looks for existing aux file and a
 suitable histogram block.  It's all in function
 GDALPamRasterBand::PamFindMatchingHistogram() in file
 gdalpamrasterband.cpp .
 As long as the dataset has support for PAM (stored in the .aux.xml file), it 
 should work.
 I found a bug in the floating-point comparison which was already fixed: 
 http://trac.osgeo.org/gdal/ticket/4183

 Unlike the stats functions (GetStatistics/ComputeStatistics), there is only 
 1 function which looks for cached data.



 Ok for me it seems to recompute the histogram every time (which takes
 about a minute+ with the sample data set I sent you). I will update my
 gdal svn copy to get your patch for #4183 and see if the problem goes
 away.

 2) regarding the caching of stats:
 Actually the GDAL driver looks for stored metadata (in function  
 GDALRasterBand::GetStatistics).
 This works for gtiff files, I don't know for other raster types.


 ok


 3) regarding the progress bar:
 Do you have sufficient authority to ask the GDAL folks to change the 
 prototype for GDALGetRasterStatistics() and GetStatistics() for them to 
 include a progress call-back?  I could make a patch for it, but I don't know 
 if they would accept it.
 In the mean time, I can copy the GDAL code into  qgsgdalprovider and submit 
 that patch to you.


 Ok Martin addressed this in his email in this thread. I basically have
 no more authority than anyone else in the community - they evauate
 each request based on merit. As Martin mentions, breaking ABI
 compatibility will not go down well with them so providing a wrapper
 function which adds progress support (or perhaps adding the progress
 callback as the last param with a default of void so that it can be
 left out will be acceptable to them) would be good.

 4)
 There is another issue I forgot to mention, and that is the bin count of the
 histogram.  GDAL uses 256 bins, and recently the GDAL histogram
 calculation  in QgsRasterLayerProperties::refreshHistogram()  has been
 changed to use 255 bins. ( const int BINCOUNT = 255; ).  Could this be
 put back to 256 for consistency with GDAL, or is there a reason for
 that?


 Ok I have changed in my local copy and will commit soon.


 Thanks! Etienne


 Thank you!

 Regards

 Tim

 
 From: Tim Sutton li...@linfiniti.com
 To: Etienne etienne...@yahoo.com
 Cc: Qgis-developer@lists.osgeo.org Qgis-developer@lists.osgeo.org
 Sent: Wednesday, August 3, 2011 6:00:56 AM
 Subject: Re: [Qgis-developer] Provider native raster band stats

 Hi Again

 By the way is there a handy way to get the histogram from the aux.xml
 too? I see it is stored there but haven't figured out how to retrieve
 it from cache again.




 - Original Message -
 From: Tim Sutton li...@linfiniti.com
 To: Etienne etienne...@yahoo.com
 Cc: Qgis-developer@lists.osgeo.org Qgis-developer@lists.osgeo.org
 Sent: Wednesday, August 3, 2011 6:00:56 AM
 Subject: Re: [Qgis-developer] Provider native raster band stats

 Hi Again

 By the way is there a handy way to get the histogram from the aux.xml
 too? I see it is stored there but havent figured out how to retrieve
 it from cache again.

 Regards

 Tim

 On Wed, Aug 3, 2011 at 10:16 AM, Tim Sutton li...@linfiniti.com wrote:
 Hi

 On Tue, Aug 2, 2011 at 7:06 PM, Etienne etienne...@yahoo.com wrote:
 Tim, my impression is that it speeds things up, but I have a suggestion to 
 make it faster.

 Cool!

 From what I have seen in your code, the  QgsGdalProvider::bandStatistics 
 function calls GDALComputeRasterStatistics (), which computes the 
 statistics every time - it doesn't fetch pre-calculated data ( which is 
 stored in gtiff metadata, or aux.xml file).

 A better way would be to use the GDALGetRasterStatistics() which 
 calls GDALComputeRasterStatistics() when needed (when bForce = TRUE)
 double myerval =  GDALGetRasterStatistics ( myGdalBand, bApproxOK, TRUE, 
 pdfMin, pdfMax, pdfMean, pdfStdDev);


 Ah - actually I thought GDALComputeRasterStatistics was using aux.xml
 cached stats already. I guess I never read the docs carefully enough.
 I applied your change and my ~8min to load raster from my original
 email took about a minute to load the first time (while gdal was
 creating an aux.xml) and subsequent use of the same raster resulted in
 it opening instantly! So thanks for your excellent advice. I have
 pushed an updated version to my repo that incorporates your changes
 should others like to try. I