[gdal-dev] how can a Geotiff occupy three times the disk space of an ASCII Grid?

G. Allegri giohappy at gmail.com
Sat Jul 5 09:53:56 PDT 2014


The problem was simpler then it appeared: I didn't realize that QGIS output
is Float64.
Yet I don't know why QGIS chosed to use this data type...

giovanni


2014-07-05 17:56 GMT+02:00 Even Rouault <even.rouault at mines-paris.org>:

> Le samedi 05 juillet 2014 17:25:48, G. Allegri a écrit :
> > > QGIS is usually just calls to gdal, which makes this even more
> > > mysterious.
> >
> > Yes, in the end it uses gdal, but it chooses the way blocks are read and
> > written.
> > If I remember correctly geotiff final sizes may depend on block ordering
> > and memory alignment.
>
> In that instance, the target geotiff has a natural block dimension which
> is a
> raster line.
> If QGIS writes the geotiff by 256x256 blocks (this is just a guess. I've
> not
> verified), the same raster line will be written several times. As it is a
> compressed geotiff, the resulting raster line will be each time being
> bigger
> since the initial zeros will be replaced by actual values. And if the new
> size
> of the line is bigger than its previous size, the new line will be
> rewritten
> at the end of the file, losing the space previously occupied.
>
> > Maybe this is the case, QGIS raster provider not doing the best at this
> > level? Don't know, but this discussion is for the QGIS ml ;)
> >
> > giovanni
> >
> > > On 7/5/2014 9:09 AM, G. Allegri wrote:
> > > > I agree with you David, I'm surprised too.
> > > > Anyway, gdal_translate is run without compression options.
> > > > I've written to the QGIS devs (it was the software) to verify what's
> > > > happening with its raster file writer code...
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>



-- 
Giovanni Allegri
http://about.me/giovanniallegri
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140705/6e8d967f/attachment.html>


More information about the gdal-dev mailing list