[Met_help] ascii2nc: difference between "Elevation" and "Height"
John Halley Gotway
johnhg at rap.ucar.edu
Mon Feb 23 11:25:58 MST 2009
Jonathan,
Elevation is the elevation of the observing location. And height is the elevation where the observation was actually taken.
If you use "ncdump" to look at the output of the PB2NC tool in METv2.0beta6/out/pb2nc/sample_pb.nc, you'll notice the following:
(1) The first observing location listed is "72233" (ncdump -v hdr_sid sample_pb.nc | more). This happens to be for Slidell, LA.
(2) That observing location has an elevation of "8 meters": the 3rd item listed in hdr_arr (ncdump -v hdr_arr sample_pb.nc | more).
(3) This observation location has many observations listed (ncdump -v obs_arr sample_pb.nc | more) - all of the observations with a header id of 0.
(4) The observations for this location have many different elevation values: 7.988074, 139.7913, 808.7925, 1520.73, and so on...
So that's the difference between them.
However, please note that currently MET does not make use of either the elevation or the height! We include both pieces of information in the NetCDF output of PB2NC in anticipation that we may use
them in the future. For example, currently MET only considers observations that are of type APDSFC or SFCSHP to actually be at the surface. So only observations of these types are matched to 2-meter
temperature or 10-meter winds. We may, at some point, want to do something more sophisticated using the elevation of the observing location and the height of the observation itself. But right now
we're not using "elevation" or "height" for anything.
So you could put in "-9999" (missing) for both, and you wouldn't have any problems using it in MET.
Thanks,
John
Case, Jonathan (MSFC-VP61)[Other] wrote:
> John,
>
>
>
> Can you explain to me the difference between the Elevation and Height
> fields in the ASCII2NC point observation format table?
>
>
>
> I'm interested in getting MADIS data output and re-formatted for use
> with ascii2nc. Over the weekend, I ran pb2nc on the archived PREPBUFR
> data archive you pointed me to, and the results were rather
> discouraging. In my 3 months period of record, I identified 10 days
> with missing data, plus an additional 7 days with incomplete data in the
> PREPBUFR archive. Therefore, I'm taking alternative steps to acquire
> MADIS data for use in MET.
>
>
>
> Thanks for the assistance,
>
> Jonathan
>
>
>
> ***********************************************************
> Jonathan Case, ENSCO, Inc.
> Aerospace Sciences & Engineering Division
> Short-term Prediction Research and Transition Center
> 320 Sparkman Drive, Room 3062
> Huntsville, AL 35805-1912
> Voice: (256) 961-7504 Fax: (256) 961-7788
> Emails: Jonathan.Case-1 at nasa.gov
>
> case.jonathan at ensco.com
>
> ***********************************************************
>
>
>
>
More information about the Met_help
mailing list