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
