[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030708: 20030708: 20030707: 20030701:GEMPAK NIDS display



Daryl,

Did you try redoing with KXKY changed?

As I said a while back, it will be less klunky to just write the driver to
the necessary format, rather than having to fit a different format (in this 
case GINI)
into someone elses idea of what a flat earth looks like. Since there is no 
limitation
in nex2gini that prevents CED, just writing the raster directly rather than
using the imgm2gi and imwgin calls of the GINI routines that add the correct
512 byte GINI header
will be simple.

Steve CHiswell

>From: Daryl Herzmann <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200307081738.h68HctLd022434

>Hello again,
>
>Did you see the report of 4.25 inch hail in Iowa yesterday?  I saw a 
>picture of it, it was big!  Anyway, not to belabour the point here but...
>
>Here is the projection I need.  "unprojected map"  (constant dlat, dlon in 
>map space)
>
>http://mathworld.wolfram.com/EquirectangularProjection.html
>
>Images produced in this projection will work in almost any GIS system that 
>supports RASTERs.  I believe that I can get the MER produced by nex2gini 
>to eventually work.  But it will not be straightforward how to get these 
>images into ESRI products and most datasets will have to be reprojected to 
>match this projection or the image will need to be reprojected.
>
>Unless I am missing something here, I will try the gdradr method again and 
>see if I can get a true "unprojected map" back out from a GEMPAK CED grid 
>file...
>
>Augh, I am probably completely missing the point here and being am 
>ignorant newbie.  A GIS pro I know always makes fun of me when I try to 
>explain projections to him...
>
>Thanks,
>  Daryl
>
>On Tue, 8 Jul 2003, Unidata Support wrote:
>
>>
>>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, y
> ou 
>>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
>>> */
>>>
>>
>>**************************************************************************** 
>>Unidata User Support                                    UCAR Unidata Program 
>>(303)497-8643                                                  P.O. Box 3000 
>>address@hidden                                   Boulder, CO 80307 
>>---------------------------------------------------------------------------- 
>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
>>**************************************************************************** 
>>
>
>-- 
>/**
> * Daryl Herzmann (address@hidden)
> * Program Assistant -- Iowa Environmental Mesonet
> * http://mesonet.agron.iastate.edu
> */
>