I think we agree (at least in discussion with @mpsonntag and @jgrewe we agreed) that it's often annoying to have to create a DataArray for the positions of a MultiTag. One proposed solution would be to change the MultiTag to hold positions in a different data structure, but that would be a major API change, a file format change, and it would change workflows for situations where an existing DataArray can (or should) be used for a MultiTag's positions.
Instead, we could solve both issues with a constructor that takes a vector or native array or nix::NDArray and internally creates the DataArray for the user. The new DataArray can be named automatically based on the MultiTag's name and the data type can be inferred.
I think we agree (at least in discussion with @mpsonntag and @jgrewe we agreed) that it's often annoying to have to create a DataArray for the positions of a MultiTag. One proposed solution would be to change the MultiTag to hold positions in a different data structure, but that would be a major API change, a file format change, and it would change workflows for situations where an existing DataArray can (or should) be used for a MultiTag's positions.
Instead, we could solve both issues with a constructor that takes a vector or native array or nix::NDArray and internally creates the DataArray for the user. The new DataArray can be named automatically based on the MultiTag's name and the data type can be inferred.