[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deployed: Bug fixes to NetCDF Java API 4.1.20100227.0121

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Deployed: Bug fixes to NetCDF Java API 4.1.20100227.0121
  • Date: Mon, 29 Mar 2010 12:32:13 -0600
On 3/29/2010 11:48 AM, Tom Margolis wrote:

Hi John,

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 CoordinateAxis1D

monoticize 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.
i think you misunderstand. the idea is not to support normalized values, only monotic coordinates. so a lon range that goes from 160 to -160 would be changed to go from 160 to 200.
the reason this can work is there is a distinction between Lat/Lon Points and coordinates. there is always a transformation: latlon <--> coord. In this case, the coords would be longitudes between 160 and 200, so a lat/lon value of -170 would get converted to coordinate of 190. If you look at LatlonProjection, you may get the idea better. 


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 would

summarize 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?
well, maybe we should try it for these problems and see how it works out, it may clarify how to do this in the future.