question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Float32 data promoted to Float64

See original GitHub issue

I used rio-cogeo to convert a geotiff with 1 band of Type=Float32 geotiff. To my surprise, the output generated was Type=Float64 geotiff. Any idea why that happened and how to keep the data as Type=Float32?

Here’s the actual rio-cogeo command I used:

rio cogeo create --cog-profile lzw Southern_California_Topobathy_DEM_1m.tif Southern_California_Topobathy_DEM_1m_COG.tif

And here’s the gdalinfo for the INPUT file:

Driver: GTiff/GeoTIFF
Files: Southern_California_Topobathy_DEM_1m.tif
       Southern_California_Topobathy_DEM_1m.tif.ovr
       Southern_California_Topobathy_DEM_1m.tif.aux.xml
Size is 316120, 225217
Coordinate System is:
PROJCS["NAD_1983_NSRS2007_UTM_Zone_11N",
    GEOGCS["GCS_NAD_1983_NSRS2007",
        DATUM["NAD_1983_NSRS2007",
            SPHEROID["GRS_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-117],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (179523.999999998224666,3824832.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  DataType=Generic
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  179524.000, 3824832.000) (120d29'26.74"W, 34d30'55.16"N)
Lower Left  (  179524.000, 3599615.000) (120d24'36.73"W, 32d29'15.49"N)
Upper Right (  495644.000, 3824832.000) (117d 2'50.95"W, 34d33'54.85"N)
Lower Right (  495644.000, 3599615.000) (117d 2'47.00"W, 32d32' 1.94"N)
Center      (  337584.000, 3712223.500) (118d44'57.15"W, 33d32'14.24"N)
Band 1 Block=128x128 Type=Float32, ColorInterp=Gray
  Min=-3857.312 Max=3067.828
  Minimum=-3857.312, Maximum=3067.828, Mean=-353.493, StdDev=804.656
  NoData Value=-3.40282306073709653e+38
  Overviews: 79030x56305, 39515x28153, 19758x14077, 9879x7039, 4940x3520, 2470x1760, 1235x880, 618x440, 309x220
  Metadata:
    RepresentationType=ATHEMATIC
    STATISTICS_COVARIANCES=647471.7255957157
    STATISTICS_MAXIMUM=3067.8276367188
    STATISTICS_MEAN=-353.49345874696
    STATISTICS_MINIMUM=-3857.3120117188
    STATISTICS_SKIPFACTORX=1
    STATISTICS_SKIPFACTORY=1
    STATISTICS_STDDEV=804.65627791978

And the gdalinfo for the OUTPUT file:

 Driver: GTiff/GeoTIFF
Files: tmp2cd_5blz.tif
Size is 316120, 225217
Coordinate System is:
PROJCS["NAD_1983_NSRS2007_UTM_Zone_11N",
    GEOGCS["GCS_NAD_1983_NSRS2007",
        DATUM["NAD_1983_NSRS2007",
            SPHEROID["GRS_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-117],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (179523.999999998224666,3824832.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  179524.000, 3824832.000) (120d29'26.74"W, 34d30'55.16"N)
Lower Left  (  179524.000, 3599615.000) (120d24'36.73"W, 32d29'15.49"N)
Upper Right (  495644.000, 3824832.000) (117d 2'50.95"W, 34d33'54.85"N)
Lower Right (  495644.000, 3599615.000) (117d 2'47.00"W, 32d32' 1.94"N)
Center      (  337584.000, 3712223.500) (118d44'57.15"W, 33d32'14.24"N)
Band 1 Block=512x512 Type=Float64, ColorInterp=Gray
  NoData Value=-3.40282306073709653e+38
  Overviews: 158060x112609, 79030x56305, 39515x28153, 19758x14077, 9879x7039, 4940x3520, 2470x1760, 1235x880, 618x440

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:22 (13 by maintainers)

github_iconTop GitHub Comments

1reaction
rsignell-usgscommented, Sep 6, 2019

@vincentsarago , yes, in fact I just used gdal_translate as you suggested:

gdal_translate Southern_California_Topobathy_DEM_1m.tif   \
                       Southern_California_Topobathy_DEM_1m_cog.tif   \
                       -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=LZW -co BIGTIFF=YES

Followed of course by:

rio cogeo validate Southern_California_Topobathy_DEM_1m_cog.tif

😸

BTW, I didn’t know about the super cool service here: https://remotepixel.ca/cogeo.html?url=https://esip-pangeo-uswest2.s3-us-west-2.amazonaws.com/sciencebase/Southern_California_Topobathy_DEM_1m_cog.tif&rescale=-50,2000&color_map=terrain#12.91/33.75184/-117.57867 Two questions:

  1. Is it using the different overviews as you zoom in?
  2. Where can I find the documentation for this RESTful API (what the parameter options are)?
1reaction
vincentsaragocommented, Aug 14, 2019

@rsignell-usgs this is a pure rasterio problem. I’ve opened a ticket over https://github.com/mapbox/rasterio/issues/1744 and hope this get resolved. I’m going to closes this issue but will follow on the rasterio repo

Read more comments on GitHub >

github_iconTop Results From Across the Web

Numpy casting float32 to float64 - python - Stack Overflow
Since a float32 can't hold all values of dtype int32 (or int64), NumPy upgrades to float64 for the first promotion. (float64 can't hold...
Read more >
Data get promoted to float64 when using WarpedVRT #1744
Without a nodata value, you would get "float32". Can you eliminate the nodata value in your case? Or change it to nan ?...
Read more >
8.2 — Floating-point and integral promotion - Learn C++
All numeric promotions are value-preserving, which means that all values in the original type are representable without loss of data or ...
Read more >
Conversion and Promotion · The Julia Language
The third and final rule dictates that promoting a rational with a float results in the same type as promoting the numerator/denominator type...
Read more >
Type Promotion Rules — Python array API standard 2021.12 ...
Behavior is not specified when mixing a Python float and an array with an integer data type; this may give float32 , float64...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found