Slicing with non-equidistant coordinate

[mvecsei]

I am currently trying to slice data with a dataobject along a "Time" coordinate. This coordinate is non-equidistant and the value ranges of the coordinate varies also considerably. The problems I have bumped into so far:

• When slicing, at a number of points the index='...' keyword is passed in dataobject.py. I do not know whether this is generally a problem, but at a few points, e.g. here it does not get recognised as an Ellipsis.
  • Since the ranges are quite different, the code stops at this point. This is not necessarily an error, but it is good to know.
  • If I understand correctly, the summing = "Mean" keyword, implemented here can give a numpy.float32 as an output. In this case the code breaks down, as it expects a numpy.ndarray. It could make sense to automatically transform these numpy.float32 scalars to numpy.ndarray
  • Also for the same keyword: np.mean is called to calculate the mean. It may make sense to replace it with np.nanmean(). If I understand it coorectly, when slicing, the output data vectors can be "padded" with nan-s if their length is very different. In this case calling np.mean will also return nan.
• The previous two points are probably also relevant for the Sum keyword

Since I do not fully understand the slicing algorithm, I did not want to implement these into the code, as I don't know whether they will cause a problem somewhere else. I still have not managed to get the slicing to work, as it seems that in contrast to the equidistant time coordinate slicing, calling mean on the sliced dataobject along the "Rel. XY in int. XY" coordinate converts the data to a scalar, and not a vector as I expected.

[mvecsei]

Update:

• Taking the mean produced a scalar instead of a vector, as the "Rel. XY in int. XY" coordinate varies over all dimensions of the data. This may be because this coordinate is also padded due to the varying value ranges. I managed to circumvent this, by explicitely setting how the "Rel. XY in int. XY" coordiante object should look like.
• As the slicing coordinate is not equidistant, this condition fails. Therefore no coord_obj variable is created. This causes a problem in this line as one tries to access a non-existent variable. I am still stuck with this problem

[mvecsei]

I rather decided to implement a section of the data processing in my own code and not try to force it into flap. However, the five points in my first comment should still be implemented in my opinion. Nevertheless, it seems that my the other points come from trying to do something specific which would require restructuring parts of flap. I do not think that it would make much sense to make the code even more complicated than as it is now.