Currently, nisarqa's geocode_radar_raster() only supports real-valued input arrays. Additionally, the function is hardcoded to output float64 arrays. In the future, it'd be great to update this function to support different dtypes, including complex-valued input arrays.
The Issue: Currently in the isce3 code for geocode cov, all the necessary type overloads have python bindings, but they all have different names. This would require QA to similarly account for all of those different type overloads; this would bloat the QA code, and currently there is not a strong enough use case. Ideally, ISCE3 would be updated with a generic Python wrapper to handle this, and then QA could simply call that wrapper.
A benefit: Once this is implemented, then the generation logic and resampling method for RIFG's LATLON browse PNG could be revisited. Currently, we must use nearest neighbors resampling to avoid artifacts from interpolating at the phase jumps. After this improvement is implemented, we could easily geocode the complex-valued wrapped interferogram, and then use alternative resampling methods.
--
After writing this comment, we looked at the icse3 code and it turns out that currently all the necessary type overloads have python bindings, but they all have different names. So we'd probably want to add a generic wrapper to isce3 that handles the type dispatch under the hood. (I'd recommend that this wrapper also implement a proper constructor, but that's another story.) Once that's released then nisarqa could get rid of the hard-coded Float64 in this method, which would expand our options for reprojecting wrapped phase layers.
Originally posted by @bhawkins in #161 (comment)
Currently,
nisarqa'sgeocode_radar_raster()only supports real-valued input arrays. Additionally, the function is hardcoded to output float64 arrays. In the future, it'd be great to update this function to support different dtypes, including complex-valued input arrays.The Issue: Currently in the
isce3code for geocode cov, all the necessary type overloads have python bindings, but they all have different names. This would require QA to similarly account for all of those different type overloads; this would bloat the QA code, and currently there is not a strong enough use case. Ideally, ISCE3 would be updated with a generic Python wrapper to handle this, and then QA could simply call that wrapper.A benefit: Once this is implemented, then the generation logic and resampling method for RIFG's LATLON browse PNG could be revisited. Currently, we must use nearest neighbors resampling to avoid artifacts from interpolating at the phase jumps. After this improvement is implemented, we could easily geocode the complex-valued wrapped interferogram, and then use alternative resampling methods.
--
After writing this comment, we looked at the icse3 code and it turns out that currently all the necessary type overloads have python bindings, but they all have different names. So we'd probably want to add a generic wrapper to isce3 that handles the type dispatch under the hood. (I'd recommend that this wrapper also implement a proper constructor, but that's another story.) Once that's released then nisarqa could get rid of the hard-coded Float64 in this method, which would expand our options for reprojecting wrapped phase layers.
Originally posted by @bhawkins in #161 (comment)