TerraSAR-X Data: SNAP and the COSAR Format


I am looking for a way to make SNAP read TS-X data that I have modified in some ways.

I have written Python code to read a TS-X stripmap product (from a *.cos file) and to perform some modifications on it. Now I would like to save the modified data back to a *.cos file (i.e., in COSAR format) so that I can treat the modified product just like any other TS-X product; I want to process it using SNAP.

Unfortunately, the GDAL COSAR driver only supports reading, but not writing. Hence, I tried to save the data as GeoTIFF because the corresponding GDAL driver is much more versatile. Alas, I can’t get SNAP to read the modified data if it’s saved as GTIFF. I suppose that’s because SNAP expects a certain structure for TS-X products.

Thus, I see two possible paths for my problem:

  1. Find a way to write SAR-data in COSAR format (ideally in Python). Perhaps there is some alternative to GDAL which I just haven’t found yet? I also checked the TS-X L1b product specifications to check the COSAR file structure. I guess I could write my own code to try to emulate the file structure, but that looks like a rabbit hole I really don’t want to go down. Surely there must be some library containing a suitable driver?

  2. Find a way to make SNAP read TS-X products when complex data is saved as GeoTIFF (or some other format for which the GDAL driver supports writing). Does anyone know what I can do to tell SNAP that the GTIFF I’m feeding it contains an SSC product? I think when SNAP sees a GTIFF in a TS-X product it automatically expects MGD data.

Does anyone have any clue for either of the strategies? I would appreciate any hints and tips! :slight_smile:



In general, BEAM DIMAP is the preferred format for saving data that will be loaded in SNAP. Since metadata are ASCII and images are a GDAL supported format, you may be able to write a suitable BEAM DIMAP with Python. There is also ESA SNAP snappy, which can write BEAM DIMAP, but you will have some work to define the product in snappy. If you are copying an existing product format, you may be able to load the existing product, update the data, and save as BEAM-DIMAP. NetCDF4-CF also has good metadata support and excellent 3rd party support. For large data, NetCDF4 internal compression can be a huge advantage over BEAM DIMAP, but you may have to build libaec, hdf5, and netcdf4 yourself as libaec is not yet widely supported (it is available in current Fedora or Debian linux and cygwin64) due lingering effects of the now obsolete szip library license. I have used python to add bands to an existing NASA level-2 netcdf file (but some NASA applications at the time still looked for metadata in a “products.xml” file even though the metadata were in the netcdf file).

Thanks for your reply, I think BEAM-DIMAP is the way to go. I will try to write my own code to write data in the BEAM-DIMAP as I have had some bad experiences with snappy relating to memory issues (I’m working on stacks of more than 20 images; see this issue: Snappy not freeing memory).