latitude_longitude grid mapping

[taylor13]

Question

The description of latitude_longitude grid mapping here mentions that "It is included so that the figure of the Earth can be described", but it doesn't list any "Map Parameters". Shouldn't it list at least as options semi_major_axis, inverse_flattening, and longitude_of_prime_meridian as in examples 5.9, 5.10, 5.11, 5.19, 7.15, and 7.16? These all appear in Table F.1 and are described as grid mapping attributes.

[davidhassell]

The top of Appendix F: Grid Mappings says:

The attributes which describe the ellipsoid and prime meridian may be included, when applicable, with any grid mapping. These are:
earth_radius
inverse_flattening
longitude_of_prime_meridian
prime_meridian_name
reference_ellipsoid_name
semi_major_axis
semi_minor_axis

and none of these are included in the definition of the individual mappings.

However, I agree with Karl, that in the special case of latitude_longitude, it wouldn't be a bad thing to re-list these parameters for that particular grid mapping.

[JonathanGregory]

Perhaps it would be sufficient to say that the attributes for describing the figure of the Earth are the ones listed at the start of Appendix F? If we list them again, there's a small risk of inconsistency developing in future. We could also consider providing an example which uses grid mapping for just that purpose in the grid mapping section.

[davidhassell]

That works for me, Jonathan. Thanks.

[taylor13]

O.K., I missed the key sentence just above the list of 7 mapping parameters that can apply to any mapping. Perhaps for each of the mapping options (not just latitude_longitude) we should include a line under "Map Parameters:" we should include the sentence:
"Any of the parameters describing the figure of Earth listed at the beginning of this Appendix."

I think there are already several examples in sections 5 and 7 that show for the latitude_longitude mapping that these parameters can be attached.

[larsbarring]

Well I both agree and disagree. Reshuffling/summarising comments a bit (hopefully without obfuscating the originally intended meaning):

1. Initially Karl asks: Shouldn't the description of latitude_longitude grid mapping here list at least as options semi_major_axis, inverse_flattening, and longitude_of_prime_meridian ?
2. And David responds: The top of Appendix F: Grid Mappings gives this information.
3. ... and then in the same comment David continues: " in the special case of latitude_longitude, it wouldn't be a bad thing to re-list these parameters for that particular grid mapping."
4. Then Jonathan suggests: it would be sufficient to say that the attributes for describing the figure of the Earth are the ones listed at the start of Appendix F.

I agree with 1, 2, and 4, but strongly disagree with 3 for the following reasons:

• The latitude_longitude grid mapping is one of two listed grid mappings that actually allow at least a reasonable geo-location of the data without knowledge of the size/shape of the earth. The other one is rotated_latitude_longitude. Of course, with information on the size/shape of the earth the data can be more precisely geo-located.
• All other grid mappings involve a map projection from a grid coordinate system to latitude/longitude. For all these the following situations arises if the grid mapping is specified without size/shape information:
  A) Grid coordinates and latitude/longitude are available. Then it is in principle possible to infer the size/shape parameters, but in practice it is awkward. And without the size/shape information the situation is similar to that of latitude_longitude that Karl pointed at in the initial post.
  B) Only latitude/longitudes are available. Then it is not possible to infer the grid coordinates, and we are back to the situation that Karl describes.
  C). Only grid coordinates are given. Then it is not even possible to calculate latitude and longitude.

That is, for all grid mappings listed in Appendix F it is always an advantage to specify the size/shape of the earth (or whatever planet/body in focus).

Moreover, in situation C, which is allowed since CF-1.9 it is necessary to specify size/shape to allow calculation of latitude/longitude.

[davidhassell]

Hi Lars, Having originally suggested it, I also disagree with 3, as noted above :) I see 3. is just a less redundant version 4.

Are you suggesting with your further observations that some/all of the shape parameters should be mandatory on latitude_longitude and rotated_latitude_longitude grid mapping? (that's not a leading question - I'm just curious!)

[larsbarring]

I was a bit imprecise, what I oppose to regarding 3 is that the the lat/lon grid mapping is special in the sense implied, i.e. that it should be more relevant to include size/shape for this grid mapping than for any other. I argue that it is exact the other way around: It is less relevant.

If you include just the size/shape parameters and no other map projection information for the lat/long grid mapping, what can you use it for?
-- you cannot infer the original model grid coordinates (probably not of any interest/relevance anyway).
-- however you can use the information together with a map projection (etc.) of your liking to e.g. provide a more exact geo-positioning of the data, or to plot a map according to some specified/required projection. Without size/shape information you have to instead make assumptions regarding this if you want to use you data for that purpose.

So, for lat/lon (and rotated lat/lon) grid mapping it is useful to have size/shape information but not required.

For all other grid mappings listed in Appendix F, either it is useful, or it is necessary to have size/shape information.

Hence, I suggest that what should be done is

• Add a sentence along what Jonathan suggests to all grid mappings.
• In the introductory text to Appendix F clearly specify that shape/size parameters are required for all map projections if lat/lon coordinates are not provided. Exceptions are of course the lat/lon and rotated lat/lon map projections.

[taylor13]

I added a thumbs up for Lars' suggestions above, but on further reflection, I'm not sure I understand whether the second bulleted item is a good idea. The first item falls along the lines of the suggestion I made here.

[larsbarring]

@taylor13 I am happy that we agree (all agree as it seems from comments so far) regarding the first point. Could you be more specific in your concerns regarding the second bullet point?

[taylor13]

O.K., after rereading a few of the above, I think I see what you are saying @larsbarring, but I don't think I agree with the second point. I don't think we should necessarily require that attributes like earth_radius and inverse_flattening be defined when lon and lat coordinates are not given. If they're undefined the user will, of course, need to assume some presumably reasonable value, but for many purposes, that should be sufficient, I think. But perhaps I've still misunderstood why they should be required. Under what conditions would they be absolutely necessary (assuming you're comfortable in being off a bit in geolocating a gird-cell's position)?

[larsbarring]

Karl, @taylor13, with what you write it seems that we now also agree on the "problem description":

If they're undefined the user will, of course, need to assume some presumably reasonable value ...

This is exactly the point I am making: to correctly geolocate the data lat/lon is required, and if not provided they have to be possible to calculate. And to carry out such a calculation enough information regarding the map projection has to be provided. And, information regarding the size/shape of the earth (or more generally the body) is part of that requirement. I take this to be a matter of fact. As such it should be made clear in the CF Conventions text.

You continue

... but for many purposes, that should be sufficient ...

I would agree to that for some (whether that is many or not I do not know) it is sufficient to pick a reasonable value if the necessary parameters are missing. But I also know that for many applications this is not acceptable. From somewhere (I can't recall where) I have it that the error could be as large as 20 km if you are picking the wrong -- but still reasonable -- size/shape parameters. Limited area models are nowaday regularly run at 1-3 km scale in climate simulation mode, and at sub-km scale in NWP mode, and around the corner are GCMs/ESMs at km-scale coming along. In this perspective 20 km error is huge and I would say unacceptable. It may put precipitation on the wrong side of mountains, mangle lake and coastal effects, and much more.

To my mind the key thing is that the CF Conventions should (must! I would argue) be clear about what the implication would be if some information is not included. However, this is not to say that the CF Convention must require this information to included. If it, for legacy arguments, is impossible for the CF Conventions to actually require the information to be included I suggest that text could still be crafted that states something along these lines:

"... if lat/lon is not provided the complete map projection must be provided to enable geolocation of the data. Therefore, the Conventions strongly recommend that size/shape parameters are given in combination with the specific parameters for each map projection ...."

[sethmcg]

I would support a recommendation to include the parameters, but we should consider the issue that they may be ill-defined.

There are datasets that have been produced by models that assume a spherical Earth, but use land cover datasets that are based on WGS84, and just read the data in as if it were on a sphere. Maybe things have gotten better since I ran into this problem, but we should consider the possibility.

[taylor13]

I think that for all existing global climate models and for the observations they are compared with, there are no consequences of importance in leaving out information about earth's size or shape. All models I'm familiar with assume a spherical earth and some radius that is close to the mean radius of earth. Mountains are located at the longitudes and latitudes where they are found, and ocean and land are not shifted from their observed longitude and latitude positions. The simulated climate recorded as a function of latitude can be compared to the observed climate at those same longitudes and latitudes.

I'm not that familiar with the map projections used for regional models. Can someone say for some common use cases what the implications would be if size or shape parameters were omitted?

[larsbarring]

@ljoakim Could you please give a brief outline of your experiences

Earlier today I learnt that Joakim is not available for some time, I will try to retrace what we encountered.
/Lars

[Armin-RS]

The German national meteorological service "Deutscher Wetterdienst" (my employer) uses a polar stereographic projection for their radar precipitation data (https://www.dwd.de/radolan). Recently the shape of the Earth in this projection was changed from spherical to the WGS84 ellipsoid. The result is that the area covered by the 900 x 900 nominal 1km x 1km grid cells expands in the east-west direction by a distance which is equivalent to several grid points on both sides of the domain.
So in this case, it is indeed important to know the shape of the Earth used in the definition of the coordinate system.

[pvanlaake]

If they're undefined the user will, of course, need to assume some presumably reasonable value

This runs counter to section 1.1 of the conventions:

The purpose of the CF conventions is to require conforming datasets to contain sufficient metadata that they are self-describing in the sense that each variable in the file has an associated description of what it represents, including physical units if appropriate, and that each value can be located in space (relative to earth-based coordinates) and time.

So there should either be a default value for missing parameters, or those parameters should be made mandatory.

More in general, I would argue for a complete overhaul of section 5.6 and the current use of grid_mappings. The current arrangement is predicated on the use of PROJ software for conversion of spatial data from one "projection" to another. That, however, is ancient practice. The ISO 191** series and OGC have been around for 20+ years and even PROJ now ingests WKT2 strings for coordinate transformations. The crs_wkt attribute already allows use of WKT strings but there are now some inconsistencies and complications that could be avoided by redesigning the section around the OGC framework.

[larsbarring]

Karl @taylor13 : Here is a real-world example:

MESAN:  [LambertConformal: radius = 6371229.0]     nx, ny = 1069, 949   dx, dy = 2500.0 m, 2500.0 m
EXTENT (min_lat,  max_lat,  min_lon,  max_lon)  :    49.7520   75.2388  -18.1719   54.2867
DIFFER (min_dlat, max_dlat, min_dlon, max_dlon) :    -0.0368    0.0219   -0.1945    0.1776

Minimum difference location (lat, lon, dx)      :    71.5785   54.2867   -6829.3 m
Absmin. difference location (lat, lon, dx)      :    51.3846   15.0159      -2.9 m
Maximum difference location (lat, lon, dx)      :    72.7658  -18.1719    5848.3 m
Mean difference location (lat, lon, dx)         :    62.6204   17.5148    -456.0 m

I.e. the maximum error exceeds ±2½ gridcells for this particular example, and even on average there is a mismatch.

This is one of the domains we are using. The limited area model uses a Lambert Conformal Conic map projection (x, y grid). The example show the difference between calculating latitude/longitude using the correct spherical radius used in the model (which requires this information to be available to the user!), and just simply assuming that it is a WGS84 ellipsoid. Because the WGS84 is very common, and prevalent in many user communities, it is not far-fetched to think that a user will make this assumption.