Maik,
Your coordinate variables in your example are latitude and longitude.
You don't have any other ones. Remember that dimension names and
variable names are not significant. The standard_name attribute value
(and, to a lesser degree, the axis attribute value) are the only things
that matter. If you had a coordinate variable with a standard name of
"projection_x_coordinate", then you would have an "x" coordinate
variable. Your coordinate variables have standard names of "longitude"
and "latitude".
CF examples are often incomplete, in an attempt to allow the particular
thing being exampled to stand out more clearly. I agree that it's
frustrating at times, as it can be hard to pull all the parts together.
It would be nice to have both the minimal examples and fully-realized
versions. That's quite an undertaking though.
Grace and peace,
Jim
On 5/31/14, 5:35 AM, Maik Riechert wrote:
> Thanks for confirming that I can use grid mapping in that way. Maybe
> then the following sentence isn't enough to capture that intent:
>
> "When the coordinate variables for a horizontal grid are longitude and
> latitude, a grid mapping variable with grid_mapping_name of
> latitude_longitude may be used to specify the ellipsoid and prime
> meridian." (CF1.6 section 5.6)
>
> In my case the coordinate variables are x and y, and not longitude and
> latitude which is why I thought I couldn't use latitude_longitude here.
>
> Also, I think it is a good idea to include grid_mapping for every
> applicable example in the CF document, with a forward reference in cases
> where grid_mapping wasn't defined yet (before 5.6). If it's not possible
> to make it a requirement, then at least CF should promote it as much as
> possible.
>
> Cheers
> Maik
>
> Am 30.05.2014 21:01, schrieb Jim Biard:
>> Maik,
>>
>> I think it would be good to make a CRS specification a requirement for
>> every variable with geographic coordinates. Backward compatibility
>> requires that we allow a default in the case that nothing was specified.
>> This is all further complicated by numerous data sets which have been
>> produced with physical latitudes and longitudes, but no CRS was
>> specified. So it's a messy situation.
>>
>> Your example looks good to me.
>>
>> Grace and peace,
>>
>> Jim
>>
>>
>> On 5/30/14, 11:37 AM, Maik Riechert wrote:
>>> Hi Jim
>>>
>>> Thanks for the detailed explanations.
>>>
>>> If a spherical earth (of a certain radius) is the default, shouldn't it
>>> be defined as such? Otherwise, having latitude and longitude coordinates
>>> without a datum, as in example 5.2, would represent (partially) useless
>>> data, quoting ISO: "without the full specification of the coordinate
>>> reference system, coordinates (that is latitude and longitude) are
>>> ambiguous at best and meaningless at worst".
>>>
>>> As for the coordinate variables, just to be sure, let's visualize it a bit:
>>> http://eol.jsc.nasa.gov/sseop/images/ESC/large/ISS030/ISS030-E-84614.JPG
>>>
>>> Let's assume for each pixel center I know the latitude and longitude --
>>> for those pixels covering the earth. That gives me each an auxiliary 2D
>>> coordinate array for latitude and longitude. It is an irregular grid of
>>> course. I would model this data as:
>>>
>>> dimensions:
>>> xc = 4256 ;
>>> yc = 2832 ;
>>> band = 3 ; // red, green, blue
>>> variables:
>>> byte img(yc,xc,band) ;
>>> img:long_name = "color intensity" ;
>>> img:units = "unitless" ;
>>> img:valid_min = 0 ;
>>> img:valid_max = 255 ;
>>> img:coordinates = "lon lat" ;
>>> img:grid_mapping = "crs";
>>> float lon(yc,xc) ;
>>> lon:standard_name = "longitude" ;
>>> lon:long_name = "longitude" ;
>>> lon:units = "degrees_east" ;
>>> float lat(yc,xc) ;
>>> lat:standard_name = "latitude" ;
>>> lat:long_name = "latitude" ;
>>> lat:units = "degrees_north" ;
>>> int crs ;
>>> crs:grid_mapping_name = "latitude_longitude";
>>> crs:semi_major_axis = 6378137.0 ;
>>> crs:inverse_flattening = 298.257223563 ;
>>>
>>> Is that correct? I am new to the field so please don't hesitate to give
>>> any kind of suggestion :)
>>>
>>> Cheers
>>> Maik
>>>
>>> Am 30.05.2014 16:20, schrieb Jim Biard:
>>>> Maik,
>>>>
>>>> You have wandered into an area that has a few hot-button topics
>>>> associated with it. I'll see if I can help clarify without riling anyone
>>>> else. :)
>>>>
>>>> Here we go, in order of your questions:
>>>>
>>>> The spherical Earth is a default. It harkens back to CF's origins in the
>>>> modeling community, where they often use a spherical Earth.
>>>>
>>>> The latitude and longitude coordinates variables, if they are true
>>>> coordinate variables (and not auxiliary coordinate variables) must each
>>>> be monotonic. If they are auxiliary coordinate variables, I don't think
>>>> there is any constraint.
>>>>
>>>> The naming "grid_mapping" is (personally) a less-than-perfect choice.
>>>> The variable named by the grid_mapping attribute contains Coordinate
>>>> Reference System (CRS) information. Even a latitude-longitude CRS needs
>>>> to be declared, as there are a number of these. (Their differences are
>>>> largely ignorable if you are working on 2.5 degree centers, but that is
>>>> an assumption that may not be warranted with observation data.) The
>>>> variable named by the grid_mapping attribute contains the declaration of
>>>> the horizontal datum, whether it is for a projected CRS or a
>>>> latitude-longitude CRS. Declarations of the vertical datum are still
>>>> being ironed out.
>>>>
>>>> Depending on what you were wanting to do, you should be able to use the
>>>> contents of the variable named by the grid_mapping attribute, along with
>>>> a geographic coordinate system package, to convert the values in
>>>> variables containing X-Y coordinates or latitude-longitude coordinates
>>>> into any other reachable CRS. (Not all CRSs are reachable from all other
>>>> CRSs, but that's a different problem.) If you have both X-Y and
>>>> latitude-longitude coordinates in your file, the software can use
>>>> whichever it chooses, and can convert to another CRS however it choses.
>>>> If you only have latitude-longitude coordinates in your file, the
>>>> software can use those straight, or can convert to another CRS, but for
>>>> precise conversion you need to know which ellipsoid to use (and where
>>>> the origin is located, etc) for the latitudes and longitudes in the file.
>>>>
>>>> Does that help?
>>>>
>>>> Grace and peace,
>>>>
>>>> Jim
>>>>
>>>> On 5/29/14, 6:30 PM, Maik Riechert wrote:
>>>>> Hi,
>>>>>
>>>>> I am confused about the following sentence in CF 1.6 under the
>>>>> Latitude-Longitude heading in appendix F:
>>>>>
>>>>> "This grid mapping defines the canonical 2D geographical coordinate
>>>>> system based upon latitude and longitude coordinates on a spherical Earth."
>>>>>
>>>>> First, why "spherical"? In example 5.9 it is used with WGS84.
>>>>>
>>>>> Then, does the first sentence refer to a grid which must be regular? Can
>>>>> it also be rectilinear? Or even irregular?
>>>>>
>>>>> I think my main confusion is that latitude_longitude and
>>>>> rotated_latitude_longitude are probably not projections but the rest of
>>>>> the grid mappings is. Yet there is no clear differentiation between the
>>>>> two types in appendix F.
>>>>>
>>>>> I think the term "grid mapping" also adds to my confusion. To me, it
>>>>> means that I define a mapping from my data array (the grid) to
>>>>> latitude/longitude coordinates in a descriptive way, that is, as an
>>>>> implicit transformation operation described by the parameters of the
>>>>> grid mapping variable. In the case of the projections it makes sense.
>>>>> You can completely ignore the latitude/longitude arrays and just use the
>>>>> grid mapping to recompute the latitudes/longitudes (if you were a
>>>>> software that draws the data on a map). Right? But for
>>>>> latitude_longitude and rotated_latitude_longitude, this is not the case.
>>>>> Here the software would be required to use the latitude/longitude
>>>>> arrays. Is this right? If yes, then should I consider latitude_longitude
>>>>> as a datum definition with an unknown projection?
>>>>>
>>>>> I hope I could explain my confusion while not confusing you too.
>>>>>
>>>>> Thanks for your time,
>>>>> Maik
>>>>> _______________________________________________
>>>>> CF-metadata mailing list
>>>>> CF-metadata at cgd.ucar.edu
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>> --
>>>> CICS-NC <http://www.cicsnc.org/> Visit us on
>>>> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
>>>> *Research Scholar*
>>>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>>>> North Carolina State University <http://ncsu.edu/>
>>>> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
>>>> 151 Patton Ave, Asheville, NC 28801
>>>> e: jbiard at cicsnc.org
>>>> o: +1 828 271 4900
>>>>
>>>>
>>>>
>>>>
>> --
>> CICS-NC <http://www.cicsnc.org/> Visit us on
>> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
>> *Research Scholar*
>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
>> North Carolina State University <http://ncsu.edu/>
>> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbiard at cicsnc.org
>> o: +1 828 271 4900
>>
>>
>>
>>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140602/2934680c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bijfdjij.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140602/2934680c/attachment-0001.png>
Received on Mon Jun 02 2014 - 07:44:02 BST
