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 >>>> [email protected] >>>> 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: [email protected] >>> 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: [email protected] > o: +1 828 271 4900 > > > > _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
