Clarify how to store "additional information" for Points

[keller-mark]

Is your feature request related to a problem? Please describe. The Design Doc for Points currently states:

Each observation is a point, and might have additional information (intensity etc.)

Thus, it seems that there are currently two ways to store additional information (i.e., additional columns besides X/Y/Z) for Points: as additional columns in the same Parquet dataframe, or as columns of an aligned (one .obs row per point) SpatialData Table element.

Further, it is unclear to me whether instance_key and feature_key refer to columns in the same Parquet table versus columns in a (point-annotating) SpatialData Table.

This may be confusing as a user creating SpatialData objects, or as a developer of a tool which needs to read/operate-on/visualize the points.

Describe the solution you'd like

• Clarify which table (Parquet table vs. SpatialData Table element) is meant to contain the columns referred to by the instance_key and feature_key metadata (if present)
• Option 1. Do not allow additional columns besides X/Y/Z(/instance_key/feature_key) in the Parquet table; Force any additional columns to be contained in a point-annotating SpatialData Table element.

Describe alternatives you've considered

• Option 2. Allow additional columns to be stored in either location, but clarify any limitations regarding the storage location choice (e.g., will all operations still work the same? will they have the same performance characteristics? when specifying a column name such as pointIntensity, how to specify to downstream software in which table to look for this column?)