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
>
>
>
>
Received on Sat May 31 2014 - 03:35:44 BST
