Re: Native Grid projection

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=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
Received on Mon Nov 10 2008 - 10:01:34 MST