20030708: 20030707: 20030701:GEMPAK NIDS display

Daryl,

The GINI format uses a number for the projection- this
number is only recognized for the 3 types of projections. It
is not a limitation of my projection code, just the GINI writing
routine.

But, the point I made is that the 1 point off is not a 1km error
if the software package you are using expresses the projection using 
a pole point calculation.

GEMPAK uses tha 2 corner points and the projection information. McIDAS 
on the other hand like many other applications, uses a different projection 
model where the pole point is specified (pole point may be outside your image
of course). When you read USGS projections, and GRIB documentation, your will
find that they supply the pole point location relative to the grid spacing. 
The pole point would have a row of something on the order of
4444 points outside your domain. When you multiply a .009999 error by 4444, you 
get something like 44km. So, if your pole point was 44km off, then your
resultant display would reflect that.

Steve Chiswell


>From: Daryl Herzmann <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200307081430.h68EUvLd025608

>Good morning,
>
>Thanks for the response.  Please see my comments below.
>
>On Mon, 7 Jul 2003, Unidata Support wrote:
>
>>Daryl,
>>
>>The only projections allowed by the GINI data format are STR, LCC, 
>>(and what they call) MER.
>
>Hehe.
>
>>First off as I'm out the door is that KXKY should be 1701;1201
>>since you have to count the starting row/column, right?
>
>Well, the 1 extra pixel would account for a 0.01 degrees of latlon space, 
>which is not very significant.  So the pixel spacing would be 0.00999 ...
>The max error in the image should be 1km, not 30-50 km that I am noticing.
>
>>As it stands, your dx and dy is not 1km, and I doubt that the resolution
>>provided by a 3 byte integer (GINI format again) will represent that
>>number accurately. What I suspect is happening is that your mapserver is
>>calculating the pole point of the projection, and that is a big number
>>(row/col) multiplied by your error in dx and dy, which magnifies the
>>error.
>
>I guess that I don't follow this.  I suspect that mapserver assumes this
>image is CED (since I tell mapserver it is) and it isn't.  I tried
>extensively last night to find a "GIS" *cough* projection to replicate
>what nex2gini produces in MER, but I couldn't get it to work....
>
>Hmmm....  The strange thing is that gdcnav.f in the nex2gini source seems 
>to have support for a CED projection.  Perhaps it is just generically 
>used for this app.
>
>Thanks for the comments.  I will keep digging... 
>
>Daryl
>
>-- 
>/**
> * Daryl Herzmann (address@hidden)
> * Program Assistant -- Iowa Environmental Mesonet
> * http://mesonet.agron.iastate.edu
> */
>