Hi Jim,
one last question: Suppose I store multiple images in a single netCDF
file and each image has its own coordinates (think of the ISS flying
around earth and you take a sequence of images). Would it be allowed to
have:
dimensions:
time = 10 ;
y = 2832 ;
x = 4256 ;
channel = 3 ;
double lat(time, y, x);
double lon(time, y, x);
short img(channel, time, y, x);
img:coordinates = "lat lon" ;
...
I couldn't find any example where the coordinate arrays varied over time.
Thanks
Maik
On 02/06/14 15:44, Jim Biard wrote:
> 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/dd381168/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140602/dd381168/attachment-0001.png>
Received on Mon Jun 02 2014 - 09:56:50 BST
