Re: [Qgis-developer] Raster providers
On Mon, Mar 14, 2011 at 1:42 PM, Alexander Bruy alexander.b...@gmail.com wrote: Hi Radim I found some issues with new raster providers (tested on r15453). 1. Applying a style to layer triggers statistic calculation. If I apply one style and then another statistics calculates twice. 2. In Metadata tab (Layer properties dialog) there is no raster statistics even when it calculated. I have created new tickets: http://trac.osgeo.org/qgis/ticket/3731 http://trac.osgeo.org/qgis/ticket/3732 Radim 3. On Histogram tab progress bar is inactive during statistics calculation. This is a bit confusing especially when raster has many bands Thanks -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS. For me, QGIS sets CRS to raster's CRS but some info seems to be lost in createFromWkt(). GRASS gives: GEOGCS[wgs84,DATUM[WGS_1984,SPHEROID[WGS_1984,6378137,298.257223563],TOWGS84[0.000,0.000,0.000]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]] QgsCoordinateReferenceSystem.createFromWkt().toWkt() gives: GEOGCS[WGS 84,DATUM[unknown,SPHEROID[WGS84,6378137,298.257223563],TOWGS84[0,0,0,0,0,0,0]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]] QgsCoordinateReferenceSystem.authid(): EPSG:4148 QgsCoordinateReferenceSystem.description(): Hartebeesthoek94 Everything for CRS QgsCoordinateReferenceSystem created from WKT given by GRASS above. Here I am only QgsCoordinateReferenceSystem user, can anybody knowing QgsCoordinateReferenceSystem explain what is happening and what is wrong? I have added more debug output, you can grep everything importing with grep -i crs. The region is not reprojected (I don't know if this should be expected). Region should be reprojected of course, but that has nothing to do with rasters, please fill a ticket for GRASS plugin. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Thu, 31. Mar 2011 at 11:12:42 +0200, Radim Blazek wrote: On Wed, Mar 9, 2011 at 12:24 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS. For me, QGIS sets CRS to raster's CRS but some info seems to be lost in createFromWkt(). GRASS gives: GEOGCS[wgs84,DATUM[WGS_1984,SPHEROID[WGS_1984,6378137,298.257223563],TOWGS84[0.000,0.000,0.000]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]] QgsCoordinateReferenceSystem.createFromWkt().toWkt() gives: GEOGCS[WGS 84,DATUM[unknown,SPHEROID[WGS84,6378137,298.257223563],TOWGS84[0,0,0,0,0,0,0]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]] QgsCoordinateReferenceSystem.authid(): EPSG:4148 QgsCoordinateReferenceSystem.description(): Hartebeesthoek94 Everything for CRS QgsCoordinateReferenceSystem created from WKT given by GRASS above. That shouldn't be a problem projectionwise. It found EPSG:4148 because that has the same projection parameters as EPSG:4326 and the WKT string doesn't have any information about which EPSG is desired. Otherwise the description and authid would change, still that wouldn't change the projection. Or am I missing something else that is lost? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Thu, Mar 31, 2011 at 11:32 AM, Jürgen E. j...@norbit.de wrote: That shouldn't be a problem projectionwise. It found EPSG:4148 because that has the same projection parameters as EPSG:4326 and the WKT string doesn't have any information about which EPSG is desired. Otherwise the description and authid would change, still that wouldn't change the projection. Or am I missing something else that is lost? OK. Giovanni, can you verify if the problem is still present? Check also layer's metadata and debug output as missing EPSG can lead to confusion described above. Radim Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel li...@borysjurgiel.pl wrote:
Finally! :-) It's impressing. I observe two issues only:
2. GDAL TMS layers don't work. I get a warning messageBox:
It seems to work. I have not done any particular fix for this, but it
was possibly fixed by one of many other fixes I have applied. Can you
verify?
Radim
Cannot ChunkAndWarpImage : Integer overflow : nSrcXSize=1048576,
nSrcYSize=1048576
This is, for example, a TMS source that doesn't work any more:
GDAL_WMS
Service name=TMS
ServerUrlhttp://tile.openstreetmap.org/${z}/${x}/${y}.png/ServerUrl
/Service
DataWindow
UpperLeftX-20037508.34/UpperLeftX
UpperLeftY20037508.34/UpperLeftY
LowerRightX20037508.34/LowerRightX
LowerRightY-20037508.34/LowerRightY
TileLevel16/TileLevel
TileCountX1/TileCountX
TileCountY1/TileCountY
YOrigintop/YOrigin
/DataWindow
ProjectionEPSG:900913/Projection
BlockSizeX256/BlockSizeX
BlockSizeY256/BlockSizeY
BandsCount3/BandsCount
Cache
Extension.png/Extension
/Cache
/GDAL_WMS
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Mon, Mar 14, 2011 at 1:42 PM, Alexander Bruy alexander.b...@gmail.com wrote: 3. On Histogram tab progress bar is inactive during statistics calculation. This is a bit confusing especially when raster has many bands I have added progress signal to GDAL provider. Histogram progress is updated only when histogram is calculated, stats progress is displayed in main app status bar, that did non change with respect to pre providers state however, I believe. The status bars are not updated as frequently as the value on them is set. I have no idea why. I have left debug output in QgsRasterLayer::onProgress, you can compare it. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
That fix is was already superseded by complete QgsGdalProvider::readBlock rewrite. I'll look at it. On Fri, Mar 11, 2011 at 8:54 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi Radim, unfortunately the temporary? ugly fix for not georeferenced images, as you call in the commit, does not seem to work fine with the georeferencer. If you open a non-georeferenced image in the georeferencer it will not show in the tool window. Cheers -- Giovanni -- On Wed, 2011-03-09 at 22:47 +0100, Radim Blazek wrote: The reason is, that GDALCreateGenImgProjTransformer() does not accept source data sources which are not georeferenced. As an ugly workaround, I set the first item in GeoTransform (x offset) to DBL_MIN. In theory it can cause a shift in georeferencing. I don't believe however that it could be really a problem. The shift is 2.22507e-308. Se also cc from gdal list. Radim On Wed, Mar 9, 2011 at 9:53 AM, Werner Macho werner.ma...@gmail.com wrote: Hi all! I tried to load a simple jpg (without any projection information) into QGIS just to test .. It unfortunately leads to a segfault .. Then i thought to georeference the file first ... and opened the georeferencer plugin .. but it seems the georeferencer plugin uses the same mechanism to load the jpg as qgis itself .. so nothing showed up and I were not able to georeference the raster file .. It seems that there whould be some defaults for rasterfiles without any projection information. Otherwise it is not possible to create georeferenced files any more.. Anyone can confirm this? best regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
You have already reported that problem and I have already explained where the problem is. That is on my list and I'll let you know once i fix that. I am trying to fix and response all related bug reports. Radim On Sun, Mar 13, 2011 at 8:43 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi Radim, just notived that also r.colors have no effect on GRASS rasters. Cheers -- Giovanni -- On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi, the problem seem to be incorrect / inconsistent handling of geotransforms with positive y-axis scale. I have the feeling that at some place the raster extent calculation is performed using a negative y-axis (probably because the CRS is not valid), but some other routines from the gdal raster provider use the directions given by the geotransform. this seemed indeed to be the case, I have commited a fix in r15481 (just adjusting the geotransform to have negative y axis if no geotransform is available). (should fix #3596, but please test) bye, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim, just notived that also r.colors have no effect on GRASS rasters. Cheers -- Giovanni -- On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi again, just notived that also r.colors have no effect on GRASS rasters. not totally true. It does not have immediately effect even if you hit the refresh button. But if you remove the raster and then add it again the new colormap will show ok. Not very handy. Cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim, On Thu, 2011-03-10 at 20:13 +0100, Radim Blazek wrote: I have changed how GDAL provider reads the data, it should be fast again. thanks for the fix! it works very well. I tested (under both Linux and Windows) a 2.7GB image with internal tiles and overviews. It opens in a blink of an eye and it reprojects just as fast! What it does not seem to work correctly now is the zoom to best scale menu in a reprojected image: the raster disappear as QGIS probably try to zoom using the wrong crs? Cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim, unfortunately the temporary? ugly fix for not georeferenced images, as you call in the commit, does not seem to work fine with the georeferencer. If you open a non-georeferenced image in the georeferencer it will not show in the tool window. Cheers -- Giovanni -- On Wed, 2011-03-09 at 22:47 +0100, Radim Blazek wrote: The reason is, that GDALCreateGenImgProjTransformer() does not accept source data sources which are not georeferenced. As an ugly workaround, I set the first item in GeoTransform (x offset) to DBL_MIN. In theory it can cause a shift in georeferencing. I don't believe however that it could be really a problem. The shift is 2.22507e-308. Se also cc from gdal list. Radim On Wed, Mar 9, 2011 at 9:53 AM, Werner Macho werner.ma...@gmail.com wrote: Hi all! I tried to load a simple jpg (without any projection information) into QGIS just to test .. It unfortunately leads to a segfault .. Then i thought to georeference the file first ... and opened the georeferencer plugin .. but it seems the georeferencer plugin uses the same mechanism to load the jpg as qgis itself .. so nothing showed up and I were not able to georeference the raster file .. It seems that there whould be some defaults for rasterfiles without any projection information. Otherwise it is not possible to create georeferenced files any more.. Anyone can confirm this? best regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
I have changed how GDAL provider reads the data, it should be fast again. BUT! I am not absolutely sure that resampling is perfect and the nearest neighbour is alway nearest. I dont think however that anybody could notice that in normal work. I would appreciate however if somebody with fresh brain could check the alignment fiddling. http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L529 More pointers - more crashes expected! Radim On Wed, Mar 9, 2011 at 8:30 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi, On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. I'm testing the new raster capabilities of QGIS and I would like to have your opinion on a certain matter before eventually filing a ticket. I have a bunch of big tiff rasters ( 1gb, sometimes 2gb), with internal tiles and/or overviews. What I'm seeing is that now those rasters take quite a *lot* (making qgis not responsive for a while) to be rendered, before the merge it was all much quicker. As exemple: on QGIS 1.6 a 1.7gb geotiff with tiles and overviews opens in (more or less) 1 sec., in trunk now takes (more os less) 1 minute! After the raster show in the canvas, also opening its properties take a long time. Before the merge was immediate. Zooming and panning it is also much slower than before the merge. Overall it seems like that tiles and overviews are ignored or not read., but to me seems that also opening big tiffs ( 1gb) without internal tiles and/or overviews takes a *lot* more than before the merge. anyone experiencing the same? cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
I fact, I forgot to write a piece of logic, there is a shift. Radim On Thu, Mar 10, 2011 at 8:13 PM, Radim Blazek radim.bla...@gmail.com wrote: I have changed how GDAL provider reads the data, it should be fast again. BUT! I am not absolutely sure that resampling is perfect and the nearest neighbour is alway nearest. I dont think however that anybody could notice that in normal work. I would appreciate however if somebody with fresh brain could check the alignment fiddling. http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L529 More pointers - more crashes expected! Radim On Wed, Mar 9, 2011 at 8:30 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi, On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. I'm testing the new raster capabilities of QGIS and I would like to have your opinion on a certain matter before eventually filing a ticket. I have a bunch of big tiff rasters ( 1gb, sometimes 2gb), with internal tiles and/or overviews. What I'm seeing is that now those rasters take quite a *lot* (making qgis not responsive for a while) to be rendered, before the merge it was all much quicker. As exemple: on QGIS 1.6 a 1.7gb geotiff with tiles and overviews opens in (more or less) 1 sec., in trunk now takes (more os less) 1 minute! After the raster show in the canvas, also opening its properties take a long time. Before the merge was immediate. Zooming and panning it is also much slower than before the merge. Overall it seems like that tiles and overviews are ignored or not read., but to me seems that also opening big tiffs ( 1gb) without internal tiles and/or overviews takes a *lot* more than before the merge. anyone experiencing the same? cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Radim, the round() you added in qgsgdalprovider causes problems for me on VC++ ( http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L664 ). Should we add something like: #define round(dbl) dbl = 0.0 ? (int)(dbl + 0.5) : ((dbl - (double)(int)dbl) = -0.5 ? (int)dbl : (int)(dbl - 0.5)) ? 2011/3/10 Radim Blazek radim.bla...@gmail.com I fact, I forgot to write a piece of logic, there is a shift. Radim On Thu, Mar 10, 2011 at 8:13 PM, Radim Blazek radim.bla...@gmail.com wrote: I have changed how GDAL provider reads the data, it should be fast again. BUT! I am not absolutely sure that resampling is perfect and the nearest neighbour is alway nearest. I dont think however that anybody could notice that in normal work. I would appreciate however if somebody with fresh brain could check the alignment fiddling. http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L529 More pointers - more crashes expected! Radim On Wed, Mar 9, 2011 at 8:30 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi, On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. I'm testing the new raster capabilities of QGIS and I would like to have your opinion on a certain matter before eventually filing a ticket. I have a bunch of big tiff rasters ( 1gb, sometimes 2gb), with internal tiles and/or overviews. What I'm seeing is that now those rasters take quite a *lot* (making qgis not responsive for a while) to be rendered, before the merge it was all much quicker. As exemple: on QGIS 1.6 a 1.7gb geotiff with tiles and overviews opens in (more or less) 1 sec., in trunk now takes (more os less) 1 minute! After the raster show in the canvas, also opening its properties take a long time. Before the merge was immediate. Zooming and panning it is also much slower than before the merge. Overall it seems like that tiles and overviews are ignored or not read., but to me seems that also opening big tiffs ( 1gb) without internal tiles and/or overviews takes a *lot* more than before the merge. anyone experiencing the same? cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Jef fixed that by qRound. Thank you Jef and sorry for various problems I am introducing. How do you indent the code? If I run scripts/prepare-commit.sh (which existence I just noticed) it does too many not desired indentations. Radim On Thu, Mar 10, 2011 at 11:58 PM, G. Allegri gioha...@gmail.com wrote: Radim, the round() you added in qgsgdalprovider causes problems for me on VC++ (http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L664). Should we add something like: #define round(dbl) dbl = 0.0 ? (int)(dbl + 0.5) : ((dbl - (double)(int)dbl) = -0.5 ? (int)dbl : (int)(dbl - 0.5)) ? 2011/3/10 Radim Blazek radim.bla...@gmail.com I fact, I forgot to write a piece of logic, there is a shift. Radim On Thu, Mar 10, 2011 at 8:13 PM, Radim Blazek radim.bla...@gmail.com wrote: I have changed how GDAL provider reads the data, it should be fast again. BUT! I am not absolutely sure that resampling is perfect and the nearest neighbour is alway nearest. I dont think however that anybody could notice that in normal work. I would appreciate however if somebody with fresh brain could check the alignment fiddling. http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L529 More pointers - more crashes expected! Radim On Wed, Mar 9, 2011 at 8:30 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi, On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. I'm testing the new raster capabilities of QGIS and I would like to have your opinion on a certain matter before eventually filing a ticket. I have a bunch of big tiff rasters ( 1gb, sometimes 2gb), with internal tiles and/or overviews. What I'm seeing is that now those rasters take quite a *lot* (making qgis not responsive for a while) to be rendered, before the merge it was all much quicker. As exemple: on QGIS 1.6 a 1.7gb geotiff with tiles and overviews opens in (more or less) 1 sec., in trunk now takes (more os less) 1 minute! After the raster show in the canvas, also opening its properties take a long time. Before the merge was immediate. Zooming and panning it is also much slower than before the merge. Overall it seems like that tiles and overviews are ignored or not read., but to me seems that also opening big tiffs ( 1gb) without internal tiles and/or overviews takes a *lot* more than before the merge. anyone experiencing the same? cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: Re: [Qgis-developer] Raster providers
Yes, it was explained in one of my previous mails: On Sat, Mar 5, 2011 at 11:21 AM, Radim Blazek radim.bla...@gmail.com wrote: Another issue is, that WMS driver does not automatically switches to projection requested by QGIS even if it is supported by WMS server. You have to manually select the right projection when layer is added. Preferably, the WMS driver should not only to switch to the right projection, but also automatically select the most similar projection offered by server if no one exactly matches. Anybody is aware of an algorithm or ready for use method doing that? Raster rendering appeared to be infinite entertainment. On Wed, Mar 9, 2011 at 8:10 AM, Ziegler Stefan stefan.zieg...@bd.so.ch wrote: Hi really impressive! What is the behaviour with WMS layer reprojection? It seems that QGIS is still doing some reprojection/resampling when OTF reprojection is enabled but the server is able to serve the desired projection. regards Stefan -Ursprüngliche Nachricht- Von: Ivan Mincik [mailto:ivan.min...@gista.sk] Gesendet am: Mittwoch, 9. März 2011 07:57 An: qgis-developer@lists.osgeo.org Betreff: Re: [Qgis-developer] Raster providers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2011 08:17 PM, Radim Blazek wrote: Merged to trunk. Congratulations, I was testing WMS layer reprojection. It is working flawlessly. I am impressed by speed. Perfect work. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13JMMACgkQVqso/9cUsCwJLgCeNCzTpXc92e2IexG/dKb/Fhvg uXgAn1ayCCcax7ONrCXNN+TsaWjCMa9X =+E80 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi all! I tried to load a simple jpg (without any projection information) into QGIS just to test .. It unfortunately leads to a segfault .. Then i thought to georeference the file first ... and opened the georeferencer plugin .. but it seems the georeferencer plugin uses the same mechanism to load the jpg as qgis itself .. so nothing showed up and I were not able to georeference the raster file .. It seems that there whould be some defaults for rasterfiles without any projection information. Otherwise it is not possible to create georeferenced files any more.. Anyone can confirm this? best regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Radim wrote: Fixed. Thanks! Tim wrote: I will update the toolbar to use the same method - it should work for multiband imagery too. I think I copied the context menu one when I did the toolbar but maybe I am wrongI'll update it. Thanks! ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote: I know that the Value Tool is a 3rd party plugin, but it would be nice if the raster-provider could work with it. All of my rasters are reported as being out of extent. confirmed: in reprojected rasters the value tool returns always out of extent. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. Regardless their CRS, GRASS rasters are always added to qgis with WGS84 CRS. Changing manually the CRS to the correct one allows to reproject as expected. The region is not reprojected (I don't know if this should be expected). Cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
AW: Re: Re: [Qgis-developer] Raster providers
I get some Messageboxes with warnings when adding a TMS [1] with GDAL minidriver: Cannot ChunkAndWarpImage: Integer overflow: nSrcXSize=8388608, nSrcYSize=8388608 The image is completely black or just fuzzy. OTF is disabled. Can this be confirmed? [1]: http://www.gdal.org/frmt_wms_openstreetmap_tms.xml regards Stefan -Ursprüngliche Nachricht- Von: Radim Blazek [mailto:radim.bla...@gmail.com] Gesendet am: Mittwoch, 9. März 2011 09:45 An: Ziegler Stefan Cc: ivan.mincik; qgis-developer Betreff: Re: Re: [Qgis-developer] Raster providers Yes, it was explained in one of my previous mails: On Sat, Mar 5, 2011 at 11:21 AM, Radim Blazek radim.bla...@gmail.com wrote: Another issue is, that WMS driver does not automatically switches to projection requested by QGIS even if it is supported by WMS server. You have to manually select the right projection when layer is added. Preferably, the WMS driver should not only to switch to the right projection, but also automatically select the most similar projection offered by server if no one exactly matches. Anybody is aware of an algorithm or ready for use method doing that? Raster rendering appeared to be infinite entertainment. On Wed, Mar 9, 2011 at 8:10 AM, Ziegler Stefan stefan.zieg...@bd.so.ch wrote: Hi really impressive! What is the behaviour with WMS layer reprojection? It seems that QGIS is still doing some reprojection/resampling when OTF reprojection is enabled but the server is able to serve the desired projection. regards Stefan -Ursprüngliche Nachricht- Von: Ivan Mincik [mailto:ivan.min...@gista.sk] Gesendet am: Mittwoch, 9. März 2011 07:57 An: qgis-developer@lists.osgeo.org Betreff: Re: [Qgis-developer] Raster providers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2011 08:17 PM, Radim Blazek wrote: Merged to trunk. Congratulations, I was testing WMS layer reprojection. It is working flawlessly. I am impressed by speed. Perfect work. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13JMMACgkQVqso/9cUsCwJLgCeNCzTpXc92e2IexG/dKb/Fhvg uXgAn1ayCCcax7ONrCXNN+TsaWjCMa9X =+E80 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
The reason is, that GDALCreateGenImgProjTransformer() does not accept source data sources which are not georeferenced. As an ugly workaround, I set the first item in GeoTransform (x offset) to DBL_MIN. In theory it can cause a shift in georeferencing. I don't believe however that it could be really a problem. The shift is 2.22507e-308. Se also cc from gdal list. Radim On Wed, Mar 9, 2011 at 9:53 AM, Werner Macho werner.ma...@gmail.com wrote: Hi all! I tried to load a simple jpg (without any projection information) into QGIS just to test .. It unfortunately leads to a segfault .. Then i thought to georeference the file first ... and opened the georeferencer plugin .. but it seems the georeferencer plugin uses the same mechanism to load the jpg as qgis itself .. so nothing showed up and I were not able to georeference the raster file .. It seems that there whould be some defaults for rasterfiles without any projection information. Otherwise it is not possible to create georeferenced files any more.. Anyone can confirm this? best regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Merged to trunk. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
\o/ \o/ \o/ \o/ -- happy QGIS users everywhere On Tue, Mar 8, 2011 at 9:17 PM, Radim Blazek radim.bla...@gmail.com wrote: Merged to trunk. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] Raster providers
Works beautifully (I'm looking at a reprojected alaska landcover test
dataset as I type this)! One comment though: The Debug output is
*extremely* verbose... as in... it looks like the matrix screen with
numbers running down my console ;-) Is this necessary?
Carson
On Tue, Mar 8, 2011 at 11:32 PM, Borys Jurgiel li...@borysjurgiel.pl wrote:
Finally! :-) It's impressing. I observe two issues only:
1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in
layer context menu and the one in toolbar). By the way, why there are the two
tools for stretching? The one in toolbar works with grayscale rasters only,
while the one in the layer context menu seems to work always.
2. GDAL TMS layers don't work. I get a warning messageBox:
Cannot ChunkAndWarpImage : Integer overflow : nSrcXSize=1048576,
nSrcYSize=1048576
This is, for example, a TMS source that doesn't work any more:
GDAL_WMS
Service name=TMS
ServerUrlhttp://tile.openstreetmap.org/${z}/${x}/${y}.png/ServerUrl
/Service
DataWindow
UpperLeftX-20037508.34/UpperLeftX
UpperLeftY20037508.34/UpperLeftY
LowerRightX20037508.34/LowerRightX
LowerRightY-20037508.34/LowerRightY
TileLevel16/TileLevel
TileCountX1/TileCountX
TileCountY1/TileCountY
YOrigintop/YOrigin
/DataWindow
ProjectionEPSG:900913/Projection
BlockSizeX256/BlockSizeX
BlockSizeY256/BlockSizeY
BandsCount3/BandsCount
Cache
Extension.png/Extension
/Cache
/GDAL_WMS
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarmer.com/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel li...@borysjurgiel.pl wrote: 1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in layer context menu and the one in toolbar). Fixed. By the way, why there are the two tools for stretching? The one in toolbar works with grayscale rasters only, while the one in the layer context menu seems to work always. No idea. Each one is calling different method : toolbar - QgisApp::localHistogramStretch() c. menu - QgsLegend::legendLayerStretchUsingCurrentExtent() It should use just one method and it should be moved to QgsRasterLayer. But which one? QgsLegend::legendLayerStretchUsingCurrentExtent() may also change drawingStyle and there is a comment in the code: // Note: Do we really want to do these next clauses? The user will get a surprise when the // drawing style they are using suddenly changes! TS Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2011 08:17 PM, Radim Blazek wrote: Merged to trunk. Congratulations, I was testing WMS layer reprojection. It is working flawlessly. I am impressed by speed. Perfect work. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13JMMACgkQVqso/9cUsCwJLgCeNCzTpXc92e2IexG/dKb/Fhvg uXgAn1ayCCcax7ONrCXNN+TsaWjCMa9X =+E80 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi On Wed, Mar 9, 2011 at 8:33 AM, Radim Blazek radim.bla...@gmail.com wrote: On Wed, Mar 9, 2011 at 12:32 AM, Borys Jurgiel li...@borysjurgiel.pl wrote: 1. Histogram stretch doesn't work with OTFR enabled (both tools: the one in layer context menu and the one in toolbar). Fixed. By the way, why there are the two tools for stretching? The one in toolbar works with grayscale rasters only, while the one in the layer context menu seems to work always. No idea. Each one is calling different method : toolbar - QgisApp::localHistogramStretch() c. menu - QgsLegend::legendLayerStretchUsingCurrentExtent() I will update the toolbar to use the same method - it should work for multiband imagery too. I think I copied the context menu one when I did the toolbar but maybe I am wrongI'll update it. Regards Tim It should use just one method and it should be moved to QgsRasterLayer. But which one? QgsLegend::legendLayerStretchUsingCurrentExtent() may also change drawingStyle and there is a comment in the code: // Note: Do we really want to do these next clauses? The user will get a surprise when the // drawing style they are using suddenly changes! TS Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] Raster providers
On Sun, 2011-03-06 at 11:01 -0800, Bob and Deb wrote: I know that the Value Tool is a 3rd party plugin, but it would be nice if the raster-provider could work with it. All of my rasters are reported as being out of extent. The value tool plugin is so useful (and fundamental) when doing raster analysis that I wish to see it become core one of these days. -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Dnia niedziela 06 marca 2011 o 21:18:59 Radim Blazek napisał(a): Hi, I am ready to merge raster-providers branch to trunk. Are you ready too? Radim Just to let you know, some of us are looking forward :-) There's less and less time for testing :) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Sun, Mar 6, 2011 at 8:01 PM, Bob and Deb bobd...@gmail.com wrote: I know that the Value Tool is a 3rd party plugin, but it would be nice if the raster-provider could work with it. All of my rasters are reported as being out of extent. The Value Tool is using layer.identify(mapPos). The layer itself knows nothing about the srs set in canvas. The easiest way to fix it is to transform mapPos in Value Tool from canvas to raster layers crs (attention, may be different for data source crs if assigned by user). I think that it may be fixed after the merge to trunk, because it will have to check QGIS version to decide if mapPos has to be projected or not. Right? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi On Sun, Mar 6, 2011 at 10:18 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi, I am ready to merge raster-providers branch to trunk. Are you ready too? +1 from me Regards Tim Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] Raster providers
I tested your updates in the raster branch today. Things look real good from my examination of the WMS capabilities. I did have a problem with the extents occasionally jumping to some very different location, but I would not consider this a show stopper. Again, this was with a WMS layer being reprojected, but no other rasters. Cheers, John On Mar 6, 2011, at 12:18 PM, Radim Blazek wrote: Hi, I am ready to merge raster-providers branch to trunk. Are you ready too? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Thanks for the update on this, Radim. I see that there will be some challenges to work out with wms and reprojection. Thanks for you hard work and great dev efforts, John On Mar 5, 2011, at 2:21 AM, Radim Blazek wrote: Hi, WMS reprojection should be fixed in sense that you get it rendered in the right place, but quality and even content is not the same like for not project on the same scale. Of course. To find the best resolution coefficient is one thing which has to be done. Higher resolution in WMS request can give you (really gives?) slightly better image but the content becomes inappropriate. Currently th QgsRasterReprojector is using just nearest neighbour, another resampling methods should be considered. Another issue is, that WMS driver does not automatically switches to projection requested by QGIS even if it is supported by WMS server. You have to manually select the right projection when layer is added. Preferably, the WMS driver should not only to switch to the right projection, but also automatically select the most similar projection offered by server if no one exactly matches. Anybody is aware of an algorithm or ready for use method doing that? Raster rendering appeared to be infinite entertainment. Radim On Mon, Feb 28, 2011 at 1:12 AM, John C. Tull jct...@gmail.com wrote: Hi, I was testing a little today. It appears that WMS layers are not being projected. I would imagine that needs to be corrected before a merge. Also, openlayers are not correctly projecting based on some quick tests on my end. I'm not sure if this is a problem with the branch or the plugin. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
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.bla...@gmail.com wrote: On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton li...@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.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
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.hugentob...@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.bla...@gmail.com wrote: On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton li...@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.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Il giorno mar, 01/03/2011 alle 09.27 +0100, Marco Hugentobler ha scritto: function. However, this is a detail and I'm in favor of merging the branch to trunk soon and fixing the minor issues there. Great. Looking forward for the merge. As soon as it will be merged, I'll test it and prepare packages for Debian unstable amd64 for wider testing. Thanks a lot to Radim. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton li...@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. BTW: The approximate reprojection could may be used also for vectors? 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 == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi On Mon, Feb 28, 2011 at 10:01 AM, Radim Blazek radim.bla...@gmail.com wrote: On Sun, Feb 27, 2011 at 9:54 PM, Tim Sutton li...@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 == -- 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] Raster providers
Hi, thanks for testing, I'll look at WMS again and let you know. Openlayers are implemented as a plugin, not provider, they will not become automatically reprojected. Radim On Mon, Feb 28, 2011 at 1:12 AM, John C. Tull jct...@gmail.com wrote: Hi, I was testing a little today. It appears that WMS layers are not being projected. I would imagine that needs to be corrected before a merge. Also, openlayers are not correctly projecting based on some quick tests on my end. I'm not sure if this is a problem with the branch or the plugin. Cheers, John On Feb 27, 2011, at 12:54 PM, Tim Sutton wrote: Hi 8-snip- - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Isn't it? The data outside source data extent are null. That is the source of all the troubles with null values handling and types remapping. The grey border around the tif you posted is part of the image. Is not? Sorry you are right - the issue lies with my data. Do you have anything else left on your todo list before you can merge to trunk? +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 == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Mon, Feb 28, 2011 at 9:01 AM, Radim Blazek radim.bla...@gmail.com wrote: BTW: The approximate reprojection could may be used also for vectors? Radim Definitely. On-the-fly reprojection of vector layers takes ages, there are no approximations right now. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi, thanks for testing, there are really too many combinations of data types, drawing styles, projections, resolutions etc. which I am not able to test all. It is fixed now. The problem was not in the color handling but in source resolution calculation. Radim On Thu, Feb 24, 2011 at 10:00 AM, Tim Sutton li...@linfiniti.com wrote: Hi Radim I did some testing too. Having otf projection is coool! Id did run into some problems with my paletted image[1] though. If I open the image in QGIS default session (i.e. no OTF projection) it displays fine [2]. If I enabled OTF Projection (using 900913 Google Mercator) the image displays as all grey [3]. If I set the CRS to the native image projection (EPSG:32734), the image does not show at all. I still need to test with other image types properly but thought I would give you this feedback so long. Also I noted that for greyscale images they always seem to load with min 0 / max 0 and I have to manually go into properties to load them from the layer. [1] http://linfiniti.com/downloads/Toposheet.tif.bz2 [2] http://imgur.com/JHOvt [3] http://imgur.com/NxB7z By the way if anyone else is using git-svn and wanting to test Radims branch, this was the process I used to add it as a local and remote branch in my local repo: git config --add svn-remote.raster-providers.url https://svn.osgeo.org/qgis/branches/raster-providers git config --add svn-remote.raster-providers.fetch :refs/remotes/raster-providers git svn fetch raster-providers -r 15231 git checkout -b raster-providers -t raster-providers git svn rebase raster-providers Thanks to Juergen for pointing me to the relevant crannie in the internet that showed how to do that. Regards Tim On Mon, Feb 21, 2011 at 4:04 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi have fixed some known problems: - short data types are represented by longer types to get space for nulls (the problem Marco found) - avoid statistics calculation on raster load (reported by John C. Tull) - properties are enabled according provider capabilities Please test. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] Raster providers
On Thu, Feb 24, 2011 at 10:00 AM, Tim Sutton li...@linfiniti.com wrote: Also I noted that for greyscale images they always seem to load with min 0 / max 0 and I have to manually go into properties to load them from the layer. For me it loads with source data type range (tested with UInt16) and it works the same way in trunk. QgsRasterLayerProperties are using mRasterLayer-minimum/maximumValue() which is by default the source data type (passed to QgsContrastEnhancement) range. Maybe 'Contrast enhancement' should be set to 'Stretch to MinMax' by default for SingleBandGray? There was little confusion in types of data read for stats calculation for GDAL, fixed. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim On Sun, Feb 27, 2011 at 6:04 PM, Radim Blazek radim.bla...@gmail.com wrote: On Thu, Feb 24, 2011 at 10:00 AM, Tim Sutton li...@linfiniti.com wrote: Also I noted that for greyscale images they always seem to load with min 0 / max 0 and I have to manually go into properties to load them from the layer. For me it loads with source data type range (tested with UInt16) and it works the same way in trunk. QgsRasterLayerProperties are using mRasterLayer-minimum/maximumValue() which is by default the source data type (passed to QgsContrastEnhancement) range. Maybe 'Contrast enhancement' should be set to 'Stretch to MinMax' by default for SingleBandGray? There was little confusion in types of data read for stats calculation for GDAL, fixed. Thanks its working great now. The grayscale issue I was having I can't replicate with the data I have here at home - will try again tomorrow on my office pc with the original dataset - as far as I know that machine is already set to stretch to min-max by default. From playing around a little on my samsung netbook, I would say performance seems quite ok for raster reprojection given the CPU's on these machines are slow. I found two other issues: - pyramids tab no long shows options to build pyramids (you can replicate with that test dataset I pointed you to). - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Otherwise its looking great for a merge into trunk soon and being part of 1.7! regards Tim Radim -- 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] Raster providers
On Sun, Feb 27, 2011 at 7:08 PM, Tim Sutton li...@linfiniti.com wrote: Thanks its working great now. The grayscale issue I was having I can't replicate with the data I have here at home - will try again tomorrow on my office pc with the original dataset - as far as I know that machine is already set to stretch to min-max by default. Sorry, you were right, after selecting 'stretch to min/max' and apply, the min max values were set wrongly. Fixed now in GDAL provider (was missing const, uff). From playing around a little on my samsung netbook, I would say performance seems quite ok for raster reprojection given the CPU's on these machines are slow. I have done some more optimization today, still not the best but acceptable, for me, the reprojection takes about 75% of time more. BTW: compiling as Release, the reprojection time was reduced to about 25%. I found two other issues: - pyramids tab no long shows options to build pyramids (you can replicate with that test dataset I pointed you to). Fixed. The methods were not virtual, but how on earth it could work before? - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Isn't it? The data outside source data extent are null. That is the source of all the troubles with null values handling and types remapping. The grey border around the tif you posted is part of the image. Is not? Radim Otherwise its looking great for a merge into trunk soon and being part of 1.7! regards Tim Radim -- 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] Raster providers
Hi 8-snip- - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Isn't it? The data outside source data extent are null. That is the source of all the troubles with null values handling and types remapping. The grey border around the tif you posted is part of the image. Is not? Sorry you are right - the issue lies with my data. Do you have anything else left on your todo list before you can merge to trunk? +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 == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi, I was testing a little today. It appears that WMS layers are not being projected. I would imagine that needs to be corrected before a merge. Also, openlayers are not correctly projecting based on some quick tests on my end. I'm not sure if this is a problem with the branch or the plugin. Cheers, John On Feb 27, 2011, at 12:54 PM, Tim Sutton wrote: Hi 8-snip- - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Isn't it? The data outside source data extent are null. That is the source of all the troubles with null values handling and types remapping. The grey border around the tif you posted is part of the image. Is not? Sorry you are right - the issue lies with my data. Do you have anything else left on your todo list before you can merge to trunk? +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 == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi Radim I did some testing too. Having otf projection is coool! Id did run into some problems with my paletted image[1] though. If I open the image in QGIS default session (i.e. no OTF projection) it displays fine [2]. If I enabled OTF Projection (using 900913 Google Mercator) the image displays as all grey [3]. If I set the CRS to the native image projection (EPSG:32734), the image does not show at all. I still need to test with other image types properly but thought I would give you this feedback so long. Also I noted that for greyscale images they always seem to load with min 0 / max 0 and I have to manually go into properties to load them from the layer. [1] http://linfiniti.com/downloads/Toposheet.tif.bz2 [2] http://imgur.com/JHOvt [3] http://imgur.com/NxB7z By the way if anyone else is using git-svn and wanting to test Radims branch, this was the process I used to add it as a local and remote branch in my local repo: git config --add svn-remote.raster-providers.url https://svn.osgeo.org/qgis/branches/raster-providers git config --add svn-remote.raster-providers.fetch :refs/remotes/raster-providers git svn fetch raster-providers -r 15231 git checkout -b raster-providers -t raster-providers git svn rebase raster-providers Thanks to Juergen for pointing me to the relevant crannie in the internet that showed how to do that. Regards Tim On Mon, Feb 21, 2011 at 4:04 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi have fixed some known problems: - short data types are represented by longer types to get space for nulls (the problem Marco found) - avoid statistics calculation on raster load (reported by John C. Tull) - properties are enabled according provider capabilities Please test. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- 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] Raster providers
Hi have fixed some known problems: - short data types are represented by longer types to get space for nulls (the problem Marco found) - avoid statistics calculation on raster load (reported by John C. Tull) - properties are enabled according provider capabilities Please test. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Raster providers
Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Thanks Radim! That was a feature I hoped to see since the first time I saw Qgis :) I'm going to check it out rigth now. giovanni 2010/11/5 Radim Blazek radim.bla...@gmail.com: Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
I appreciate your interest, but as I said, it is not usable at the moment, with a lot of luck you can display GRASS integer map, but you have to set min/max manually to get reasonable colors. Radim On Fri, Nov 5, 2010 at 10:08 AM, G. Allegri gioha...@gmail.com wrote: Thanks Radim! That was a feature I hoped to see since the first time I saw Qgis :) I'm going to check it out rigth now. giovanni 2010/11/5 Radim Blazek radim.bla...@gmail.com: Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
No problem Radim. I think having a rasterprovider layer is of big interest to be able to bind other kind of raster sources (i.e. VTK). What about GDAL? It's 'hard-coded' inside the rasterlayer, but I suppose it will become a raster provider implementation. Isn'it? 2010/11/5 Radim Blazek radim.bla...@gmail.com: I appreciate your interest, but as I said, it is not usable at the moment, with a lot of luck you can display GRASS integer map, but you have to set min/max manually to get reasonable colors. Radim On Fri, Nov 5, 2010 at 10:08 AM, G. Allegri gioha...@gmail.com wrote: Thanks Radim! That was a feature I hoped to see since the first time I saw Qgis :) I'm going to check it out rigth now. giovanni 2010/11/5 Radim Blazek radim.bla...@gmail.com: Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
On Fri, Nov 5, 2010 at 11:35 AM, G. Allegri gioha...@gmail.com wrote: What about GDAL? It's 'hard-coded' inside the rasterlayer, but I suppose it will become a raster provider implementation. Isn'it? Yes, that is one aim. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
