84 support znap format from SNAP

[Simon-van-Diepen]

Adds:

• from_snap_dataset in _io.py and as top level function, capable of reading output .znap archives from SNAP into the same output format as from_binary and from_ds
• snap driver to read_metadata, capable of reading the relevant fields from the output json into familiar formats

from_snap_dataset takes a list of .znap archives as input, and converts them into a single xr.Dataset, where the y and x local coordinate system is replaced with azimuth and range (including offset management), and dates are automatically put in chronological order. The complex layer is recreated from the i (real) and q (imaginary) parts, and any other layers in x/y coordinates are preserved (e.g. h2ph as a (azimuth/range/time) layer and longitude as a (azimuth/range) layer.

[Copilot]

Pull request overview

Adds SNAP .znap ingestion support so SNAP-produced outputs can be read into sarxarray’s standard (azimuth, range, time) stack model, including metadata parsing from SNAP’s JSON.

Changes:

• Added from_snap_dataset(...) to load a list of SNAP .znap archives into a single xr.Dataset, rebuilding complex from i/q and carrying through additional layers.
• Extended read_metadata(..., driver="snap") with a JSON-based parser + new SNAP regex patterns and array-shape handling.
• Added tests and bundled SNAP .znap-style Zarr test fixtures under tests/data/zarrs/....

Reviewed changes

Copilot reviewed 54 out of 65 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
sarxarray/_io.py	Implements from_snap_dataset, SNAP JSON metadata flattening/parsing, and integrates driver="snap" into read_metadata.
sarxarray/conf.py	Adds SNAP metadata key patterns, array-shape hints, and unit conversion settings.
sarxarray/init.py	Exposes from_snap_dataset as a top-level API.
tests/test_io.py	Adds coverage for read_metadata(..., driver="snap") and from_snap_dataset(...).
tests/data/zarrs/20230331-coreg.znap/.zattrs	SNAP Zarr fixture metadata for the 2023-03-31 sample.
tests/data/zarrs/20230331-coreg.znap/.zgroup	Root Zarr group marker for the 2023-03-31 fixture.
tests/data/zarrs/20230331-coreg.znap/SNAP/.zgroup	SNAP sub-group marker for the 2023-03-31 fixture.
tests/data/zarrs/20230331-coreg.znap/SNAP/vector_data/ground_control_points.csv	SNAP vector-data fixture (GCPs).
tests/data/zarrs/20230331-coreg.znap/SNAP/vector_data/pins.csv	SNAP vector-data fixture (pins).
tests/data/zarrs/20230331-coreg.znap/elevation_VV/.zarray	Zarr array metadata for elevation layer.
tests/data/zarrs/20230331-coreg.znap/elevation_VV/.zattrs	Zarr attrs for elevation layer.
tests/data/zarrs/20230331-coreg.znap/i_VV_31Mar2023/.zarray	Zarr array metadata for I (real) layer.
tests/data/zarrs/20230331-coreg.znap/i_VV_31Mar2023/.zattrs	Zarr attrs for I (real) layer.
tests/data/zarrs/20230331-coreg.znap/incident_angle/.zarray	Zarr array metadata for incident angle layer.
tests/data/zarrs/20230331-coreg.znap/incident_angle/.zattrs	Zarr attrs for incident angle layer.
tests/data/zarrs/20230331-coreg.znap/incident_angle/0.0	Binary Zarr chunk for incident angle layer.
tests/data/zarrs/20230331-coreg.znap/latitude/.zarray	Zarr array metadata for latitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/latitude/.zattrs	Zarr attrs for latitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/latitude/0.0	Binary Zarr chunk for latitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/latitude_VV/.zarray	Zarr array metadata for latitude full-res layer.
tests/data/zarrs/20230331-coreg.znap/latitude_VV/.zattrs	Zarr attrs for latitude full-res layer.
tests/data/zarrs/20230331-coreg.znap/longitude/.zarray	Zarr array metadata for longitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/longitude/.zattrs	Zarr attrs for longitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/longitude/0.0	Binary Zarr chunk for longitude tiepoint layer.
tests/data/zarrs/20230331-coreg.znap/longitude_VV/.zarray	Zarr array metadata for longitude full-res layer.
tests/data/zarrs/20230331-coreg.znap/longitude_VV/.zattrs	Zarr attrs for longitude full-res layer.
tests/data/zarrs/20230331-coreg.znap/q_VV_31Mar2023/.zarray	Zarr array metadata for Q (imag) layer.
tests/data/zarrs/20230331-coreg.znap/q_VV_31Mar2023/.zattrs	Zarr attrs for Q (imag) layer.
tests/data/zarrs/20230331-coreg.znap/slant_range_time/.zarray	Zarr array metadata for slant range time layer.
tests/data/zarrs/20230331-coreg.znap/slant_range_time/.zattrs	Zarr attrs for slant range time layer.
tests/data/zarrs/20230331-coreg.znap/slant_range_time/0.0	Binary Zarr chunk for slant range time layer.
tests/data/zarrs/20230319-coreg.znap/.zattrs	SNAP Zarr fixture metadata for the 2023-03-19 sample.
tests/data/zarrs/20230319-coreg.znap/.zgroup	Root Zarr group marker for the 2023-03-19 fixture.
tests/data/zarrs/20230319-coreg.znap/SNAP/.zgroup	SNAP sub-group marker for the 2023-03-19 fixture.
tests/data/zarrs/20230319-coreg.znap/SNAP/vector_data/ground_control_points.csv	SNAP vector-data fixture (GCPs).
tests/data/zarrs/20230319-coreg.znap/SNAP/vector_data/pins.csv	SNAP vector-data fixture (pins).
tests/data/zarrs/20230319-coreg.znap/h2ph_VV_19Mar2023/.zarray	Zarr array metadata for extra h2ph layer.
tests/data/zarrs/20230319-coreg.znap/h2ph_VV_19Mar2023/.zattrs	Zarr attrs for extra h2ph layer.
tests/data/zarrs/20230319-coreg.znap/i_VV_19Mar2023/.zarray	Zarr array metadata for I (real) layer.
tests/data/zarrs/20230319-coreg.znap/i_VV_19Mar2023/.zattrs	Zarr attrs for I (real) layer.
tests/data/zarrs/20230319-coreg.znap/incident_angle/.zarray	Zarr array metadata for incident angle layer.
tests/data/zarrs/20230319-coreg.znap/incident_angle/.zattrs	Zarr attrs for incident angle layer.
tests/data/zarrs/20230319-coreg.znap/incident_angle/0.0	Binary Zarr chunk for incident angle layer.
tests/data/zarrs/20230319-coreg.znap/latitude/.zarray	Zarr array metadata for latitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/latitude/.zattrs	Zarr attrs for latitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/latitude/0.0	Binary Zarr chunk for latitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/longitude/.zarray	Zarr array metadata for longitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/longitude/.zattrs	Zarr attrs for longitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/longitude/0.0	Binary Zarr chunk for longitude tiepoint layer.
tests/data/zarrs/20230319-coreg.znap/q_VV_19Mar2023/.zarray	Zarr array metadata for Q (imag) layer.
tests/data/zarrs/20230319-coreg.znap/q_VV_19Mar2023/.zattrs	Zarr attrs for Q (imag) layer.
tests/data/zarrs/20230319-coreg.znap/slant_range_time/.zarray	Zarr array metadata for slant range time layer.
tests/data/zarrs/20230319-coreg.znap/slant_range_time/.zattrs	Zarr attrs for slant range time layer.
tests/data/zarrs/20230319-coreg.znap/slant_range_time/0.0	Binary Zarr chunk for slant range time layer.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rogerkuou]

Hi @Simon-van-Diepen , I am working on reviewing this PR. I find there are some structural changes I want to suggest. I will do this by opening a new PR to this branch. For now you can ignore the Copilot suggestions. I was using them only as references

[rogerkuou]

Hi @Simon-van-Diepen , while I am working on the suggestion PR, I think I can already make some comments on the test data tests/data/zarrs:

1. It seems the metadata of image 20230319-coreg.znap is not correct. For example in .zattrs the timestamp information is 20230331. Is this error caused by corregistration itself, or by copying the metadata of 20230331? Can we have a small crop but with the corect metadata? (I am asking this because I would like to change the current behavior of getting time information from the datalayer names)
2. The current size of metadata is 7MB, which IMO is still big (spatially 84x338). If possible, can we have a even smaller crop? like 50x50?

Thanks! Meanwhile I will continue working on my suggestion PR.

[rogerkuou]

Hi @Simon-van-Diepen , I made PR #106 as suggestions for from_znap_zarr. Plz have a look on that one! I will continue reviewing the rest after merging it

[rogerkuou]

Hi @Simon-van-Diepen , while I am working on the suggestion PR, I think I can already make some comments on the test data tests/data/zarrs:

1. It seems the metadata of image 20230319-coreg.znap is not correct. For example in .zattrs the timestamp information is 20230331. Is this error caused by corregistration itself, or by copying the metadata of 20230331? Can we have a small crop but with the corect metadata? (I am asking this because I would like to change the current behavior of getting time information from the datalayer names)
2. The current size of metadata is 7MB, which IMO is still big (spatially 84x338). If possible, can we have a even smaller crop? like 50x50?

Thanks! Meanwhile I will continue working on my suggestion PR.

After discussing with Simon:

1. The size is mainly caused by metadata. After checking we did not find a safe way to remove info from it. For now we will just allow it.
2. The time information in the metadata is wrong. This error is likely to be introduced by corregistration processing. We need to fix this from the dataset aspect.

[Simon-van-Diepen]

@rogerkuou could you have another look at this PR?

I have lowered the cognitive complexity of both functions but don't see a clean way to get it below 15, mainly due to various checks that need to be completed.
Compared to your implementation, I have:

• removed the ZNAP_VAR_DAUGHTERS from the config, since that was unused
• fixed the units of two of the SNAP output variables which were still in MHz instead of Hz
• turned the regex patterns of RE_PATTERNS_SNAP_DATALAYER into wildcards, where they can match any layer with the polarisation / polarisation and date present
• Made sure that, like in the documentation, all layers in the x/y grid are saved to the output grid (with the help of the wildcards)
• Changed the reading of the timestamp from the hacked .zattrs metadata which cannot be trusted to the source filenames embedded within the metadata json
• Reverted the hacked metadata timestamp

[rogerkuou]

Hi @Simon-van-Diepen, thanks!

I added more suggestions via #113. I think for complexity it is fine for now. I accept that the metadata flattening function is now 16>15.

Could please see if they make sense?

[Simon-van-Diepen]

Hi @rogerkuou I have taken up all your suggestions, they make sense to me. I added an extra case for if ds_stack is None to _append_mother in case the mother epoch is the only one being read out, and a test to ensure that this functionality remains working. Other than that everything you proposed looked great. Could you have one more look to see if it is good for you as well now?

[rogerkuou]

Hi @Simon-van-Diepen I have one last comment on the function name. After that please feel free to merge. Thanks for this awesome implementation!

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud