scverse / scverse/spatialdata

Explicit intrinsic coordinate system for points and shapes

Open
#169 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
394
Forks
95
Avg merge
4d 3h
Merged PRs (30d)
7

Description

Shapes and points have an intrinsic coordinate system, i.e. what coordinate system are the coordinate values in.

This is noted in the design doc:

Each set of polygons is associated with a coordinate system.

However we currently are not explicit about what this coordinate system is. I think we should be, and have a "coordinate_system" field for the PointModel and ShapeModel.

To figure out what coordinate system points or polygons are defined in, we can sort of figure it out by looking through the coordinate transforms seeing which transformation is an identity transform. But there's no restrictions ensuring this is unique.

I think having an explicit intrinsic coordinate system for these elements would be very useful for figuring out what default coordinate system operations should be performed in.

Example: Polygon aggregations

A needed feature in https://github.com/scverse/spatialdata/pull/162 is figuring out whether two things are in the same space, or if we can transform one to another's space.

I think the ideal way to do this is:

values_coordinate_system = get_native_coordinate_system(values)
by_coordinate_system = get_native_coordinate_system(by)
if values_coordinate_system != by_coordinate_system:
    by = get_transform(by, values_coordinate_system).transform(by)

This is very easy to predict, implement, and instruct users on what to do if it doesn't work (e.g. "add a transformation to {values_coodinate_system} to by").

However if we are implicitly defining intrinsic coordinate systems by "which coordinate system is transformed to via Identity", we may have multiple results, and have to pick one. I don't think there's a reasonable way to do that.

(cc: @LucaMarconato @giovp)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the design document's polygons section and the PointModel and ShapeModel definitions. Review the polygon aggregation work in pull request #162, especially how it determines whether two elements share a space. Done should explicitly represent each element's intrinsic coordinate system and make the intended same-space and transformation behavior unambiguous.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.