UAVSAR support

[yunjunz]

Create an issue page here to keep track of the common discussion for UAVSAR (processed with ISCE) data support as there will be several pull requests (#374) for it.

1. YYYYMMDDTHHMMSS time format

• [x] @taliboliver and I agreed on a YYYYMMDDTHHMM string format, e.g. 20200610T1430, because there are multiple UAVSAR acquisitions on the same day. This new time string format will be used for all the time info for UAVSAR datasets, such as the date dataset in the timeseries.h5 and ifgramStack.h5 file.

  @taliboliver is the time info used here in UTC? (yes)

• [ ] We did not include the second info mainly because one SAR image spans multiple seconds (5-15 for space-borne data). I don't have a strong opinion on this. What do you think @hfattahi? Should we use YYYYMMDDTHHMMSS format?

  I would just use the full time "YYYYMMDDTHHMMSS" which can point to the center of the scene.

2. PyAPS support for air-borne data

• [ ] The date and UTC time info from 1 could be passed to PyAPS, we will need to adjust the code in tropo_pyaps3.py for that.

• [ ] The altitude of UAVSAR should be passed to PyAPS as well, and adjustments are needed on both tropo_pyaps3.py and PyAPS.

@dbekaert As I understood, @taliboliver is not using tropospheric correction with PyAPS because his study area is flat so we don't expect ERA5 will help much, thus, adjusting PyAPS to the airborne SAR data is not on the to-do list currently. We welcome contributions if someone else is interested in this.

[dbekaert]

Flat terrain and aps in uavsar will show a range ramp mainly because of incidence angle mapping. Even with topography APS will have strong range dependancy. Agreed that beyond the ramp the model will be too coarse to provide detailed correction. Swath is also pretty narrow.

[hfattahi]

I would just use the full time "YYYYMMDDTHHMMSS" which can point to the center of the scene.

[yunjunz]

Sounds good @hfattahi, let's do that then.