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
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 space
2) 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.