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.
Leon, 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.) Ryan On Thu, Nov 13, 2014 at 12:38 PM, Leon Majewski <Leon.Majewski@xxxxxxxxxx> wrote: > 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 ( > http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/reference/StandardCoordinateTransforms.html) > and source ( > https://github.com/Unidata/thredds/blob/4.5.3/cdm/src/main/java/ucar/unidata/geoloc/projection/VerticalPerspectiveView.java) > 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: > http://www.unidata.ucar.edu/mailing_lists/ > > -- Ryan May Software Engineer UCAR/Unidata Boulder, CO
netcdf-java
archives: