Good day!

I have been reviewing the all the codes from hagelslag and I would like to ask the data input format that it needs. Thank you.

The centroid in the csv track_step file is different than the centroid in the patches netCDF file.
When I say different, I don't mean more than 0.2 degrees different, but definitely more than machine roundoff error.

For example:
object: d01_REFL_1KM_AGL_20110427-0000_24_25_622_01
csv longitude: -87.70007
patches longitude: -87.73282

The ampersand (&) symbol in the /hagelslag/evaluation/ProbabilityMetrics.py module's DictributedROC class update() function did not produce expected behavior. My interpretation is that np.count_nonzero((forecasts >= threshold) & (observations >= self.obs_threshold)) should yield the frequency of values where boolean values are true and intersect, but instead this yields for me the frequency of times either boolean array is true. I added a np.logical_and and it fixed this issue for me. Please let me know if you can replicate this issue, and if so, I can submit a pull request of my fix.

    def update(self, forecasts, observations):
        """
        Update the ROC curve with a set of forecasts and observations
        Args:
            forecasts: 1D array of forecast values
            observations: 1D array of observation values.
        """
        for t, threshold in enumerate(self.thresholds):
            tp = np.count_nonzero((forecasts >= threshold) & (observations >= self.obs_threshold))
            fp = np.count_nonzero((forecasts >= threshold) &
                                  (observations < self.obs_threshold))
            fn = np.count_nonzero((forecasts < threshold) &
                                  (observations >= self.obs_threshold))
            tn = np.count_nonzero((forecasts < threshold) &
                                  (observations < self.obs_threshold))
            self.contingency_tables.iloc[t] += [tp, fp, fn, tn]

Eventually we need to accept the objects' region properties in row-column coordinates, as opposed to xy.

skimage.measure regionprops function will stop using xy coordinates and use row-column instead.
STObject.py uses it for shape properties.

We could specify regionprops(..., coordinates='xy') for now to avoid the warning, but this will break.

See https://scikit-image.org/docs/0.14.x/release_notes_and_installation.html#deprecations for details on how to avoid this message.
warn(XY_TO_RC_DEPRECATION_MESSAGE)

STObject was built under the assumption of hourly integer time steps originally, and some of the derived functions have not been updated to enable arbitrary time differencing when tracking or calculating trajectories and centroids. This functionality needs to be fixed so that arbitrary times can be used rather than integer times with a step of 1.

The centroid lon / lat data in the netCDF patch data represents the the longitude / latitude values at the center of the patch, not the center of the object, and thus there are mis-matches between centroid lon / lat in the CSV files and netCDF files for the same storm objects.

Is there any reason to keep the patch-center derived lons / lats? If not, the values could be replaced using the same process to generate the centroids for the CSV file.