having sources and elements defined in different planes, when in local coordinates, results in events being in different coordinates. This makes plotting difficult, because one has to specialize potting for sources or elements.

currently

in python you would do

pos_x = ...
pos_y = ...
pos_z = ...
object_id = ...

# in order to know which unique object ids belong to sources or elements, we have to express it as part of our api, or the user has to write this arrays by hand
unique_source_ids = ...
unique_elements_ids = ...

# here we need to have different logic depending on source or element, thus i wrote 2 loops here
for i in unique_source_ids:
  mask = i == object_id
  histogram(pos_x[mask], pos_y[mask]) # note: using pos_y here
for i in unique_element_ids:
  mask = i == object_id
  histogram(pos_x[mask], pos_z[mask]) # note: using pos_z here

this would be better

if sources and elements shared the same local coordinate system. in python you would be able to do:

pos_x = ...
pos_z = ...
object_id = ...

# simple loop. treat sources and elements the same way
for i in np.unique(object_id):
  mask = i == object_id
  histogram(pos_x[mask], pos_z[mask])

but, we have to consider

maybe we should consider this scenario as a recurrent thing. future or third party source and elements are not necessarily defined in our local coordinates plane of choice, anyways. so, maybe we should make this always explicit

for example we could make express the local coordinate plane to the user.

for i in np.unique(object_id:
  mask = i == object_id
  if (object_local_plane[i] == Plane.XY) # or XZ
    histogram(pos_x[mask], pos_y[mask]) # note: using pos_y here
  elseif (object_local_plane[i] == Plane.XY) # or XZ
    histogram(pos_x[mask], pos_z[mask]) # note: using pos_z here

this could solve the issue completely

or maybe, depending on the element local coordinate plane, a transformation of the events takes place, before the user gets access to them. to the user has to think in just one coordinate system, always. Effectively achieving the most simple API for the user

note: in rayx-core, elements already have Plane::XY or Plane::XZ flag. Implementation might be trivial