Re: [netcdf-java] Units for Standard Coordinate Transforms [SEC=UNCLASSIFIED]

  • To: Leon Majewski <Leon.Majewski@xxxxxxxxxx>
  • Subject: Re: [netcdf-java] Units for Standard Coordinate Transforms [SEC=UNCLASSIFIED]
  • From: Ryan May <rmay@xxxxxxxx>
  • Date: Fri, 21 Nov 2014 15:15:25 -0700

Thanks for the detailed report. This is definitely a bug in our vertical
perspective code. For writing out files, we were being CF-compliant, but on
reading in, we were:

1) Assuming 'km'
2) Only reading in 'height_above_earth'

neither of which is CF-compliant, unlike the other transforms we support.
I've fixed both--we now assume units of 'm' (and convert to 'km'
internally) and also check for 'perspective_point_height' (and fall back to
'height_above_earth'). If you could send or point me to a data file, I can
add this to our unit test suite.

If you can build your own version of NetCDF-java, you can get this from our
current 4.5.4 branch. Otherwise, the fix will appear in release 4.5.4; in
the meanwhile, you might consider using the Geostationary projection, which
should be CF-1.7 compliant.

Regarding the slight errors, I can confirm for you that our code for
vertical perspective only pulls in earth_radius; if you don't specify it,
it uses the default (6371229.)


On Thu, Nov 13, 2014 at 12:38 PM, Leon Majewski <Leon.Majewski@xxxxxxxxxx>

> Hi,
> I've been having some issues with the accurate display (via ncWMS/godiva)
> of some geostationary satellite data (netCDF4 with metadata that ~complies
> with CF 1.6). I've tracked this down to the units of
> "perspective_point_height" aka "height_above_earth". CF uses m while the
> netcdf-java docs (
> and source (
> suggest the input is in km. Which of these should I follow?
> Details:
> When I specify a "height_above_earth" of 35785831 m, the WMS display does
> not line up with coastlines (it seems shrunk). However, if I change this to
> 35785.831, the coastlines are just about right. I think the remaining,
> minor, differences are due to a) inaccuracies of the satellite navigation
> and/or b) the use of semi_minor_axis and semi_major_axis in my projection
> spec (ie I don't supply "earth_radius" - so maybe the default Earth radius
> in km is being used).
> My proj4 string is '+proj=geos +lon_0=145.0 +h=35785831 +a=6378169.0
> +b=6356583.8', while the attributes of the 'vertical_perspective'
> grid_mapping is:
>                 vertical_perspective:grid_mapping_name =
> "vertical_perspective" ;
>                 vertical_perspective:inverse_flattening = 295.488065897 ;
>                 vertical_perspective:latitude_of_projection_origin = 0. ;
>                 vertical_perspective:longitude_of_projection_origin = 145.
> ;
>                 vertical_perspective:perspective_point_height = 35785831 ;
>                 vertical_perspective:height_above_earth = 35785831 ;
>                 vertical_perspective:semi_major_axis = 6356583.8 ;
>                 vertical_perspective:semi_minor_axis = 6378169. ;
>                 vertical_perspective:units = "m" ;
> Note that I've already added a WKT string (under
> vertical_perspective:spatial_ref) for GDAL to be able to access the data
> correctly (not shown).
> So, I can change my metadata to match the ncWMS code (and add a comment to
> that effect), but this would break my CF ~compliance (eg units of m).
> Alternatively, I could make local changes to our source (maintenance
> issues) or suggest changes to the code base (potentially catastrophic for
> users who have changed to km). I'd appreciate any suggestions.
> Thanks,
> Leon Majewski
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:

Ryan May
Software Engineer
Boulder, CO
  • 2014 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: