Support loading polygon shapes from SpatialData

[keller-mark]

User story

User has segmentations that are represented using polygon shapes within a SpatialData object. User wants to visualize these segmentations using Vitessce without converting them to a different data format/representation.

Preferred solution

Implement a new FileType and data loader class that returns the polygon shapes as the obsSegmentations data type with obsSegmentationsType === 'polygon'

vitessce/packages/types/src/data-types.ts

Line 59 in 40fe260

export type ObsSegmentationsPolygons = {

This will require knowledge of how the SpatialData stores Shape elements on-disk. Some relevant resources that may help are:

• https://spatialdata.scverse.org/en/latest/design_doc.html#shapes
• https://github.com/scverse/spatialdata/blob/643b845658b39f23ab84db32f0443d6ea91da98c/src/spatialdata/_io/io_shapes.py#L51

Relevant places in the code:

• Vitessce currently supports loading Circle shapes from SpatialData, using the obsSpots data type:
  • https://github.com/vitessce/vitessce/blob/main/packages/file-types/zarr/src/SpatialDataShapesSource.js
  • https://github.com/vitessce/vitessce/blob/main/packages/file-types/zarr/src/spatialdata-loaders/SpatialDataObsSpotsLoader.js
• Vitessce also supports loading polygon segmentations from JSON files:
  • https://github.com/vitessce/vitessce/blob/main/packages/file-types/json/src/json-loaders/ObsSegmentationsJson.js

Possible alternatives

[LucaMarconato]

A note on this. For the disk representation of shapes we plan to transition from using the GeoPandas ragged-array representation (Zarr) to the GeoParquet representation, also supported natively by GeoPandas. This change would be beneficial for interoperability because the GeoParquet is widely supported.

Practically, from the Python side it will amount to use to_parquet() and read_parquet() from geopandas, but we haven't done it yet because we need to do in a backward compatible way and also providing a data migration CLI (the data migration will be lightweight because the heavy data are images, labels and tables; all of which have a stable data format that will not change).

I think therefore that for this hackathon we could already try the GeoParquet representation if it makes the implementation easier, and then add the support for the current version.