We should not have a ProbeGroup with overlapping contact positions.
I think ProbeGroup.add_probe should raise an error if the incoming probe has contact positions that collide in space with contacts already in the group. A ProbeGroup represents a physical experimental setup, and two distinct contacts cannot occupy the same spatial position. We should enforce that invariant at Probe construction and when adding an extra Probe with ProbeGroup.add_probe.
Currently we enforce checks with _check_compatible within ProbeGroup.add_probe that raises an error when trying to mix 2D and 3D probes. We should extend it for contact position uniqueness across the probe group. We are already doing this at the Probe level (see Probe.set_contacts) and I think we should use the same criteria when forming a ProbeGroup, where two contacts might be in the same position in the experimental setup.
In practice, we are already checking this on the SpikeInterface side: ChannelsAggregationRecording asserts unique contact positions before building a combined ProbeGroup. I think the responsibility and logic for this should be here.
The complication of a probe having a side (or whatever comes in the future) does not really change the logic here. If the criterion is position, we should validate position across the probe group; if the criterion for uniqueness is position plus side, we should validate that; we can extend the criterion to whatever might come, but we should check it.
Note that this is separate from the contact_ids uniqueness discussed in #402 (unique at probe level, compound key (probe_index, contact_id) unique at group level). Positions are stricter, because they correspond to physical space rather than a labelling choice.
We should not have a ProbeGroup with overlapping contact positions.
I think
ProbeGroup.add_probeshould raise an error if the incoming probe has contact positions that collide in space with contacts already in the group. A ProbeGroup represents a physical experimental setup, and two distinct contacts cannot occupy the same spatial position. We should enforce that invariant at Probe construction and when adding an extra Probe withProbeGroup.add_probe.Currently we enforce checks with
_check_compatiblewithinProbeGroup.add_probethat raises an error when trying to mix 2D and 3D probes. We should extend it for contact position uniqueness across the probe group. We are already doing this at the Probe level (seeProbe.set_contacts) and I think we should use the same criteria when forming a ProbeGroup, where two contacts might be in the same position in the experimental setup.In practice, we are already checking this on the SpikeInterface side:
ChannelsAggregationRecordingasserts unique contact positions before building a combined ProbeGroup. I think the responsibility and logic for this should be here.The complication of a probe having a side (or whatever comes in the future) does not really change the logic here. If the criterion is position, we should validate position across the probe group; if the criterion for uniqueness is position plus side, we should validate that; we can extend the criterion to whatever might come, but we should check it.
Note that this is separate from the
contact_idsuniqueness discussed in #402 (unique at probe level, compound key(probe_index, contact_id)unique at group level). Positions are stricter, because they correspond to physical space rather than a labelling choice.