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

RE: M3IOConvention



Hi John,

If I could add my $0.02 ... all M3IO files at this point should be assumed to 
have a radius of 6370000.000 m.  The CMAQ team made the change to be consistent 
with that value quite some time ago.  It  certainly would have been helpful to 
have had that in the M3IO spec for clarity.  So, my suggestion would be to 
assume the value of 6370000.000 m unless a file comment attribute indicates 
otherwise.

Donna Schwede

-----Original Message-----
From: Plessel, Todd 
Sent: Tuesday, February 26, 2013 1:55 PM
To: John Caron; Schmunk, Robert B. (GISS-611.0)[TRINNOVIM, LLC]
Cc: Unidata netCDF Java Support; Schwede, Donna; address@hidden; Paulsen,  Heidi
Subject: Re: M3IOConvention


Hi John,

Thanks for the note.
The M3IO spec does not include the spheroid / radius.
However, on rare occasions an M3IO file might contain a hint in the 'file 
comment' attribute:
"EARTH RADIUS ASSUMED IN MCIP:  6370000.000 m"
I agree that it would be easy and worthwhile to add logic to 
M3IOConvention.java To check for this and, if found, use it.

Can you do this John?
I don't have an up-to-date version of that file.
(Also, remove M3IOVGGridConvention.java since it is redundant and apparently 
(discovered by Liz Adams) does not project stereographic correctly while 
M3IOConvention.java does.)

Todd


On 2/25/13 4:51 PM, "John Caron" <address@hidden> wrote:

>Hi Robert:
>
>It would be simple to modify M3IOConvention.java to look for this 
>information, and pass the radius to the projection:
>
>       new LambertAzimuthalEqualArea(lat0, lon0, 0.0, 0.0, 6370000.0);
>
>I notice that the sample file i have does not have that info in it. I 
>am cc'ing Todd Plessel, the original author, to see if he has any 
>comments or wants to add this feature.
>
>Regards,
>John
>
>
>On 1/28/2013 1:22 PM, Schmunk, Robert B. (GISS-611.0)[TRINNOVIM, LLC]
>wrote:
>>
>> John,
>>
>> A Panoply user had a problem with a small shift in the placement of a 
>> projected lon-lat grid in a netCDF dataset. The gridding uses the 
>> Lambert conformal conic grid, and the dataset was written using the 
>> M3IO convention. I got into the netCDF-Java source code for 
>> ucar.nc2.dataset.conv.M3IOConvention.java to see if I could get a 
>> better grip of what was going on and found that that class is looking 
>> for a grid type specified by the dataset's GDTYP global attribute.
>> Further definition of the grid is determined by checking the XCENT, 
>> YCENT, P_ALP, and P_BET attributes.
>>
>> The problem that is arising is that there is apparently no way to 
>> pass along the value of the Earth radius used by the projected grid.
>> M3IOConvention.java is not looking for the value and is defaulting to
>> 6,371.229 km, but the grid in the problem dataset is based on a 
>> radius of 6370 km. (A very small diference, but the effect is visible 
>> in a plot a couple egrees on a side.) The dataset (and perhaps the 
>> M3IO format) do not include a single specific attribute for the Earth 
>> radius, but does include info about it in a FILEDESC global 
>> attribute, a very long string which includes "Š EARTH RADIUS ASSUMED 
>> IN MCIP:  6370000.000 m Š".
>>
>> Is it possible that in a coming update to the NJ libraries that 
>> M3IOConvention.java could be coded to look for this radius 
>> information in the FILEDESC attribute? Or do you have any suggestions 
>> on how one might otherwise deal with this non-default radius? The 
>> user who contacted me about this apparently has hundreds of similar 
>> files, so we're looking for a consistent gridding/plotting solution.
>>
>>
>> rbs
>>
>>
>> -- Robert B. Schmunk Webmaster / Senior Systems Programmer NASA 
>> Goddard Institute for Space Studies 2880 Broadway, New York, NY
>> 10025
>>
>