Re: Re: Native Grid projection

Thanks David,
Its nice to see the same result using "native method". Just a few observations (not so imp though, nevertheless for clarity). Hope you can comment.

(a) Out of curiosity, I modified your block of code and tried this:

  res_at_mpLimitMode = "corners"
  res_at_mpLeftCornerLatF = 22.09688 ;glat_1(0,0)
  res_at_mpLeftCornerLonF = -22.002 ;glon_1(0,0)
; ur_ix = ;dimsizes(glat_1) - 1
  res_at_mpRightCornerLatF = 62.90312 ;glat_1(ur_ix(0),ur_ix(1))
  res_at_mpRightCornerLonF = 34.002 ;glon_1(ur_ix(0),ur_ix(1))

These (lat/lon) are the same that I used earlier in res_at_mpLimitMode = "LatLon" for Non-Native method (wrf_with_glatlon.ncl).

However, using these values here (with corners, in Native method), I don't get the same result.

(b) The plot using (wrf_with_glatlon.ncl) gives me the lat/lon grid superimposed over the contours. Can the same be done in the Native plot.

(c) wrf_with_glatlon.ncl) takes a longer to plot compared to Native (which plots instantly). This is inspite using (in both scripts):

      res_at_cnFillMode = "RasterFill"
      res_at_cnRasterSmoothingOn = True

Many thanks once again. If anyone else is interested in the script/associated netcdf file, kindly contact me as the file size is > 3 mb, hence not able to post it on ncl talk.

Best regards
Malcolm
(Barcelona Supercomputing Center)

------------------------------------------------------------------------

----- Original Message -----
From: David Brown <dbrown_at_ucar.edu>
To: malmistry_at_indiatimes.com
Cc: ncl-talk_at_ucar.edu forum <ncl-talk_at_ucar.edu>
Sent: Tue, 18 Nov 2008 06:08:22 +0530 (IST)
Subject: Re: Re: Native Grid projection

Hi Malcolm,

The mpMinLatF, mpMinLonF, etc resources are not useful for setting up
native projection plots except in cases where
the lat and lon values are constant along the edges of projection
window (unrotated cylindrical equidistant or mercator projections).

It is normally best to use the "corners" method of setting
mpLimitMode. In the case of your example code, you need to do something
like the following:

res_at_mpLimitMode = "corners"
res_at_mpLeftCornerLatF = glat_1(0,0)
res_at_mpLeftCornerLonF = glon_1(0,0)
ur_ix = dimsizes(glat_1) - 1
res_at_mpRightCornerLatF = glat_1(ur_ix(0),ur_ix(1))
res_at_mpRightCornerLonF = glon_1(ur_ix(0),ur_ix(1))

In other words you specify the lower left grid point and the upper
right grid point. (you could instead use the upper left and the lower
right points).
This allowed me to produce a plot that looks correct for the landmask
values.

In reference to your earlier question, concerning my statement:

"Also note that coordinates that can be expressed in the
rotated system using a single-dimensioned vector or simply as start,
step size, and number of grid points, need 2D lat and lon
coordinate arrays to be specified in the unrotated system. And
additionally note that you would only need to convert the grid
corners from rotated to un-rotated in order to do the "native"
grid plot."

the GLAT and GLON coordinates in the wrf.nc are relative to the
unrotated grid (0 latitude is the equator
and 0 longitude is the greenwich meridian). These are 2-D coordinate
arrays and had I known this is what
you were given, my statement would not have been needed.

Often, however, a rotated lat/lon system is defined by moving the
origin of the coordinate system to the
center lat/lon point (in this case lat 42.5, lon 6.0). This allows
the same grid to be expressed using 1D
coordinate arrays because in this system vertical lines through the
grid have constant longitude and
horizontal lines have constant latitude. This is really what is
meant by "rotated lat/lon". You rotate the
the origin of the lat/lon coordinate system to another point on the
globe.

Hopefully this makes sense.
  -dave

On Nov 13, 2008, at 10:37 AM, malmistry_at_indiatimes.com wrote:

> Dave,
> Thanks...attached are 3 files:
>
> (a) wrf.nc (which as 4 variables)
> (b) wrf_glatlon.ncl (script that uses res_at_sfXarray, res_at_sfYarray)
> (c) wrf_native.ncl (script using Native Proj method)
>
> Plots can be verified by looking at the variable 'LANDMASK' ("lm"
> in the script).
>
> In wrf_glatlon.ncl, 'lm' is shown correctly. TH10 (temp) shows a
> slight distortion (evident over Italy)...but I believe it is not a
> good variable for verification.
>
> In wrf_native.ncl, there is a clear distortion (shift)...in fact,
> the grid doesn't even look correct (like how it is projected in
> wrf_glatlon.ncl).
>
> I have commented wherever necessary in both scripts. I am satisfied
> with the plot (using wrf_glatlon.ncl) and can use this method in
> future. But my only concern is that some output files may not
> necessarily have glat & glon as variables...hence more time will be
> spent on first finding the lat/lon.
>
> Would be interesting to create the same result using the Native
> Method...I played around with wrf_native.ncl a lot. The only thing
> i managed to do was move the grid a little to make it look
> sensible, but I know some more tuning is required.
>
> Thanks for your help.
>
> Best regards
> Malcolm
> P.S I cannot mail this to ncl talk as the file size is big.
>
> ----- Original Message -----
> From: David Brown <dbrown_at_ucar.edu>
> To: malmistry_at_indiatimes.com
> Sent: Thu, 13 Nov 2008 01:57:57 +0530 (IST)
> Subject: Re: Re: Native Grid projection
>
> Malcolm,
> I look forward to seeing your example script. I would prefer to look
> at it before trying to comment on the coordinate rotation.
> Can you also send a data file that would allow your script to run?
> Thanks for the link to the MatLab functions.
> -dave
>
>
> On Nov 12, 2008, at 12:06 PM, malmistry_at_indiatimes.com wrote:
>
>> David,
>> Many thanks for your comments (in quotes)...I have replied to some
>> of them.
>>
>> "Actually what I was trying to say is not that the data was coming
>> from a WRF-GRIB file but simply that the specification of the
>> MAP_PROJ as 203 is more than........"
>>
>> I understand that now. Thank you.
>>
>> " The difficulty is that usually the lat/lon coordinates of such
>> grids are given in the rotated frame of reference. It requires some
>> trigonometry to convert these into un-rotated coordinates, but this
>> is necessary to plot such grids using NCL. We don't yet have a
>> function to do this calculation,
>> but it should become a priority"
>>
>> I hope to see these functions in NCL too. For everyone's info,
>> there are some functions in Matlab, such as 'org2pol', 'rotatem'
>> etc (link below)
>>
>> http://www.mathworks.com/access/helpdesk/help/toolbox/map/
>> index.html?/access/helpdesk/help/toolbox/map/rotatem.html
>>
>> "Also note that coordinates that can be expressed in the
>> rotated system using a single-dimensioned vector or simply as start,
>> step size, and number of grid points, need 2D lat and lon
>> coordinate arrays to be specified in the unrotated system. And
>> additionally note that you would only need to convert the grid
>> corners from rotated to un-rotated in order to do the "native"
>> grid plot."
>>
>> I am afraid, I did not understand this clearly (it sounds
>> important, could you please explain with some simple example).
>>
>> By the way, I have managed to plot the variable correctly (from my
>> originial WRF, Rotated Lat-Lon, E grid file), using
>>
>> res_at_sfXarray = glon
>> res_at_sfYarray = glat
>>
>> (where glat & glon are the geographic lat/lon in degrees of the
>> grid domain).
>>
>> But I could NOT plot it correctly as native grid. I shall send the
>> 2 scripts soon. Thanks to all of you for helping as I now
>> understand the "Native Grid" better.
>>
>> I do not actually need anything specific (such as WRF
>> postprocessor) for 'E Grid'. I was only testing this file as it had
>> the same projection to the new file (UMO model, B Grid) i am about
>> to start off with.
>>
>> The grid (E, B or whatever) is only important to know the grid
>> spacing/step size in the x and y direction, using which we can
>> compute the res_at_mpMinLatF, res_at_mpMaxLatF etc). However, because WRF
>> is well documented in NCL, I thought it was perhaps a good idea to
>> include the Rotated Lat-Lon feature of something like my file in
>> the documentation too.
>>
>> Once again, thanks to all of you...I shall email the scripts soon
>> as I would still like to plot the file using "Native Grid" method.
>>
>> Rgds
>> Malcolm
>> (Barcelona Supercomputing Center)
>>
>> ----- Original Message -----
>> From: David Brown <dbrown_at_ucar.edu>
>> To: malmistry_at_indiatimes.com
>> Cc: ncl-talk_at_ucar.edu
>> Sent: Wed, 12 Nov 2008 02:59:44 +0530 (IST)
>> Subject: Re: Re: Native Grid projection
>>
>> Malcolm,
>>
>> I will attempt to answer at least some of your questions. The
>> comments are interspersed.
>> On Nov 11, 2008, at 12:30 PM, malmistry_at_indiatimes.com wrote:
>>
>>> Dear Mary,
>>> Many thanks for your prompt reply. I appreciate your detail
>>> explanation. My remarks are between your comments.
>>>
>>>> However, I do see that you have some knowledge of the projection,
>>>> even
>>>> thought this didn't appear to be in complete form on your file, so
>>>> maybe this
>>>> is not an idealized case? Where did this file come from?
>>>
>>> The source of this file is WRF-NMM (E grid). It is not an idealized
>>> case, but the WRF expert (Wei Huang, Thank you!!) made me do a
>>> little research and I found this.
>>>
>>> (a) Pages (23-30) on http://www.mmm.ucar.edu/wrf/users/tutorial/
>>> 200807/NMM_Dynamics_jul2008_FINAL.pdf
>>>
>>>> Just a couple more things that Dave Brown mentioned after I sent
>>>> the last message. - MAP_PROJ = 203
>>>> this looks like it might be coming from a WRF-GRIB file?
>>>
>>> I doubt that (but once again, thank you for making me do more
>>> research on this). I do know that this is a Rotated Lat-Lon (from
>>> the above PDF link). Also, you will find more info on "MAP_PROJ",
>>> on the below two links (by just searching for "MAP_PROJ" or
>>> "Rotated" on these pages).
>>
>> Actually what I was trying to say is not that the data was coming
>> from a WRF-GRIB file but simply that the specification of the
>> MAP_PROJ as 203 is more than
>> a coincidence: the definition of GRIB GDS grid 203 is "Arakawa semi-
>> staggered E-grid on rotated latitude/longitude grid-point array (2-
>> dimensional)" and as
>> the citation you list above states, the WRF-NMM grid is "The Arakawa
>> E-grid stagger".
>>
>>>
>>> http://www.dtcenter.org/wrf-nmm/users/docs/user_guide/WPS/
>>> users_guide_nmm_chap5_v1_WPS.htm
>>> http://www.dtcenter.org/wrf-nmm/users/docs/user_guide/SI/
>>> users_guide_nmm_chap3_SI.php
>>>
>>> IMP!! -------The WRF parent file has a lot of variables. So I did
>>> 'ncks' on that to extract only 'TH10' variable (and send it in my
>>> previous mail). However, the parent file actually also contains
>>> GLAT & GLON (variables) which are not exactly the geographic lat/
>>> lon.
>>>
>>> I am trying to check how to convert that to geographic lat/long.
>>> The problem is that it is quite an awkward grid and as you
>>> correctly said, to plot it as "Native", more precise information
>>> would be required.
>>>
>>>> - If you indeed have a rotated lat/lon grid, you want to set
>>>> mpCenterLatF and mpCenterLonF (you currently have
>>>> them commented out), and *not* mpCenterRotF:
>>>
>>>> res_at_mpCenterLonF = 6.0 ; center
>>>> lon
>>>> res_at_mpCenterLatF = 42.5 ; center
>>>> lat
>>>> ; res_at_mpCenterRotF = 6.0
>>>
>>> I tried this as follows:
>>> ---------------------------------------
>>> ; res_at_mpCenterRotF = 6.0
>>> ; res_at_mpRelativeCenterLon = True
>>> res_at_mpCenterLonF = 6.0
>>> ; res_at_mpRelativeCenterLat = True
>>> res_at_mpCenterLatF = 42.5
>>> ----------------------------------------
>>>
>>> The plot still looks the same (with the same shift). If I use
>>> "res_at_mpRelativeCenterLatF = True" & "res_at_mpRelativeCenterLonF =
>>> True", the plot doesn't look correct. Hence I have commented them
>>> as I did not quite understand what purpose they serve exactly.
>>>
>>>> - You still need to get your map limits correct. Dave and I both
>>>> think this is where the problem is most likely arising. You
>>>> may have to do this by trial and error, if you don't have any
>>>> further information about the correct values.
>>>
>>> Absolutely! I too believe that the issue here is to define that
>>> correctly. At present I have used the info from global attributes
>>> to do simple math & calculate the corners of the grid domain (which
>>> may not be precise). But once I figure out the conversion of GLAT/
>>> GLON (variables) to geogphraphic lat/long (for a flat map), then I
>>> think I could try using the other method to plot, i.e the normal
>>> method using "res_at_sfXArray = glon , res_at_sfYArray = glat". This is
>>> also what you suggested in your email (3 Methods to plot).
>>>
>>> I have plotted this file in Ferret too and I can see the same
>>> shift! So I have more reasons to believe that NCL is doing what it
>>> is being told to do. The problem (as you suggested) is to know more
>>> about the model projection and coordinates. I will try to plot/
>>> compare more variables (such as SEA-MASK, which should give a
>>> better picture of any shift). The variable TH-10 is temperature and
>>> may actually (could) have a shift.
>>>
>>> Lastly, I have 2 QUESTIONS.
>>>
>>> (a) res_at_mpProjection = "CylindricalEquidistant". I checked the
>>> res_at_mpProjection and found other projections...but there's nothing
>>> like "Rotated Lat-lon". From an earlier query, I found Dennis's
>>> reply that usually "Cylindrical Equidistant" is the same as
>>> "Rotated Lat-Lon"
>>
>> In fact, there is no "rotated lat-lon" projection in NCL because
>> rotated lat-lon is simply a cylindrical equidistant projection with
>> mpCenterLonF and (especially) mpCenterLatF
>> set to non-zero values. The difficulty is that usually the lat/lon
>> coordinates of such grids are given in the rotated frame of
>> reference. It requires some trigonometry to convert
>> these into un-rotated coordinates, but this is necessary to plot such
>> grids using NCL. We don't yet have a function to do this calculation,
>> but it should become a priority
>> to add one. Also note that coordinates that can be expressed in the
>> rotated system using a single-dimensioned vector or simply as start,
>> step size, and number of grid points,
>> need 2D lat and lon coordinate arrays to be specified in the
>> unrotated system.
>>
>> And additionally note that you would only need to convert the grid
>> corners from rotated to un-rotated in order to do the "native" grid
>> plot.
>>
>>>
>>> (b) WRF-NCL processing scripts are incorporated into the NCL
>>> Libraries. Do you know of any example that could be closely related
>>> to my script/netcdf file?
>>>
>>> I will soon have another file based on a similar projection for
>>> regional domain (over western Europe), but "UMO Model, 'B' Grid.
>>> Hence I was testing my script with this WRF file.
>>
>> Someone else will need to answer this question.
>>
>>>
>>> Before I end my email, I would like to thank you all for doing a
>>> wonderful job (as support team). Not only your responses are
>>> prompt, they are also precise and with loads of examples.
>>>
>>> Best regards
>>> Malcolm
>>> (Barcelona Supercomputing Center)
>>>
>>> ----- Original Message ----------------------------
>>> From: Mary Haley <haley_at_ucar.edu>
>>> To: malmistry_at_indiatimes.com
>>> Cc: ncl-talk_at_ucar.edu
>>> Sent: Mon, 10 Nov 2008 23:05:00 +0530 (IST)
>>> Subject: Re: Native Grid projection
>>>
>>> Malcolm,
>>>
>>> Just a couple more things that Dave Brown mentioned after I sent the
>>> last message.
>>>
>>> - MAP_PROJ = 203 --> this looks like it might be coming from a
>>> WRF-GRIB file?
>>>
>>> - If you indeed have a rotated lat/lon grid, you want to set
>>> mpCenterLatF and mpCenterLonF (you currently have
>>> them commented out), and *not* mpCenterRotF:
>>>
>>> res_at_mpCenterLonF = 6.0 ; center
>>> lon
>>> res_at_mpCenterLatF = 42.5 ; center
>>> lat
>>> ; res_at_mpCenterRotF = 6.0
>>>
>>> - You still need to get your map limits correct. Dave and I both
>>> think this is where the problem is most likely arising. You
>>> may have to do this by trial and error, if you don't have any
>>> further information about the correct values.
>>>
>>> --Mary
>>>
>>>
>>> On Mon, 10 Nov 2008, Mary Haley wrote:
>>>
>>>> On Mon, 10 Nov 2008 malmistry_at_indiatimes.com wrote:
>>>>
>>>>> Dear Ncl users,
>>>>>
>>>>> I am a bit confused about Native grid projection (and after
>>>>> looking at
>>>>> the examples on NCL scripts, even a bit more).
>>>>>
>>>>> My doubts are in two parts. Part 1: in general on native proj.
>>>>> Part 2:
>>>>> specific to my script
>>>>
>>>> Dear Malcolm,
>>>>
>>>> I've included a long explanation below, for the benefit of other
>>>> users
>>>> who also have confusion with native projections.
>>>>
>>>> After reading over your email, looking at your file, and talking
>>>> to a
>>>> WRF expert here (Wei Huang), Wei suggested that maybe you have
>>>> idealized data, which is not meant to be plotted on a map. Your
>>>> file
>>>> doesn't appear to contain useful map projection information,
>>>> *and* it
>>>> doesn't include any lat/lon values, so there's no way to know
>>>> where on
>>>> the map to put the data.
>>>>
>>>> However, I do see that you have some knowledge of the projection,
>>>> even
>>>> thought this didn't appear to be in complete form on your file, so
>>>> maybe this
>>>> is not an idealized case? Where did this file come from?
>>>>
>>>> Please read further for more information.
>>>>
>>>>> --------------------PART 1-------------------------
>>>>>
>>>>> (a) On http://www.ncl.ucar.edu/Applications/list_maps.shtml ,
>>>>> there
>>>>> are a few projections defined and then there is Native projection.
>>>>
>>>> Just to be clear, the "native" projection is not a map
>>>> projection. It
>>>> just means that your data was defined on some specific map
>>>> projection,
>>>> like lambert conformal, and hence is native to that projection.
>>>>
>>>>> Suppose I have a model output file based on a certain UNKNOWN
>>>>> projection, with no coordinate variables eg. variable Temp is
>>>>> (z,y,x);
>>>>> where x/y are NOT lon/lat but model x/y grid points from 1 to
>>>>> 550. Would this be regarded as a Native grid projection?
>>>>
>>>> There's not enough information to answer this question.
>>>>
>>>> In order to correctly overlay data on a map, you need to have
>>>> one of
>>>> these three bits of information:
>>>>
>>>> 1. You need to have one-dimensional lat/lon coordinate arrays.
>>>>
>>>> 2. You need to have two-dimensional lat/lon arrays that represent
>>>> the lat/lon locations of your data array.
>>>>
>>>> 3. If you don't have #1 or #2, then you need to know the *exact*
>>>> map
>>>> projection your data was measured on. This constitutes a native
>>>> projection.
>>>>
>>>> It is possible to have both lat/lon arrays *and* to have a native
>>>> projection information. This allows you to put your data on a
>>>> different map projection than your native projection, if desired.
>>>>
>>>>> (b) If I define "res_at_tfDoNDCOverlay = True", it effectively means
>>>>> that my model projection is used without any transformation. Then
>>>>> do I
>>>>> still need to specify "res_at_mpProjection =
>>>>> CylindricalEquidistant/Lambert/..." ? If yes, then wouldn't this
>>>>> cause
>>>>> a conflict with "res_at_tfDoNDCOverlay = True"
>>>>
>>>> If you set "res_at_tfDoNDCOverlay = True", then you are indicating to
>>>> NCL
>>>> that you have data on a native projection. Hence you *must* set
>>>> mpProjection and other map resources in order to define the exact
>>>> map
>>>> projection and location your data was measured on. NCL can not
>>>> magically figure out from your data what map projection was used.
>>>>
>>>>> (c) If my projection is native and "res_at_tfDoNDCOverlay = True",
>>>>> what
>>>>> purpose does "res_at_mpLimitMode = LatLon/Corner" serve? I understand
>>>>> that this is just a way to zoom in. But your tutorial says that
>>>>> if it
>>>>> is Native projection, then "res_at_mpLimitMode = Corner" (ALWAYS!!).
>>>>
>>>> The documentation is misleading here. The mpLimitMode resource
>>>> doesn't
>>>> necessarily have to be set to "corners", but this is a common
>>>> setting.
>>>>
>>>> However, again, for a native projection, you must know the
>>>> projection
>>>> and the location on the map of your data, so you will need to set
>>>> "mpProjection" (or use one of the specific map projection functions
>>>> like gsn_csm_contour_map_ce), *and* you will most likely need to
>>>> set
>>>> "mpLimitMode" and associated resources to indicate the location on
>>>> the
>>>> globe of your data. In addition, in order to get the right
>>>> orientation, you might need to set other resources, like
>>>> mpCenterLonF
>>>> or mpCenterLatF.
>>>>
>>>> This is why it's important that you know the exact map projection
>>>> that your data was measured on. Usually, this information comes
>>>> with
>>>> the data file that your data is on, like global attributes
>>>> on the file. This is certainly the case for WRF data files.
>>>>
>>>> If you look at the global attributes on your WRF file, you'll see
>>>> values like:
>>>>
>>>> MAP_PROJ : 203
>>>> CEN_LAT : 42.5
>>>> CEN_LON : 6
>>>> TRUELAT1 : 1e+20
>>>> TRUELAT2 : 1e+20
>>>>
>>>> These usually indicate map projection parameters, but the
>>>> MAP_PROJ=203
>>>> looks wrong to me. Also, TRUELAT1 and TRUELAT2 are missing.
>>>>
>>>> I don't know enough about WRF files to know what the values above
>>>> mean, but I don't think you don't have enough information on this
>>>> file
>>>> to determine how to correctly overlay your data on a map.
>>>>
>>>>> (d) Is "res_at_gsnAddCyclic = False" absolutely necessary for
>>>>> regional
>>>>> data files ?
>>>>
>>>> It doesn't hurt to set it if you have regional data. It just tells
>>>> NCL
>>>> not to try to add a wrap-around point in the longitude direction,
>>>> which you definitely don't want for regional data. However, NCL can
>>>> sometimes figure this out on its own. It just depends on the
>>>> nature of
>>>> your data. You can try not setting this resource, and if things
>>>> look
>>>> really bad or you get a warning that you might need to set it, then
>>>> go ahead and set it.
>>>>
>>>> I don't think this resource is the source of your problem here,
>>>> though.
>>>>
>>>>> --------------------PART 2-------------------------
>>>>>
>>>>> Attached is my WRF output (.nc) file. It is Regional data based on
>>>>> Rotated Lat-Lon (I assume the same as Cylindrical Equidistant
>>>>> Projection). The center (origin) is shifted to 42 deg N, 6 deg
>>>>> E. Below is my NCL script defining the Limit window using LatLon
>>>>> method and also giving a rotation of 6 deg (as the shifted pole
>>>>> would
>>>>> be 6.0 deg E)
>>>>
>>>> Given that you know all this information, I'm a bit confused
>>>> by the WRF file you included, as it doesn't have what looks to
>>>> be complete map information.
>>>>
>>>>> Since there are no coordinate variables, I assume it is a Native
>>>>> Grid
>>>>> issue. By doing ncdump on the file, I have used the additional
>>>>> info to
>>>>> write the script (attached).
>>>>
>>>> That's usually a safe assumption, especially given that it's a WRF
>>>> file. But again, you would then expect to see other information
>>>> on the file about the map projection used.
>>>>
>>>>> I have compared the plot with NCView and I can definitely say
>>>>> that the
>>>>> plot shifts a little (this is easily evident by looking at Italy
>>>>> where
>>>>> the contour should be within the boundary).
>>>>>
>>>>> I have tried different things (such as using different
>>>>> LimitMode). The
>>>>> mpMinLatF / mpMinLonF etc are calculated using the grid spacing &
>>>>> the
>>>>> center of domain (42.5 deg N, 6.0 deg E) which is the shifted
>>>>> origin. This should mean that the shifted pole is 6.0 deg E.
>>>>>
>>>>
>>>> I think the problem is that you are close to getting the right
>>>> map projection, but you to be *exact* on this in order for it to
>>>> look right.
>>>> You probably have the mpCenterLatF and mpCenterRotF
>>>> resources set correctly, but I'm thinking that you may need
>>>> to check your values for the lat/lon corners.
>>>>
>>>> Try tweaking these values, or else try find some more information
>>>> that would tell you exactly what they need to be.
>>>>
>>>>> (e) Is it necessary to know the exact origin / pole etc if this
>>>>> is a
>>>>> native projection?
>>>>
>>>> Yes.
>>>>
>>>> --Mary
>>>>
>>>>
>>>>> Am not sure why the plot is still not correct. Hoping to
>>>>> understand
>>>>> this better....Thanks in advance.
>>>>>
>>>>> Malcolm
>>>>> (Barcelona Supercomputing Center)
>>>>>
>>>>>
>>>>> --
>>>>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>>>>> ZigWheels.com
>>>>> http://www.zigwheels.com/b2cam/newsDetails.action?
>>>>> name=Emb11_20080731&path=/INDT/News/
>>>>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=fo
>>>>> o
>>>>> t
>>>>> er&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>>>>>
>>>> _______________________________________________
>>>> ncl-talk mailing list
>>>> List instructions, subscriber options, unsubscribe:
>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>>> ZigWheels.com
>>> http://www.zigwheels.com/b2cam/newsDetails.action?
>>> name=Emb11_20080731&path=/INDT/News/
>>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=foot
>>> e
>>> r
>>> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>>>
>>>
>>>
>>> --
>>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>>> ZigWheels.com
>>> http://www.zigwheels.com/b2cam/newsDetails.action?
>>> name=Emb11_20080731&path=/INDT/News/
>>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=foot
>>> e
>>> r
>>> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>>>
>>>
>>>
>>> --
>>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>>> ZigWheels.com
>>> http://www.zigwheels.com/b2cam/newsDetails.action?
>>> name=Emb11_20080731&path=/INDT/News/
>>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=foot
>>> e
>>> r
>>> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>>> _______________________________________________
>>> ncl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>>
>>
>>
>> --
>> Hyundai to launch the i20 in India. Catch the exclusive preview on
>> ZigWheels.com
>> http://www.zigwheels.com/b2cam/newsDetails.action?
>> name=Emb11_20080731&path=/INDT/News/
>> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=foote
>> r
>> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
>
>
>
>
>
> --
> Hyundai to launch the i20 in India. Catch the exclusive preview on
> ZigWheels.com
> http://www.zigwheels.com/b2cam/newsDetails.action?
> name=Emb11_20080731&path=/INDT/News/
> Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer
> &utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW<wrf_native.ncl
> ><wrf.nc><wrf_glatlong.ncl>

--
Hyundai to launch the i20 in India. Catch the exclusive preview on ZigWheels.com
http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
--
Hyundai to launch the i20 in India. Catch the exclusive preview on ZigWheels.com
http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk