Ticket #474 (new Defect: null)

Opened 2 years ago

For Aviso datasets in geographic projections (Mediterranean, Black Sea), the Okubo-Weiss eddy detection tool fails to project them before running the eddy-detection algorithm

Reported by: jjr8 Owned by: jjr8
Priority: Medium Milestone: 0.8
Component: Tools - Data Products - Aviso Version:
Keywords: Cc:

Description

Although the tool appears to work for these datasets, there is a caveat. The tool is designed to operate on projected data. Internally, the tool is supposed to project the geographic data to a coordinate system such as Albers Equal Area before running the eddy detection step, but I did not have time to finish this capability before I had to release MGET 0.8a25. The result is that all the physical calculations are being performed as if the cells are 0.125 meters wide and high, when they should actually be about 10000 meters. That is a big discrepancy, so why does it seem to work?

The answer is that, by default, the algorithm identifies eddies using a relative threshold, not an absolute one. The default threshold is 0.2 standard deviations below the mean, which is a common threshold from the literature. So even though the calculations of vorticity, shear, the Okubo-Weiss parameter, and have the wrong order of magnitude, the threshold still works because it is a unit-less fraction relative to the mean. However, if you instructed the tool to use an absolute threshold and provided a proper value (such as the one used by Chelton et al. 2007), it would not work properly. The results would be totally wrong; either no eddies would be detected, or all possible eddies would be detected, I’m not sure which.

The possible solutions are:

  1. Implement the automatic projecting of the data that I described.
  1. Limit the tool so that if a geographic dataset is selected, it will only allow the "Standard deviation" threshold type to be used ("Absolute" would not be allowed).

The second is certainly less work. I am inclined to choose that one once I review the code and convince myself that it is really ok for the algorithm operate on geographic coordinates rather than projected coordinates. (I think it should be fine, because the datasets cover such a small extent, so the cells are all approximately the same size in both geographic and projected systems...)

Note: See TracTickets for help on using tickets.