Upendra Dadi wrote:
> I found this in the r.in.gdal documentation:
>
> "Float32 and Float64 type bands are translated as GRASS floating point
> cells (but not double precision ... this could be added if needed)"
>
> I guess r.out.gdal can translate DCELL_TYPE into Float64. Why is
> Float64 translated to FCELL_TYPE instead DCELL_TYPE? What is the
> reason for the discrepancy?
AFAICT, it's done merely to simplify the code, so that r.in.gdal only
needs to handle two types rather than 3.
It's debatable whether there's any point in using double precision.
Single precision is accurate to better than one part per billion; is
the data really that accurate?
> What should I do to allow transformation of Float64 into DCELL_TYPE?
>
> In main function(using C) for r.in.gdal, there is a function named
> importBand():
>
> eRawGDT = GDALGetRasterDataType(hBand);
>
> switch (eRawGDT) {
> case GDT_Float32:
> case GDT_Float64:
> data_type = FCELL_TYPE;
> eGDT = GDT_Float32;
> complex = FALSE;
> break;
>
> Would re-writing this to the following(and making some changes in the
> subsequent code) wouldn't work?:
>
> case GDT_Float32:
> data_type = FCELL_TYPE;
> eGDT = GDT_Float32;
> complex = FALSE;
> break;
> case GDT_Float64:
> data_type = DCELL_TYPE;
> eGDT = GDT_Float64;
> complex = FALSE;
> break;
That's necessary, but not sufficient; search for GDT_Float32 in the
source code to find a couple of other places where a third case needs
to be added.
--
Glynn Clements <
[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
