Xenium Reader now filters out invalid polygons

[timtreis]

No description provided.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.16%. Comparing base (6be7296) to head (091c5f3).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #283      +/-   ##
==========================================
- Coverage   55.23%   55.16%   -0.07%     
==========================================
  Files          26       26              
  Lines        2848     2844       -4     
==========================================
- Hits         1573     1569       -4     
  Misses       1275     1275              

Files with missing lines	Coverage Δ
src/spatialdata_io/readers/xenium.py	72.37% <ø> (-0.33%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LucaMarconato]

Thanks Tim. I'll make a minor change: I'll filter the data in the function that reads the polygons, to avoid to read the polygon data twice.

[LucaMarconato]

Can you point to some data to reproduce the behavior? I'd like to test that the polygons with 3 vertices are really degenerate and not triangles that can be closed.

[LucaMarconato]

For polygons with 4 vertices the problem could be the line

    def _poly(arr: ArrayLike) -> Polygon:
        return Polygon(arr[:-1])

[LucaMarconato]

I investigated this issue. As shown in the example here kharchenkolab/Baysor#153 (comment), the problem does not seem to originate from degenerate polygons. Instead, it arises from the fact that in the nucleus_boundaries.parquet and cells_boundaries.parquet files, polygons are typically represented as a list of rows where the x, y, and coordinates described by the first and last rows are identical, while in a specific version of Baysor (now patched), the last row was omitted.

The constructor Polygon() accepts both versions, but due to the code

    def _poly(arr: ArrayLike) -> Polygon:
        return Polygon(arr[:-1])

when a polygon was a triangle, the unusual version with the last row omitted triggered the reported bug.

The fact that the polygons are not degenerate is also emphasized by this comment #245 (comment), which states that the associated table data is valid.

As a result, a patch is simpler to implement, allowing to avoid filtering the table. If future users report issues with degenerate polygons during parsing, we can implement some variation of the code for filtering the table in the commit history of this PR. However, I do not think such problems will arise.