subset.py: support --lat/lon in radar coordinates
#1238
Conversation
+ `coord.geo2radar()`: use smaller search range (x/y_factor) for more accurate conversion. Tests based on Sentinel-1 miaplpy dataset show this change brings the conversion accuracy to the sub-pixel level. + `subset`: support subsetting radar-coded files using lat/lon - revert the change in `subset_input_dict2box()` to remain its simplicity as described in the comment. - `read_aux_subset2inps()`: add the code body to to convert bbox in lat/lon to bbox in y/x for radar-coded files + `cli/subset`: add usage example for radar-coded files
subset.py: support --lat/lon in radar coordinates
yunjunz
left a comment
There was a problem hiding this comment.
Thank you @falkamelung for the PR. Your test on the buffer at #1232 is also very helpful. I modified your code a little bit to make them more compact. The changes look all good to me now.
It seems good. Do I need to update the current version? |
If you would like to use this new functionality, yes, I recommend updating your installation to this latest development version. |
+ objects.coord.coordinate._get_lookup_row_col(): if the given y/x_factor is too small, resulting in no overlap area, then iterate with larger y/x_factor values. This fixes the bug introduced in insarlab#1238, which reduced the default y/x_factor from 10 to 4. + tropo_pyaps3: fix a bug introduced by insarlab#1364 + prep_aria: remove the print out msg for a more informative print out msg, which was duplicated.
+ `objects.coord.coordinate._get_lookup_row_col()`: if the given `y/x_factor` is too small, resulting in no overlap area, then iterate with larger `y/x_factor` values. This fixes the bug introduced in #1238, which reduced the default y/x_factor from 10 to 4. + `tropo_pyaps3`: fix a bug introduced by #1364, which did not specify the full path to the `~/.netrc` file. + `prep_aria`: remove the redundant print out msg for a nicer print out msg.
Description of proposed changes
This PR addresses this issue:
#1232
Reminders