<div dir="ltr">Given that an ASCII Grid doesn't provide a data type, maybe the driver choose the larger one, while the utilities guess it trying to fit the values into a smaller type?<div><br></div><div>giovanni</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-05 20:31 GMT+02:00 G. Allegri <span dir="ltr"><<a href="mailto:giohappy@gmail.com" target="_blank">giohappy@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I've debugged it, and it gets Float64 directly from GDALGetRasterDataType( GDALRasterBandH ).<div>I've also tried opening it with Python GDAL and I get Float64.</div><div>gdalinfo tells me Float32.</div>

<div>I will try to send you a subset of it. It's not easy, as it is a heavy ASCII Grid and I don't want to alter it.</div><div><br></div><div>giovanni</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

2014-07-05 20:22 GMT+02:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span>:<div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Le samedi 05 juillet 2014 20:18:50, G. Allegri a écrit :<br>
<div>> Finally I've reached the point: GDAL's driver is opening the ASCII as<br>
> Float64, consequently QGIS treats it this way.<br>
> I wonder why gdalinfo and gdal_translate treat it as Float32 instead....<br>
<br>
</div>If gdalinfo opens it as Float32, then it is Float32 for everybody. I guess<br>
QGIS probably promotes Float32 to Float64.<br>
<div><div><br>
><br>
> giovanni<br>
><br>
> 2014-07-05 18:53 GMT+02:00 G. Allegri <<a href="mailto:giohappy@gmail.com" target="_blank">giohappy@gmail.com</a>>:<br>
> > The problem was simpler then it appeared: I didn't realize that QGIS<br>
> > output is Float64.<br>
> > Yet I don't know why QGIS chosed to use this data type...<br>
> ><br>
> > giovanni<br>
> ><br>
> ><br>
> > 2014-07-05 17:56 GMT+02:00 Even Rouault <<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>>:<br>
> ><br>
> > Le samedi 05 juillet 2014 17:25:48, G. Allegri a écrit :<br>
> >> > > QGIS is usually just calls to gdal, which makes this even more<br>
> >> > > mysterious.<br>
> >> ><br>
> >> > Yes, in the end it uses gdal, but it chooses the way blocks are read<br>
> >> > and written.<br>
> >> > If I remember correctly geotiff final sizes may depend on block<br>
> >> > ordering and memory alignment.<br>
> >><br>
> >> In that instance, the target geotiff has a natural block dimension which<br>
> >> is a<br>
> >> raster line.<br>
> >> If QGIS writes the geotiff by 256x256 blocks (this is just a guess. I've<br>
> >> not<br>
> >> verified), the same raster line will be written several times. As it is<br>
> >> a compressed geotiff, the resulting raster line will be each time being<br>
> >> bigger<br>
> >> since the initial zeros will be replaced by actual values. And if the<br>
> >> new size<br>
> >> of the line is bigger than its previous size, the new line will be<br>
> >> rewritten<br>
> >> at the end of the file, losing the space previously occupied.<br>
> >><br>
> >> > Maybe this is the case, QGIS raster provider not doing the best at<br>
> >> > this level? Don't know, but this discussion is for the QGIS ml ;)<br>
> >> ><br>
> >> > giovanni<br>
> >> ><br>
> >> > > On 7/5/2014 9:09 AM, G. Allegri wrote:<br>
> >> > > > I agree with you David, I'm surprised too.<br>
> >> > > > Anyway, gdal_translate is run without compression options.<br>
> >> > > > I've written to the QGIS devs (it was the software) to verify<br>
> >> > > > what's happening with its raster file writer code...<br>
> >><br>
> >> --<br>
> >> Geospatial professional services<br>
> >> <a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
> ><br>
> > --<br>
> > Giovanni Allegri<br>
> > <a href="http://about.me/giovanniallegri" target="_blank">http://about.me/giovanniallegri</a><br>
> > Twitter: <a href="https://twitter.com/_giohappy_" target="_blank">https://twitter.com/_giohappy_</a><br>
> > blog: <a href="http://blog.spaziogis.it" target="_blank">http://blog.spaziogis.it</a><br>
> > GEO+ geomatica in Italia <a href="http://bit.ly/GEOplus" target="_blank">http://bit.ly/GEOplus</a><br>
<br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</div></div></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Giovanni Allegri<br><a href="http://about.me/giovanniallegri" target="_blank">http://about.me/giovanniallegri</a><div>
Twitter: <a href="https://twitter.com/_giohappy_" target="_blank">https://twitter.com/_giohappy_</a></div>
<div>blog: <a href="http://blog.spaziogis.it" target="_blank">http://blog.spaziogis.it</a><br>GEO+ geomatica in Italia <a href="http://bit.ly/GEOplus" target="_blank">http://bit.ly/GEOplus</a></div></div>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Giovanni Allegri<br><a href="http://about.me/giovanniallegri" target="_blank">http://about.me/giovanniallegri</a><div>Twitter: <a href="https://twitter.com/_giohappy_" target="_blank">https://twitter.com/_giohappy_</a></div>
<div>blog: <a href="http://blog.spaziogis.it" target="_blank">http://blog.spaziogis.it</a><br>GEO+ geomatica in Italia <a href="http://bit.ly/GEOplus" target="_blank">http://bit.ly/GEOplus</a></div></div>
</div>