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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140530/7ebedd26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aahjehcc.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140530/7ebedd26/attachment-0001.png>
Received on Fri May 30 2014 - 13:01:12 BST
