HI Don:
GeoGrid will become deprecated but will stay in the core 5.0. It will
eventually be removed, but likely not for a long time. All of the CDM/TDS
will switch to using Coverage in 5.0. Once it stabilizes Im sure we will
produce some docs for the migration.
Preliminary (and evolving) notes on 5.0 changes are here (although not much
yet on Coverage) :
http://www.unidata.ucar.edu/software/thredds/v5.0/tds/UpgradingTo5.html
regards,
John
On Thu, Jul 30, 2015 at 1:52 PM, Don Murray <don.murray@xxxxxxxx> wrote:
> 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 mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
