Inconsistent delta time in `Example_OLR_Tracking_satellite`

[simonrp84]

Hello,
I just noticed that the time dimension in the OLR dataset used in this notebook is not consistent. The difference between subsequent datapoints varies from ~300 seconds to ~1800 seconds:

time = np.array(OLR.time)
for i in range(0, len(time)-1):
    print((time[i+1] - time[i]) / np.timedelta64(1, 's'), end = ', ')

Results in:

476.0, 301.0, 600.0, 424.0, 476.0, 300.0, 600.0, 423.0, 476.0, 301.0, 600.0, 423.0, 478.0, 298.0, 1801.0, 599.0, 425.0, 475.0, 301.0, 599.0, 425.0, 476.0, 300.0, 599.0, 424.0, 476.0, 302.0, 600.0, 422.0, 476.0, 301.0, 599.0, 425.0, 476.0, 299.0, 1801.0, 1800.0, 600.0, 425.0, 477.0, 298.0, 599.0, 424.0, 476.0, 301.0, 600.0, 424.0, 476.0, 300.0, 599.0, 425.0, 476.0, 299.0, 

The notebook seems to run OK, but I thought I'd raise this as an issue as I suspect it might have an influence on the tracking steps. Feel free to close if I've missed some part of the code that takes care of the non-constant timestep!

[JuliaKukulies]

Thanks for pointing this out @simonrp84! Not sure if this is the nature of the used satellite data or if this has mistakenly been introduced somewhere in the data processing. Maybe @fsenf or @mheikenfeld knows more?

Anyhow, you are right that this has an effect on the trajectory linking because dt is crucial to calculate the propagation speed. Currently, tobac works only with a single value for dt, so a better approach for non-constant time steps would probably to take an average timestep instead of using the function tobac.utils.get_spacings()/ tobac.utils.general.get_spacings() because this function only considers the time difference between the first two timesteps.

I think it is not a problem that our example data is like this because it actually could happen that you have data with non-constant timesteps. However, we could for sure modify the tutorial notebook to clarify the effect on dt and the tracking or this could be an issue to be raised in https://github.com/tobac-project/tobac, because we could modify tobac.utils.get_spacings() the way that not only the first timesteps are considered when calculating dt. What do you think @fsenf ?

[fsenf]

@simonrp84 : Good observation! I am not a GOES expert, but I guess that the different time steps reflect the different scan strategies applied throughout the day. And yes, tobac can only deal with non-constant time steps if trackpy can do ...

@w-k-jones has worked a bit with GOES data. Perhaps, he knows more ... ?