Float32 data promoted to Float64
See original GitHub issueI 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:
- Created 4 years ago
- Reactions:1
- Comments:22 (13 by maintainers)
Top 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 >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@vincentsarago , yes, in fact I just used
gdal_translate
as you suggested:Followed of course by:
😸
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:
@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