Closed LiangJYu closed 1 year ago
@LiangJYu In the context of providing information debugging, what do you think about printing out the burst ID to the logger? maybe somewhere in the lines below?
@LiangJYu In the context of providing information debugging, what do you think about printing out the burst ID to the logger? maybe somewhere in the lines below?
I like the idea. I don't immediately see a clean way of doing it though. Will stew on this...
@LiangJYu In the context of providing information debugging, what do you think about printing out the burst ID to the logger? maybe somewhere in the lines below? https://github.com/opera-adt/COMPASS/blob/643b951efb0f2763b104163365fae7515f52d6f4/src/compass/s1_geocode_slc.py#L95-L98
I like the idea. I don't immediately see a clean way of doing it though. Will stew on this...
@seongsujeong rather than passing around the burst ID so open_raster
what do you think about adding the following call somewhere after the block you linked above?
info_channel.log(f"Starting geocoding of {burst_id} for {date_str}")
This keeps open_raster
general while adding log info that can facilitate log readability.
@LiangJYu In the context of providing information debugging, what do you think about printing out the burst ID to the logger? maybe somewhere in the lines below? https://github.com/opera-adt/COMPASS/blob/643b951efb0f2763b104163365fae7515f52d6f4/src/compass/s1_geocode_slc.py#L95-L98
I like the idea. I don't immediately see a clean way of doing it though. Will stew on this...
@seongsujeong rather than passing around the burst ID so
open_raster
what do you think about adding the following call somewhere after the block you linked above?info_channel.log(f"Starting geocoding of {burst_id} for {date_str}")
This keeps
open_raster
general while adding log info that can facilitate log readability.
I like that implementation. Thanks :)
Not sure if you like the idea. But if we can exploit this PR for the last fix, can we comment out or remove the couple of lines in validate_product.py
? I've found that this is necessary for the static layer products from CAL/VAL SAS.
Not sure if you like the idea. But if we can exploit this PR for the last fix, can we comment out or remove the couple of lines in
validate_product.py
? I've found that this is necessary for the static layer products from CAL/VAL SAS.
Done. PR title edited reflect expanded scope.
This PR:
gdal.Open
incompass.utils.helpers.open_raster
withtry/catch
and provide meaningful error message on failurevalidate_product
gdal.Open
tries to load a rdr2geo ENVI binary whose 1st two bytes match those of a JPG by usinggdal.OpenEx
after firsttry/except