Velocity metric for subsecuent traces error

[GuillermoDylan]

The computation of the speed, as it is currently done, always places the first coordinate of each trace at a NaN value, which gets converted to 0. In the first trace this makes sense, since it is the beginning of the user’s movement, but in the subsequent traces, does it really make sense for the speed to start at 0? Especially for calculations such as the user’s average speed—wouldn’t we be introducing an error in the average?

I’m not sure whether the last coordinate of the previous trace should be used to calculate that speed. It’s true that if the traces are analyzed separately it does make sense, but I don’t know if this could end up causing a calculation error at a more general level.

pywib/pywib/core/movement.py

Lines 28 to 32 in d1b4822

	for j in range(len(session_traces)):
	session_traces[j] = _path(session_traces[j])
	session_traces[j]['velocity'] = session_traces[j]['distance'] / session_traces[j]['dt']
	# Fix NaN velocity for first point - set to 0
	session_traces[j]['velocity'] = session_traces[j]['velocity'].fillna(0)

[GuillermoDylan]

Another topic to be considered on the same line is the operation performed in velocity_metrics (as well as for acceleartion and jerkiness) to exclude non zero velocities:

return compute_metrics_from_traces(
        df=df,
        traces=traces,
        column_name=ColumnNames.VELOCITY,
        compute_traces_fn=lambda _: traces,
        preprocess_fn=lambda s: s[s > 0]
)

This should also be discussed, as it may make more sense to either not exclude 0s by default or to leave it up for the user to determine.