Changes between Initial Version and Version 1 of Ticket #169, comment 4


Ignore:
Timestamp:
01/09/19 14:34:06 (11 months ago)
Author:
piyush.agram
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #169, comment 4

    initial v1  
    18182. Products generated like these are already by GDAL's HDF5 driver and treated as complex data. See https://github.com/OSGeo/gdal/blob/master/gdal/frmts/hdf5/hdf5dataset.cpp#L407-L448
    1919
    20 3. In general, working with an extra complex dimension seems cumbersome since a lot of SAR/InSAR datasets now are represented as data cubes (acquisitiondate, time, range) or (baseline, time, range) for stacks/ tomograms. It would be lot simpler if queries for dimensions directly returned the sizes instead of us having to check for dimension size of 2 and is_complex. This is a personal preference I guess.
     203. In general, working with an extra complex dimension seems cumbersome since a lot of SAR/InSAR datasets now are represented as data cubes (acquisitiondate, time, range) or (baseline, time, range) or (polarization, time, range) for stacks/ tomograms. It would be lot simpler if queries for dimensions directly returned the sizes instead of us having to check for dimension size of 2 and is_complex. This is a personal preference I guess.
    2121
    22224. I like the idea of is_complex attribute for disambiguation. As an implementer, I would detect a compound data type and confirm with this attribute that the data represents complex numbers.