Good afternoon. I have a NetCDF file of daily PM2.5 concentration. The file is projected in Lambert Conformal Conic projection, and now I want to project it into WGS84. I am wondering is there any post-processing tool/ioapi script exists that allows converting a NetCDF file into another projection. Or, some sort of script, which can convert the latitude and longitude of a given projection (csv, netcdf or other format) to others.
I would highly appreciate it if you could share your knowledge to help me came out of this issue.
You donât have things quite right in your question: WGS84 is a geodetic spheroid, a particular choice of representing the Earthâs surface as an oblate ellipsoid; WGS-84 os one of these and the WRF-Sphere is another. Lambert Conformal Conic is a map projection, a scheme for putting 2-D Cartesian X-Y coordinates on a (portion of) the Earthâs surface (the transformation equations assume that you have already chosen a geodetic spheroid, btw. Different spheroids may well give differences in coordinates as large as 25KM at CONUS scales.)
Grids are defined in terms of a map projection: given the projection, specify the lower-left corner coordinates, the cell-sizes DX in the X direction and DY in the Y direction, and the numbers NCOLS of grid-columns and NROWS of grid-rows in order to specify a grid.
Various of the m3tools programs can be used to transform gridded data from one grid to another (each of which has potentially its own map-projection. Program m3cple does linear interpolation, which is appropriate for going from a coarse (large-cells) grid to a find (small-cells) grid. The pair of programs mtxcalc+mtxcple does re-sampling and re-aggregation, appropriate for going from a finer grid to a coarser grid (or grids of about the same cell-size); it also works for going from coarser to finer.
BEWARE that coordinate-transformations for emissions data have a piece of non-obvious trickiness: as per the usual conventions, emissions data is not given in terms of standard MKS units, but instead has an extra (implicit) per-grid-cell qualifier to the units: units recorded as Kg/sec really mean Kg/sec/grid-cell, so in doing transforms of emissions data you need also to adjust for the ratio of the output-grid grid-cell area to the input-grid grid-cell area. Program mtxcalc has an option for doing this adjustment, so you need to use mtxcalc+mtxcple for re-gridding emissions data.
Thank you so much for your reply. It was really very helpful post. Thanks for your time for pointing to some helpful resources and making the concept clear to me.
Sorry for bothering you again. I was reading the link(https://cjcoats.github.io/ioapi/GRIDS.html) you shared. I have a question. If now I understand correctly, " Grids are defined in terms of a map projection", for my case it is âLambert Conformal Conicâ. But I didnât understand the significance of the parameter âGCTP projection 4â. Also, how can I know which âgeodetic spheroidâ has been chosen? Is there any way to know that? I would appreciate your help in this regard. Thanks again for clarifying my concept on projection.
The I/O API coordinate system treatment is based upon the USGS Geographic Coordinate Transform Package (GCTP), which at the time we started the project was the easiest high-quality publicly-available geographic package for us to use. Its original manual is at https://cjcoats.github.io/ioapi/GCTP.pdf and many of the I/O API coordinate concepts and parameters come from it.
The Earth is approximately an ellipsoid, in particular, because of the force of the Earthâs rotation it is a âflattenedâ spheroid â the rotation causes the diameter to âstretchâ in the plane of the Equator (so that the diameter across the Equator is greater than the diameter pole-to-pole. A spheroid is such a description of the Earth; there have been many such descriptions proposed and used; the most common, together with their GCTP code-numbers are
Clarke 1866: GCTP uses 0 as its index-number
GRS 1980: 8
WGS 84: 12
perfect sphere: 19 (in which case we have to specify the radius elsewhere)
Generally the more recent GRS 80 or WGS 84 ellipsoids are what GIS people use; meteorologists tend to use perfect spheres since doing proper equations of motion on a more-general ellipsoid is quite âhairyâ mathematics. I have seen some older data given in terms of Clarke 1866âŠ
A map projection is a way of putting Cartesian X-Y coordinates on ellipsoids (and so needs a ellipsoid-specification to complete its definition). A Lambert Conformal Conic, for example (I/O API projection code 2, GCTP projection code 4), has the geometric algorithm:
Form a cone that intersects the ellipsoid at two latitudes alpha and beta (and has central axis the same as the rotational N-S axis of the Earth).
Project a geometric ray from the center of the Earth through both its surface and the surface of the cone. Map the Earth-surface intersection-point of that ray to the coneâs intersection point. If you do the arithmetic for this youâll get into some rather messy trigonometry
Slice the cone diametrically opposite âcentral longitudeâ gamma and unroll it flat, with the longitude-gammaâs image on the cone in the N-S, or Y direction.
Find the point on the unrolled-cone where âorigin-pointâ latitude-longitude (LATORIG,LONORIG) winds up, and start measuring X and Y coordinates from there â Y parallel to the longitude-gammaâs line. Usually one chooses LONORIG=gamma, and LATORIG somewhere between alpha and beta (but not always;-( )
Because of how this works, choosing different ellipsoids to represent the Earth will give somewhat-different X-Y coordinate systems; if you use Lambert projections with alpha=30, *beta=*60, and gamma=90, LONORIG=-90 (note the minus-sign, for longitudes west of the Prime Meridian LON=0), and LATORIG=45, then the Cartesian origin X=Y=0 somewhere in Illinois no matter which ellipsoid you use, but the coordinates for Portland Maine will be different by about 20 KM between choosing a spherical ellipsoid and the WGS84 ellipsoid.
Note that because of round-off problems in all the map-projection arithmetic, it is best to do everything in REAL8 (DOUBLE PRECISION) rather than in REAL4, which doesnât have enough significant digits to be sure of giving the ârightâ answerâŠ
And the I/O APIâs coordinate transform routines generally do this work for you, given descriptions you donât need to worry much about the messy mathematics.
The worst problem youâre likely to encounter is transforming back and forth between grid-cell columns and rows and Cartesian X-Y coordinates:
Suppose you have a grid with lower-left corner (X0,Y0) and cell-size (DX,DY), and a point (X,Y) with Xâ„X0, Yâ„Y0. Then the column-
and row-numbers (C,R) for the point are C=1+INT((X-X0)/DX), R=1+INT((Y-Y0)/DY).
Beware that computer-languages âconvert to integerâ operators tend to âdo the wrong thingâ from a mathematical point of view: INT(-0.5) and INT(0.5) are both 0 ;-( so you have to do explicit checks for Xâ„X0, Yâ„Y0 and say âthe point is off the gridâ if either one fails.
Thank you so much for your step by step explanation. I appreciate your time to make these things clear to me. Though I am still struggling with my issues, many things are clear to me now.
Since I need to know the latitude and longitude associated with WGS 84 ellipsoid (12. WGS 84) from my GRIDDESC file. I was trying the following programs:
But, I am getting the following error.
âlatlon: error while loading shared libraries: libnetcdf.so.11: cannot open shared object file: No such file or directoryâ
If I am on the right track, do I need to install another version of NetCDF?
I am feeling really very sorry for bothering you a lot.
