Very low PS detected

[renierlgv]

I've been running small dolphin projects recently to get use to it but there are a number of issues I've faced on the way (will be happy to share/discuss about them). However, for "successful" runs I am having a systematic problem, ie, extremely few or non PS are detected. As an example I show the figures in the attachment showing a small town (ROI) which although surrounded by agricultural field has plenty of high to low densely populated buildings as from the Copernicus LULC data, therefore, I was expecting to see way more PS. The amplitude dispersion (AD) looks about right, yet it looks a bit too high at certain locations with buildings, road, etc. The temporal coherence (TC) on the other hand looks all right to me, so, Im having hard times to wrap all things together to understand where the lack of PS is coming from. Again, this is just one example of a few with more or less the same results in terms of PS identification. Any help in understanding and potentially fixing the issue will be appreciated.

[scottstanie]

Hi @renierlgv , thanks for sharing! please do feel free to post bugs as you have time.

• What is the data source/ what was the method for coregistering your SLC stack?
• How many images did you have in your stack?

My initial thoughts when there are low PS:

1. Having one "outlier bad data" image in the stack and make the whole amplitude dispersion look very high, but the phase linking part can successfully ignore if more easily (that is, the temporal coherence stays relatively high if you have one complete garbage data)
2. with all good data, if you have a very high number of images, if can be hard to have low amplitude dispersion for the default threshold (which is an okay-ish number for like 30-80 images). A fix if you have a huge stack: raise the threshold to like 0.3-0.4. If a pixel has 0.4 dispersion after 100 images, that's pretty reliably good. The low 0.25 number was to be cautious around small stack sizes or 15-20
3. amplitude dispersion is sort of a weak metric, and dolphin right now just has that simple measure. there can be other, more sophisticated PS selectors added in the future.

[renierlgv]

Hello @scottstanie Thank you for the quick reply.
Answering your questions:

• I am using SLC products downloaded with asf_search as the BURST products in my area go back to ~2020.
• Im using 400+ slices covering 2016-2026 to avoid issues with earlier datasets

I will try with a more relaxed AD threshold. Indeed I was using 0.2 in my setups which for these large stack seems to be too restrictive.

Reading the discussions I've found that some of the issues I faced seems to be resolved or will be resolved in the next update, ie,:

• ministack growing out of control
• additional options to mask final velocity field

A couple I still haven'e seen resolved or work in progress are:

• for a stack of the entire catalogue for a project of about a full slice size, the number of bursts is beyond the limit for "ls" command, so, the configuration file creation fails. probably listing the files with find or similar will make the trick
• this one is from sweets, but it will be good to have the 3 cosine directors in the geometry folder or at least incidence angle to estimate "los_up" in ground geometry along with the currently available files los_east and los_north. If I'm right, the incidence angle is only available in radar coordinates
• This one is probably on me (it was working before my last installation with pixi) but it will be probably good to have a look at how the crlb files are created/compressed as I get this error:
  packages/rasterio/init.py", line 366, in open
      dataset = writer(
                ^^^^^^^
    File "rasterio/_io.pyx", line 1636, in rasterio._io.DatasetWriterBase.init
    File "rasterio/_base.pyx", line 967, in rasterio._base.DatasetBase.meta.get
    File "rasterio/_base.pyx", line 506, in rasterio._base.DatasetBase.dtypes.get
    File "rasterio/_base.pyx", line 176, in rasterio._base._band_dtype
  KeyError: 15
  I think this is on me because I get this answer from chatgpt:
  Your run completes phase-linking, then crashes when Dolphin tries to repack the CRLB GeoTIFFs “for more compression”:
  Dolphin calls io.repack_rasters(..., use_16_bits=True) for the CRLB outputs.
  use_16_bits=True sets the GeoTIFF creation option NBITS=16 (intended to store float rasters at reduced precision).
  With newer GDAL builds, that “16-bit float-ish” pathway can result in GDAL reporting a raster band type that Rasterio doesn’t know how to map. Rasterio then throws:
  KeyError: 15 coming from Rasterio’s “GDAL datatype → numpy dtype” mapping (i.e., an unknown GDAL datatype code 15 in your Rasterio build). This matches the fact that Rasterio’s dtype mapping (even on mainline) does not include a datatype key 15.
  GDAL has been adding new datatypes (e.g., Float16 / CFloat16 in recent GDAL releases), which is exactly the kind of mismatch that can trigger this

So, it seems its my gdal/rasterio versions compatibility issues which may require pre defined locked versions of the packages. Similar issue for the phase closure files

Thank you again for the help

After implementing your suggestion one more arrises:

• Why there is such a shift between the location of ground objects, ie, power lines and PS locations (see attachment). I spect some potential geometrical artifacts from the looking geometry but not some ~50 meters shift