I did indeed think about the fact that a monotonic CoordinateAxis1D is
assumed throughout your code, but I'm not familiar enough with the code
to uncover all the tangential effects of supporting non-monotonic
longitude axes, nor do I have unit tests that test all your code. I
ran all the tests I could from my side. My assumption was that you
would run your test suites using the new CoordinateAxis1D to uncover
these tangential effects. If you don't have unit tests that would do
so, maybe that's something we could work on.
we never have enough unit tests, so we just try to add them when we can.
Its possible that a better strategy is to have CoordinateAxis1Dmonoticize its values
I think this would simply shift the problem. The goal is to support
both [0 to 360] *and* [-180 to 180] longitude scales; in other words,
the CoordinateAxis1D should be able to interpret -20 and 340 as the same
longitude value. If CoordinateAxis1D monoticizes its values (i.e.
converts them to a [0 to 360] scale), then it won't support [-180 to
180] values, and we're back to square one.
These appear to be the same as what you previously sent?
Acutally, the compareToLonRange(..) method called in the latest GridCoordSys class is different than the one I had previously sent, so it's probably safest just to adopt the new GridCoordSys class.
It would be helpful to me in reviewing your fixes if you wouldsummarize the problem, as well as the fix
Sorry - I thought I had summarized the problem in previous emails, but
it's probably best if I summarize the summaries (!) in one email. And I
can certainly send you unit tests; do you need them for these fixes or
just for subsequent fixes?
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.