[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030904: PROJ and DEVICE keywords
- Subject: 20030904: PROJ and DEVICE keywords
- Date: Wed, 10 Sep 2003 12:49:29 -0600
Kwan-yin,
You had changed grid sizes which affect simple map projections.
The NPS uses the average of corner points to try to determine a
central longitude, which can skew as the curvature of
the earth becomes large. You are better off specifying the
full map projection using the 3 angles (see phelp PROJ for
information). The third angle is the rotation angle of
the projection which can be used to rotate the projection
about the central longitude. Angle 1 is the latitude through which
the projection plane passes through (or tangent for 90 or -90) the earth.
When using the device driver, eg gif, make sure you don't have any
files or directories in your path with that name, eg "gif", which would
be confused with the executable $GEMEXE/gif.
Steve Chiswell
>From: "Kwan-yin Kong" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200309041829.h84ITRLd007646
>Steve,
>
> Thank you. After specifying PROJ="str/90;-61.5;0"
>in GDCFIL, the analyzed grids are now navigated correctly.
> PROJ=nps had been working fine for me before. I suppose
>that the updated version of either OABSND or the PROJ
>options caused confusion in navigation (Am I right?). The
>advantage of using PROJ=nps is that I don't need to
>specify the "central longitude" for the map area. One
>thing that bothers me since I have been using GEMPAK from
>day one is that the maps displayed using the nps and lcc
>projections are skewed. The skewness becomes increasingly
>noticable as I increase the geographical coverage. The
>reason appears to be because the central longitude is
>calculated simply by averaging the longitude of the
>lower-left corner and the longitude of the upper-right
>corner. You confirmed this in your last email. If the
>longitude specified for the upper-right corner is taken to
>be the longitude for the lower-right corner, then the map
>would be shown "up-right". But this means the longitude
>for the upper-right corner would not be what's been
>specified. It must be calculated somehow. On this same
>note, I've also used the UTM projection. The skewness
>problem does not appear there because the longitude
>specified for the upper-right corner is indeed taken to be
>the longitude for the lower-right corner.
>
> The reason I picked NPS/STR as the background map
>projection for objective analyzes instead of a lat/long
>mesh is that the Canadian stations are sparse compared
>with those in the U.S. I can counter the data sparsity in
>Canada by using the STR projection since the projected
>area of STR decreases towards the poles. In your last
>email, you gave PROJ=STR/90;-61.5;0. I understand that
>angle2 represents the central longitude for the map, but
>I'm not clear on the purposes of angle1 and angle2. If
>they can be used to spread out the areas in lower
>latitudes and shrinks the area in higher latitudes, that
>would even out the sparse data in Canada and the denser
>data in the U.S.
>
> Another problem I encounter after re-installing
>GEMPAK was that when I try to generate a gif file using
>DEVICE=gif, it gives the following error.
>
>GEMPAK-GDCNTR>r
>Creating process: gif for queue 2303
>Error in execl to gif = 13
>
>What's the meaning of this error?
>
>Thanks again for your help.
>
>Kwan-yin Kong
>City College of New York
>
>
>On Wed, 03 Sep 2003 12:42:16 -0600
> Unidata Support <address@hidden> wrote:
>>
>>Kwan-yin,
>>
>>All the attatchments came through fine this time.
>>The grid file you sent had navigation:
>> GRID NAVIGATION:
>> PROJECTION: NPS
>> GRID SIZE: 30 25
>> LL CORNER: 12.00 -103.00
>> UR CORNER: 76.00 -20.00
>>
>>while the mkgrid script creates a grid where KXKY=25;21.
>>
>>Several points to make here:
>>
>>1) You are using the simple map projection NPS.
>>This map projection is equivalent to STR/90;avg_lon;0
>>
>>The average longitude of the grid will be data set
>>dependent,
>>and therefore is one problem you are having. For the
>>GAREA you have above,
>>you should use PROJ=STR/90;-61.5;0 in GDCFIL rather than
>>PROJ=NPS
>>so that your projection is constant. Otherwise, the NPS
>>output for the different
>>grids you have may not be the same, which could cause the
>>confusion
>>with OABSND that you saw in using the projection from the
>>gridded set
>>including the extended area and data area.
>>
>>2) Your upper air data set is very sparse to the east of
>>the US, which will
>>lead to objective analysis displacement of the feature
>>based on the stations
>>within your search radius. That is, while the storm is
>>closest to the sounding
>>locations in NC, the objective analysis will place the
>>low at the grid
>>location where the contribution of surrounding stations
>>is a minimum,
>>therefor most likely south and east of where you might
>>expect (I would suggest
>>not using the /EX flag to SEARCH in OABSND for this
>>reason.
>>
>>I think you will get the results you were expecting with:
>>
>> GDOUTF = testme.gem
>> PROJ = str/90;-61.5;0
>> GRDAREA = 12;-103;76;-20
>> KXKY = 25;21
>> MAXGRD = 750
>> CPYFIL =
>> ANLYSS = 3.0/3;3;3;3
>> GEMPAK-GDCFIL>r
>>
>> GDCFIL PARAMETERS:
>>
>> New grid file: testme.gem
>>
>>
>> Grid projection: STR
>> Lower left corner: 12.00 -103.00
>> Upper right corner: 76.00 -20.00
>> KX, KY: 25 21
>> DELTAN = 3.000 EXTEND = 3; 3; 3; 3
>> Maximum number of grids that can be added to file 750
>>Enter <cr> to accept parameters or type EXIT:
>> Parameters requested:
>>GDOUTF,PROJ,GRDAREA,KXKY,MAXGRD,CPYFIL,ANLYSS.
>> GEMPAK-GDCFIL>
>>
>>
>> SNFILE = 19990916_upa.gem
>> GDFILE = testme.gem
>> SNPARM = pmsl
>> STNDEX = cape;cins;show
>> LEVELS = 0
>> VCOORD = pres
>> DATTIM = 1200
>> DTAAREA =
>> GUESS =
>> GAMMA = 0.20
>> SEARCH = 30
>> NPASS = 2
>> QCNTL =
>> GEMPAK-OABSND>r
>>
>> OABSND PARAMETERS:
>>
>> Output grid file: testme.gem
>> Number of x, y points: 25 21
>> Grid bnds: 12.00 -103.00 76.00 -20.00 Grid
>>xtnd: 3 3 3 3
>> Station spacing: 3.00
>> No first guess file is requested.
>> Sounding file: 19990916_upa.gem
>> Data area: 4.00;-151.00;89.00;24.00
>> Level parameters: PMSL
>> QC threshold: 0.0
>> Levels: 0
>> Vertical coordinate: pres
>>
>>
>>
>> Station parameters: CAPE CINS SHOW
>> Time: 990916/1200
>> GAMMA: 0.20 SEARCH: 30.00 NPASS: 2
>> No data extrapolation will occur.
>>Enter <cr> to accept parameters or type EXIT:
>>
>> Processing data at time 990916/1200
>>
>> RMS values for pass 1
>> PARAMETER: PMSL CAPE CINS SHOW
>> LEVEL: 0 0 0 0
>> RMS: 3.47 217.74 31.72 2.56
>> #STN: 101 101 101 93
>>
>> RMS values for pass 2
>> PARAMETER: PMSL CAPE CINS SHOW
>> LEVEL: 0 0 0 0
>> RMS: 1.24 137.79 10.79 1.13
>> #STN: 90 90 90 83
>> Parameters requested:
>>SNFILE,GDFILE,SNPARM,STNDEX,LEVELS,VCOORD,DATTIM,
>> DTAAREA,GUESS,GAMMA,SEARCH,NPASS,QCNTL.
>> GEMPAK-OABSND>
>>
>>
>>
>> GDATTIM = 1200
>> GLEVEL = 0
>> GVCORD = PRES
>> GFUNC = pmsl
>> GDFILE = testme.gem
>> CINT = 4
>> LINE = 3
>> MAP = 1
>> TITLE = 1
>> DEVICE = XW
>> SATFIL =
>> RADFIL =
>> PROJ = str/90;-61.5;0
>> GAREA = 12;-103;76;-20
>> IJSKIP =
>> CLEAR = y
>> PANEL = 0
>> TEXT = 1
>> SCALE = 0
>> LATLON =
>> HILO =
>> HLSYM =
>> CLRBAR =
>> CONTUR = 0
>> SKIP = 0
>> FINT = 0
>> FLINE = 10-20
>> CTYPE = C
>> LUTFIL =
>> STNPLT =
>> IMBAR =
>> GEMPAK-GDCNTR>r
>>Creating process: xw for queue 10503
>>
>> Grid file: testme.gem
>>
>>
>> GRID IDENTIFIER:
>> TIME1 TIME2 LEVL1 LEVL2 VCORD
>>PARM
>>990916/1200 0 PRES
>>PMSL
>>
>> GAREA: 12;-103;76;-20
>>
>> SCALE:
>> 0
>>
>> MINIMUM AND MAXIMUM VALUES 964.57 1026.55
>>
>> LINE CONTOURS:
>>
>> LEVELS: 968.00 972.00 976.00 980.00
>> 984.00 988.00 992.00
>>
>> LEVELS: 996.00 1000.00 1004.00 1008.00
>> 1012.00 1016.00 1020.00
>>
>> LEVELS: 1024.00
>>Enter <cr> to accept parameters or type EXIT:
>> Parameters requested:
>>GDATTIM,GLEVEL,GVCORD,GFUNC,GDFILE,CINT,LINE,MAP,
>> TITLE,DEVICE,SATFIL,RADFIL,PROJ,GAREA,IJSKIP,CLEAR,PANEL,TEXT,SCALE,LATLON,
>> HILO,HLSYM,CLRBAR,CONTUR,SKIP,FINT,FLINE,CTYPE,LUTFIL,STNPLT,IMBAR.
>> GEMPAK-GDCNTR>
>>
>>
>>
>>
>>Steve Chiswell
>>Unidata User Support
>>
>