Lack of symmetry between shapes and points in on-disk format

[Bisaloo]

(Feel free to transfer this issue if it'd be more appropriate in https://github.com/scverse/spatialdata-io.)

While working on HelenaLC/spatialdataR#198, I noticed that shapes and points are not treated the same in the on-disk representation of SpatialData:

• shapes are in shapes/layer_name/shapes.parquet
• points are points/layer_name/points.parquet/part.0.parquet

Is this intended & desirable that the actual parquet file is stored one level deeper for points than for shapes? Conceptually, I don't see any reasons why they shouldn't be stored based exactly on the same path constructor. The current situation seems like a technical constraint has driven the file tree structure.

[LucaMarconato]

Thanks for highlighting this. Points are saved as pure parquet files (using dask's APIs), while shapes are saved as geoparquet files, using geopandas APIs. I agree that an unification of the format would be beneficial, ideally geoparquet. When we tried using geoparquet for points, it was significantly slower than using plan parquet. We could dig deeper info this.

[Bisaloo]

I think the issue is related but it could also be treated independently from which format & backend are used.

It should be possible to ensure both paths look the same even if one of the parquet file is geoparquet and the other standard parquet.