Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Christian-What is the future of the existing GeoGrid classes? Are these going to be deprecated/removed or will they stick around for a while until the GridCoverage API is well tested and stable? Since it is not backward compatible, will you be providing documentation for client developers on migrating from GeoGrid to GridCoverage?
Don On 7/30/15 10:12 AM, Christian Ward-Garrison wrote:
Hi Antonio,Yeah, our versions are a little convoluted right now. The current release versions is 4.6.2, which is probably what you're using. We also have two unreleased in-development versions: 4.6.3 and 5.0.0. We decided to put GridCoverage (which replaces GeoGrid and fixes the dateline issue) on 5.0.0 because it is a large change that isn't backwards-compatible. Clients will have to rewrite parts of their code to take advantage of that, but it couldn't really be helped. Better to wrap those changes in a MAJOR-version increase (i.e. v4 -> v5) than a PATCH-version increase (i.e. v4.6.2 -> v4.6.3) [1].Cheers, Christian [1] http://semver.org/On Thu, Jul 30, 2015 at 5:50 AM, Antonio Rodriges <antonio.rrz@xxxxxxxxx <mailto:antonio.rrz@xxxxxxxxx>> wrote:Christian: Thank you. Why NetCDF-Java v5.0? I used netcdfAll-4.6.jar [1], doesn't 4.6 reflect NetCDF-Java version? [1] http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/documentation.htm 2015-07-30 1:48 GMT+03:00 Christian Ward-Garrison <cwardgar@xxxxxxxx <mailto:cwardgar@xxxxxxxx>>: > Hi Antonio, > > There are many longstanding issues concerning grids that cross the date > line, and this is one of them. It's actually a very hard problem to solve in > a way that doesn't break existing clients (e.g. the IDV), but we finally > have a solution for it in the upcoming NetCDF-Java v5.0. Until then, > hopefully you can work around the date line weirdness. > > Cheers, > Christian > > On Mon, Jul 27, 2015 at 6:27 AM, Antonio Rodriges <antonio.rrz@xxxxxxxxx <mailto:antonio.rrz@xxxxxxxxx>> > wrote: >> >> Hello, >> >> Am I doing smth wrong? - >> >> When I call GridCoordSystem.getRangesFromLatLonRect >> I always get two-element List<Range> regardless of whether the given >> LatLonRect crosses dateline or not. >> >> There are some datasets with longitudes 0..360 and others with >> -180..-180, so we have index breaks at 0 and +/-180 correspondingly. >> When I call getRangesFromLatLonRect for box containing 0 it returns me >> the range for values > 0 and if crossing +180 it returns range >> containing positive lons < 180. >> >> _______________________________________________ >> netcdf-java mailing list >> netcdf-java@xxxxxxxxxxxxxxxx <mailto:netcdf-java@xxxxxxxxxxxxxxxx> >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ >> > _______________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdf-java archives: