int64 src and float64 offset results in type error

dshean / demcoreg

Utilities for DEM and point cloud co-registration

MIT License

110 stars 42 forks source link

int64 src and float64 offset results in type error #12

Closed ShashankBice closed 4 years ago

ShashankBice commented 4 years ago

A user reported this error when dz_offset is added to the src_dem_array: TypeError: Cannot cast ufunc add output from dtype('float64') to dtype('int64') with casting rule 'same_kind' .

This happens when src DEM has int values and ref DEM has float values.
I think converting src DEM with int dtype (if present) to float should be harmless here ? Let me know what you think @dshean and I can submit PR.

dshean commented 4 years ago

Ah, OK, thanks for reporting. See also: https://stackoverflow.com/questions/52868835/im-getting-a-typeerror-for-a-b-but-not-b-a-numpy. Somewhere there is a += that can be modified. Casting inputs to float could also work, as long as it doesn't create issues with output dtype when writing to Geotiff.

ShashankBice commented 4 years ago

Ok, that is here: https://github.com/dshean/demcoreg/blob/f133ed6fb2aa88e8b1233a2a8c5c1d8f754e1c10/demcoreg/coreglib.py#L53 . I will check and file PR accordingly tomorrow.

ShashankBice commented 4 years ago

a = a+dz easily fixes the issue, a is promoted to float to facilitate the addition. But when the adjusted masked array is written to disk, the data is again converted to int16 (as the input src_ds is copied to target ds here) and potentially some minimal information used in DEM alignment is lost. If the goal is to just compare the DEM with the reference DEM it was aligned to, it should be ok as users can directly use the *align_diff.tif output elevation difference map, which will still contain floating point values obtained from array differencing (it uses the warped src_dem_crop_ds_align ds as the output ds).

dshean commented 4 years ago

All sounds good. Thanks for looking into this and submitting PR!