@ABraun You mention coregistration here. Is this happening within PolSARPro (PSP) or in SNAP? I’ve not found a coregistration tool within PSP so I’ve been trying to undertake coregistration within SNAP then export to PSP format. However, I’m not quite sure how to do this correctly. The SNAP coregistration tools produce a stack, so I’ve tried Stack Split to give separate files. But this avenue does not seem to allow for the generation of the required binaries when exporting to PSP format. When I do this, all I get is the configuration text file and no binaries.
Any suggestions on a basic Sentinel-1 workflow for ingest into PSP for tomoSAR (I know S-1 may not a suitable sensor for this task, it’s more of a trial data set)? My initial thought was this: Read > ApplyOrbitFile > RadioCal > DeBurst > Coreg > Subset. Thanks for any help
I am not sure how well PolSARpro coregisters the data to be honest. There is a “coarse coregistration” module, but as it says it is probably not accurate enough for PolInSAR approaches. All training material of PolSARpro already refers to well coregistered data products so I guess doing this before is a good idea.
If you want to coregister S1 data you apply BackGeocoding followed by ESD and then you deburst the data.
Yes, “coarse” coregistration does not sound very promising. Thank you for the suggestion. This seem to be a good workflow based on the trial run I did.
However, I’m still running into the issue of not getting the binary files I need. I’m not totally sure if this step is required, but it seems to me the co-registered stack needs to be split in order to be imported into PolSARpro. Any ideas on how this is done correctly? When I use the Stack Split tool, this does in fact split the stack as expected, but when I try to export each constituent into PolSARpro format, all I get in each exported folder is the config.txt file and no binaries.