[CF-metadata] Clarifications on latitude_longitude

From: Eizi TOYODA <toyoda> Date: Wed, 25 Jun 2014 11:48:14 +0900 · This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

--
Eiji (aka Eizi) TOYODA
http://www.google.com/profiles/toyoda.eizi
On Sat, May 31, 2014 at 4:01 AM, Jim Biard <jbiard at cicsnc.org> wrote:
>  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 listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>  --
> CICS-NC <http://www.cicsnc.org/> <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> <http://www.facebook.com/cicsnc> 	*Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/> <http://ncsu.edu/>
> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/> <http://ncdc.noaa.gov/>
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org
> o: +1 828 271 4900
>
>
>
>
>
>
> --
>       [image: 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
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140625/aff396f1/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/20140625/aff396f1/attachment-0001.png>