GRASS raster reading to QGIS 1.0.0 Kore

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GRASS raster reading to QGIS 1.0.0 Kore

Patrick Giraudoux
Dear all,

I am working on Ubuntu Hardy. I have just updated from QGIS Metis to
Kore 1.0.0, and to my surprise, GRASS raster reading has become
extremely slow, whatever the context (QGIS launched withing GRASS 6.3 or
from outside). Even small rasters take minutes before being displayed
(against fraction of second on Metis).

Otherwise, raster import (eg tif) is working OK when GRASS is not
concerned...

Any idea about what is happening ?

Patrick



_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

patrick_giraudoux.vcf (406 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GRASS raster reading to QGIS 1.0.0 Kore

Patrick Giraudoux
Seems that I can narrow the question now. Actually, QGIS Kore reads
GRASS maps well except when the maps  have been created from raster ramp
color have been optimized with i.landsat.rgb. For example in GRASS:

r.composite r=etm7 g=etm5 b=etm2 out=south752brut

makes a map 'south752brut' which is well read within QGIS

Now if I do:
i.landsat.rgb r=etm7 g=etm5 b=etm2
r.composite r=etm7 g=etm5 b=etm2 out=south752opt

it makes a map 'south752opt' which is extremly long to read (several
minutes), and when read makes change (displacement, zoom, etc...)
extremely long to be displayed at a speed that prevent any work

However, 'south752opt' and 'south752brut' are quick/normally displayed
both at the same speed when on work within GRASS (e.g. d.rast south752opt)

Any hint ?

Patrick



Patrick Giraudoux a écrit :

> Dear all,
>
> I am working on Ubuntu Hardy. I have just updated from QGIS Metis to
> Kore 1.0.0, and to my surprise, GRASS raster reading has become
> extremely slow, whatever the context (QGIS launched withing GRASS 6.3
> or from outside). Even small rasters take minutes before being
> displayed (against fraction of second on Metis).
>
> Otherwise, raster import (eg tif) is working OK when GRASS is not
> concerned...
>
> Any idea about what is happening ?
>
> Patrick
>
>

_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

patrick_giraudoux.vcf (406 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: GRASS raster reading to QGIS 1.0.0 Kore

Martin Dobias
2009/1/4 Patrick Giraudoux <[hidden email]>:

> Seems that I can narrow the question now. Actually, QGIS Kore reads GRASS
> maps well except when the maps  have been created from raster ramp color
> have been optimized with i.landsat.rgb. For example in GRASS:
>
> r.composite r=etm7 g=etm5 b=etm2 out=south752brut
>
> makes a map 'south752brut' which is well read within QGIS
>
> Now if I do:
> i.landsat.rgb r=etm7 g=etm5 b=etm2
> r.composite r=etm7 g=etm5 b=etm2 out=south752opt
>
> it makes a map 'south752opt' which is extremly long to read (several
> minutes), and when read makes change (displacement, zoom, etc...) extremely
> long to be displayed at a speed that prevent any work
>
> However, 'south752opt' and 'south752brut' are quick/normally displayed both
> at the same speed when on work within GRASS (e.g. d.rast south752opt)
>
> Any hint ?

Hi Patrick,

we're using GDAL library to access GRASS rasters, so the problem may
be there. I would suggest you to try reading the raster in some other
GDAL-based software [1] to see whether it also suffers slow
performance. If so, file a bug for GDAL, if the problem happens only
in QGIS file a ticket for QGIS with details.

Martin

[1] https://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: GRASS raster reading to QGIS 1.0.0 Kore

Patrick Giraudoux
Martin Dobias a écrit :
2009/1/4 Patrick Giraudoux [hidden email]:
  
Seems that I can narrow the question now. Actually, QGIS Kore reads GRASS
maps well except when the maps  have been created from raster ramp color
have been optimized with i.landsat.rgb. For example in GRASS:

r.composite r=etm7 g=etm5 b=etm2 out=south752brut

makes a map 'south752brut' which is well read within QGIS

Now if I do:
i.landsat.rgb r=etm7 g=etm5 b=etm2
r.composite r=etm7 g=etm5 b=etm2 out=south752opt

it makes a map 'south752opt' which is extremly long to read (several
minutes), and when read makes change (displacement, zoom, etc...) extremely
long to be displayed at a speed that prevent any work

However, 'south752opt' and 'south752brut' are quick/normally displayed both
at the same speed when on work within GRASS (e.g. d.rast south752opt)

Any hint ?
    

Hi Patrick,

we're using GDAL library to access GRASS rasters, so the problem may
be there. I would suggest you to try reading the raster in some other
GDAL-based software [1] to see whether it also suffers slow
performance. If so, file a bug for GDAL, if the problem happens only
in QGIS file a ticket for QGIS with details.

Martin

[1] https://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal

  
Ok. I will try and come back with the result ASAP.

Additionally before your mail I have made some other trials that may (?) help to understand what happens... Looks like corroborating your suspicion about bad interactions between rgdal and qgis. When I export the file using r.out.gdal format=GTiff and then try and read the tif file externally from QGIS, I have the same (bad/slow) result as when reading the grass file from QGIS within GRASS. Then, if I export the GRASS file with r.out.tiff I get a file which is easily read from QGIS and correctly (quickly) displayed as a three band tif object (as an external raster, of course). Furthermore, what surprises me is that when I read a raster GRASS file created with r.composite within QGIS, I get a 1-grey band file  with "color palette" ("palette de couleur" in French) activated in the "properties" box of the layer (however, I was more expecting a three band rgb).

Do those info put you a bit more clearly on the track ?

Thanks for your ideas and advice to where to adress the trouble...

Patrick





_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user

patrick_giraudoux.vcf (406 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: GRASS raster reading to QGIS 1.0.0 Kore

pcav
Patrick Giraudoux ha scritto:
> Do those info put you a bit more clearly on the track ?

This (rather intricated, IMV) issue has been extensively discussed on
GRASS ML, so I suggest you to search there to better understand what's
going on.
It does not seem a QGIS problem, however.
All the best.
pc
--
Paolo Cavallini: http://faunalia.it/pc
_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: GRASS raster reading to QGIS 1.0.0 Kore

Micha Silver
In reply to this post by Patrick Giraudoux
Patrick Giraudoux wrote:

> Martin Dobias a écrit :
>> 2009/1/4 Patrick Giraudoux <[hidden email]>:
>>  
>>> Seems that I can narrow the question now. Actually, QGIS Kore reads GRASS
>>> maps well except when the maps  have been created from raster ramp color
>>> have been optimized with i.landsat.rgb. For example in GRASS:
>>>
>>> r.composite r=etm7 g=etm5 b=etm2 out=south752brut
>>>
>>> makes a map 'south752brut' which is well read within QGIS
>>>
>>> Now if I do:
>>> i.landsat.rgb r=etm7 g=etm5 b=etm2
>>> r.composite r=etm7 g=etm5 b=etm2 out=south752opt
>>>
>>> it makes a map 'south752opt' which is extremly long to read (several
>>> minutes), and when read makes change (displacement, zoom, etc...) extremely
>>> long to be displayed at a speed that prevent any work
>>>
>>> However, 'south752opt' and 'south752brut' are quick/normally displayed both
>>> at the same speed when on work within GRASS (e.g. d.rast south752opt)
>>>
>>> Any hint ?
>>>    
>>
>> Hi Patrick,
>>
>> we're using GDAL library to access GRASS rasters, so the problem may
>> be there. I would suggest you to try reading the raster in some other
>> GDAL-based software [1] to see whether it also suffers slow
>> performance. If so, file a bug for GDAL, if the problem happens only
>> in QGIS file a ticket for QGIS with details.
>>
>> Martin
>>
>> [1] https://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal
>>
>>  
> Ok. I will try and come back with the result ASAP.
>
> Additionally before your mail I have made some other trials that may
> (?) help to understand what happens... Looks like corroborating your
> suspicion about bad interactions between rgdal and qgis. When I export
> the file using r.out.gdal format=GTiff and then try and read the tif
> file externally from QGIS, I have the same (bad/slow) result as when
> reading the grass file from QGIS within GRASS. Then, if I export the
> GRASS file with r.out.tiff I get a file which is easily read from QGIS
> and correctly (quickly) displayed as a three band tif object (as an
> external raster, of course). Furthermore, what surprises me is that
> when I read a raster GRASS file created with r.composite within QGIS,
> I get a 1-grey band file  with "color palette" ("palette de couleur"
> in French) activated in the "properties" box of the layer (however, I
> was more expecting a three band rgb).
>
> Do those info put you a bit more clearly on the track ?
>
> Thanks for your ideas and advice to where to adress the trouble...
>
> Patrick
>
Some months ago there was discussion on this list pointing to two
possible reasons for slow rendering of rasters:
http://www.mail-archive.com/qgis-user@.../msg00813.html
One was tiled rasters. For some reason it seemed like rasters with tiles
(created with gdal_translate -co "TILED=YES") rendered somewhat slowly.
The second problem was incorrect CRS headers in the raster. Setting the
correct projection header with gdalwarp caused tiffs to render faster.
I don't know if this is relevant to your case. (Does i.landsat.rgb set
CRS headers??) But it's worth checking.
--
Micha
 

>
>
>
>
>
> This mail was received via Mail-SeCure System.
>
> _______________________________________________
> Qgis-user mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
>
> This mail was received via Mail-SeCure System.
>
>  

_______________________________________________
Qgis-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-user