Request: metadata field in SpatialSeries for boundary range

[TomDonoghue]

It would be nice if there was a clean / easy way to indicate some position metadata in for position data, in particular the boundary range. This would probably be something to add to SpatialSeries (or, possibly, in the Position) object.

The use case is if we have possible boundary ranges across x / y / z dimensions, it's nice to store the possible range, to have a size of the map, regardless of the recorded values. We need this for some experiments, and right now we are having to hack this a bit, but adding separate arrays with boundary definitions.

I chatted on this briefly with @bendichter - adding a simply min/max boundary to each x / y / z only addresses the square / cube case, but it at least addresses this simple / general case (with more complicated map boundaries perhaps needing to be outsourced to an extension). This new field would presumably be optional, but it would be a nice / clear place to be able to read float values for boundary ranges.

[oruebel]

Thanks @TomDonoghue for submitting this helpful issue.

This would probably be something to add to SpatialSeries (or, possibly, in the Position) object.

I think this makes most sense on the SpatialSeries. Since this is specific to the data values, I would suggest adding it as an optional attribute on the data, i.e., define this as SpatialSeries.data.bounds. The units for the bounds values should be the same as SpatialSeries.data.units. This seems to be a fairly simple change that seems to be generally useful to have.

@mavaylon1 would you be able to help with implementing this feature?

The use case is if we have possible boundary ranges across x / y / z dimensions, it's nice to store the possible range, to have a size of the map

This is more a philosophical comment. Defining the bounds of values is useful, e.g., to support error checking of values or search based on relative positions within the bounds. However, we should not confuse bounds of data values with the geometry of a map. It so happens that in the case of square that the bounds are sufficient to describe the square but in general that is not the purpose of bounds. If the goal it to describe the geometry of a map, then this should be handled separately. All this being said, I think that adding a bounds attribute for SpatialSeries makes sense, I just wanted to make sure we are not confusing data bounds with actual geometry.

[TomDonoghue]

@oruebel - agreed on the comments about range vs. map! This wouldn't in any real sense provide a map geometry, which is better supported by an extension or similar (though in the basic case of the square / rectangle / cube this does overlap with bounds). Conceptualize it as 'data bound' rather than any kind "boundary" makes sense to me.

I'm not yet familiar with working with the schema files / approach, but if there is anything I can do to help add this, let me know!

[oruebel]

I'm not yet familiar with working with the schema files / approach, but if there is anything I can do to help add this, let me know!

Thanks for your offer to help. I think we can handle this particular issue on our end.

Just FYI, in general the process for this is that we need to:

1. Create a PR on the nwb-schema (i.e,. this repo) to propose the change to the schema
2. We then need to make a corresponding PR on the PyNWB repo to: 1) update the SpatialSeries class: 2) pull in the new schema, 3) Update the tutorial for SpatialSeries, 3) add unit tests.
3. Create an issue on the MatNWB repo pointing to the schema PR so that we can make sure the changes are working in MatNWB as well. For this particular change, I believe this will mainly involve: 1) pulling in the new schema, 2 adding unit tests, and 3) updating the tutorial for SpatialSeries. We should need to update the SpatialSeries class itself since MatNWB autogenerates the class from the new schema.

[mavaylon1]

I will hack on this after the Rehack

[rly]

We are reverting this change before release while we resolve issues with supporting this feature in HDMF which underlies PyNWB.

[rly]

See NeurodataWithoutBorders/pynwb#1992