NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On 6/25/2012 1:20 PM, Rockwood, Bryan wrote:
if you have a netcdf file, you are not constrained to use the code that created it.John, Thanks for the quick response. 1. Sadly, I'm just a recipient of the netCDF files created by the v4.0 API and the upstream source of this data is not planning on upgrading anytime soon. That said, I expected you guys might say that so I did verified that the code works this way in 4.3 too.
2. Understood. I've already finished the code that does the netCDF -> GRIB conversion so this was more of a "why does it work that way?" type of email. 3. Gotcha. I wasn't even thinking of it from a GIS standpoint. After spending time writing code that handles GRIB data, I'm used to the first point in a GRIB record being 0,0 and going from there. The only reason I brought it up was that it was the first indication that the projection being used to generate the x and y is not using LA1 and LO1 as the originating point. 4. I'm guessing this is where I'm getting hung up. All this time, I've been working with the assumption that LA1 and LO1 from the GDS was origin of the projection. How was it decided that LATIN1 and LOV were going to be used for the origin instead? I've talked to a two other software devs who work with GRIB (full disclosure, one is a meteorologist, the other is not), and they haven't seen it done this way either.
Im guessing that you are confusing two things: 1) the (0,0)th point (eg the upper right grid point) in index space2) the (lat, lon) location where x=0, y=0 on the projection plane. This is typically placed near the middle of the grid to minimize distortion.
netcdf-java
archives: