Jonathan,
>From an application writer's point of view, it is preferable to separate the
projection parameters into separate attributes. It's just easier and more accurate
to write an application to get the correct datatype and value of the parameter(s)
if they are separated out, and this will translate into more robust applications.
True, we could write code to parse a (combined) projection attribute, but this
isn't necessarily easy to do such that the code is portable, maintainable,
extensible, and usable for all languages and APIs!
Best regards,
Bob
Jonathan Gregory wrote:
> Dear Brian
>
> Thanks for your posting. It could be that this discussion depends on personal
> preferences. You wrote
>
> > I'm not in favor of individual attributes unless the projection can be
> > factored out.
>
> so I'll address that first. Sorry I was sloppy in referring to the proposed
> method for defining projections as an attribute, when it is actually a
> variable with attributes.
>
> The current CF proposal has the advantage of showing the name of the mapping
> (rotated_latitude_longitude in this example). It has
>
> float T(lev,rlat,rlon);
> T:units="K";
> T:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
> float precipitation(lev,rlat,rlon);
> T:units="kg m-2 s-1";
> T:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
>
> whereas in the new proposal (modified because grid-mappings are not necessarily
> projections) we would have
>
> char mymapping(p_len);
> mymapping:grid_mapping_type="rotated_latitude_longitude";
> mymapping:grid_north_pole_latitude=32.5;
> mymapping:grid_north_pole_longitude=170.0;
>
> ... other stuff ...
>
> float T(lev,rlat,rlon);
> T:units="K";
> T:grid_mapping="mymapping";
> float precipitation(lev,rlat,rlon);
> T:units="kg m-2 s-1";
> T:grid_mapping="mymapping";
>
> I find the latter less convenient to read, actually. Whereas in the former
> case, when I am looking at the data variable I have the mapping right in front
> of me, in the latter I have to remember its name while looking somewhere else
> in the CDL file to find out what it is. The name itself may not tell me any-
> thing about the projection, especially if it has been generated automatically.
>
> If the mappings of two variables are not the same, because they come from
> different models, for instance, again I think this factoring-out makes the
> CDL file less easy for a human to read. In the current CF proposal we have
>
> float Thadley(lev,rlat,rlon);
> Thadley:units="K";
> Thadley:institution="Hadley Centre";
> Thadley:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
> float Tncar(lev,rlat,rlon);
> Tncar:units="K";
> Tncar:institution="NCAR";
> Tncar:grid_mapping="lambert_conformal_conic ",
> "standard_parallel: 25.0 longitude_of_central_meridian: -95.0 ",
> "latitude_of_projection_origin: 25.0";
>
> and in the new proposal we have
>
> char hadleymapping(p_len);
> hadleymapping:grid_mapping_type="rotated_latitude_longitude";
> hadleymapping:grid_north_pole_latitude=32.5;
> hadleymapping:grid_north_pole_longitude=170.0;
> char ncarmapping(p_len);
> ncarmapping:grid_mapping_type="lambert_conformal_conic";
> ncarmapping:standard_parallel=25.0;
> ncarmapping:longitude_of_central_meridian=-95.0;
> ncarmapping:latitude_of_projection_origin=25.0;
>
> ... other stuff ...
>
> float Thadley(lev,rlat,rlon);
> Thadley:units="K";
> Thadley:institution="Hadley Centre";
> Thadley:grid_mapping="hadleymapping";
> float Tncar(lev,rlat,rlon);
> Tncar:units="K";
> Tncar:institution="NCAR";
> Tncar:grid_mapping="ncarmapping";
>
> Looking at the data variables of the new proposal, I have no information about
> what the mappings are except that they are probably different - even that is
> not certain because the definitions might be identical. In the present
> proposal, it is obvious that they really are different, and also I can see the
> definitions of the mappings in the same place in the file.
>
> You're right, the factoring-out is the same as with coordinate variables.
> Coordinate variables also have the consequent difficulty that you have to do
> some complicated programming to avoid writing duplicate coordinate variables to
> a file. I would say that is a *problem* with coordinate variables, rather than
> a feature of them that we want to use for grid mappings as well! In the case of
> coordinate variables, we do it that way because their space requirements are
> not trivial, but for grid mappings that is not an issue, as we have agreed.
>
> Regarding the other point, you write
>
> > I would argue that reading inidividual attributes directly into variables of
> > the right type is easier than parsing a string and converting string values
> > to the proper type. But ease of use is very subjective. It depends on what
> > tools are at your fingertips.
>
> Point taken. To address this, I propose we provide a parser for the
> grid_mapping attribute, which decomposes it into key-value pairs, checks the
> keywords are valid (from its knowledge of the allowed mappings), checks the
> syntax for valid numbers and casts them into the right type. This should not
> be very hard. We have to do most of this for other kinds of CF attribute as
> well, so such a utility would have several uses.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Feb 18 2003 - 10:53:51 GMT
