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.
Hi Eric- Kemp, Eric M. (TASCSD) wrote:
I am writing a post-processor for the WRF model. My intent is to generate new netCDF files with optional derived variables on pressure surfaces. I have been writing my code to use the CF-1.0 convention as recommended in the IDV documentation, but this week I discovered that the CF convention does not include the Mercator map projection. (Note that the Transverse Mercator projection included in CF is not the same projection.)
We have proposed Mercator as a standard for CF, but it has not been accepted yet. However, you can define it as: mercator char Mercator_Projection; :grid_mapping_name = "mercator"; :longitude_of_projection_origin = 110.0; :latitude_of_projection_origin = -25.0; :standard_parallel = 0.02; :_CoordinateTransformType = "Projection"; :_CoordinateAxisTypes = "GeoX GeoY"; See the reference at: https://www.unidata.ucar.edu/software/netcdf-java/reference/StandardCoordinateTransforms.html
I've made two attempts to work around this while remaining in the CF convention: (1) label the data as Lambert Conformal with the standard latitudes equidistant from the equator, which is supposed to be equivalent to the Mercator projection; and (2) not write out any grid_mapping metadata, but include the latitudes/longitudes at each grid point. In the first case, IDV freezes up and has to be killed. In the second case, IDV claims there are no gridded data in the file, even though the data meets the CF convention (the grid_mapping metadata is listed as optional in the CF documentation).
Can you provide sample files so we can look into this?
So at this point, I'm looking for help on how to encode this for IDV. One extreme possibility is to abandon the CF convention and try using the _Coordinate convention described in the NetCDF-Java documentation, but I'd appreciate feedback before taking such a drastic step.
Try using the definition above.
(Note that my post-processor should also support other map projections used by WRF, so I'd like the output convention to be as flexible as possible.)
Don ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
idvusers
archives: