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

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
>>
>