Re: Native Grid projection

From: Mary Haley <haley_at_nyahnyahspammersnyahnyah>
Date: Mon, 10 Nov 2008 10:35:00 -0700 (MST)

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=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
>
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Mon Nov 10 2008 - 10:35:00 MST

This archive was generated by hypermail 2.2.0 : Fri Nov 14 2008 - 16:42:12 MST