hdim_1 and hdim_2 double-defined in feature dataframe

[JuliaKukulies]

Also from discussion #214:

The columns hdim_1 and hdim_2 in the output data frame from feature_detection_multithreshold() are some cases double-defined, whereby one of the two hdim_1 (hdim_2) has the same value as south_north west_east. This can, for example, be seen in our example notebook for WRF model data and seems only be the case for non latlon grids as it does not appear in this example.

I am not sure of the scope of this problem. It leads to the fact that the Features and Track data frames cannot be saved to an HDF file because column names are not allowed to be double-defined. Additionally, I believe that this issue could cause more serious bugs when we have suddenly two different values for hdim_1/ hdim_2 ?

[freemansw1]

Yeah, this is a critical bug to identify and fix. Thanks for documenting the bug, @JuliaKukulies, and thanks for identifying it, @lk337. If nobody else does, I will have some time to dig into this early next week. We should try to get this out quickly for a 1.4.1 bugfix release. Once we identify the issue, we should probably add in a unit test to make sure that it doesn't happen again.

Longer-term, I think it would be good to add a CI step to auto-run the jupyter notebooks and make sure they don't fail. Maybe target that for v1.6.0.

[w-k-jones]

Problem is caused in linking_trackpy here:

tobac/tobac/tracking.py

Line 254 in 49c4c27

features.rename(columns={"hdim_1": "y", "hdim_2": "x"}, inplace=True)

This is done to avoid a bug with trackpy, however because in the OLR_tracking_model example data the features dataframe already has x, y coords, this results in repeating the column names

When the columns are renamed back to hdim1, hdim2

tobac/tobac/tracking.py

Line 283 in 49c4c27

features.rename(columns={"y": "hdim_1", "x": "hdim_2"}, inplace=True)

this also renames the original x, y columns.

A quick fix would be to check if x, y already exist as column names in the features dataframe and temporarily rename them while tracking. The longer term fix would be solving the original issue with trackpy that caused this workaround

[w-k-jones]

Fixed in #217