Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
@JimBiardCics The `grid_mapping` attributes were introduced to allow software to do the transformation if it wanted to, for instance to transform other locations (apart from the coordinates and boundaries) or do other computations (such as working out local directions or cell areas). They are optional because generic software does not need to be able to do the transformation if the 2D lat and lon coordinates are required to be present. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589751663 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
@JonathanGregory Am I right in understanding that back in the day the whole grid_mapping scheme in CF was added to annotate the relationship between lat and lon variables (which were always required) and X and Y variables? If the purpose was annotation and that annotation was itself optional, there was no actual need for the grid_mapping attributes provide sufficient information to do the transformation. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589731823 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
Dear @snowman2 That's good about `proj` supporting those two projections. Thanks. I used `proj` as an example but I was really thinking more about the general point that Jim raised, about relying on external resources. We've often discussed this on the former CF email list. I understand from what you say that `proj` is software, rather than a conventions document, so that's a bit different. You're right of course that open-source software can be modified by anyone for their own use. However, if someone proposes a new `grid_mapping` in CF, they just want the document to be modified, and they would not be offering to modify `proj` software to support this new mapping. Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589720986 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
How are they represented in CF right now? As far as I know only by 2d coordinates (which doesn't codify the iso-coordinate lines). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589720466 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
I haven't been following this, but what about tripolar grids, which are often used in ocean models? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589717696 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
> Does proj4 include rotated pole and vertical perspective, for instance?
Just to have it noted that it is supported in PROJ (the conversion classes will
be released in pyproj 2.5.0 soon, but the PROJ string version works on all
versions):
```python
>>> from pyproj.crs.coordinate_operation import
>>> RotatedLatitudeLongitudeConversion, VerticalPerspectiveConversion
>>> RotatedLatitudeLongitudeConversion(o_lat_p=1, o_lon_p=2).to_proj4()
'+proj=ob_tran +o_proj=longlat +o_lat_p=1 +o_lon_p=2 +lon_0=0'
>>> VerticalPerspectiveConversion(viewpoint_height=5).to_proj4()
'+proj=nsper +lat_0=0 +lon_0=0 +h=5 +x_0=0 +y_0=0'
```
>From tests:
```python
crs = CRS.from_cf(
dict(
grid_mapping_name="rotated_latitude_longitude",
grid_north_pole_latitude=32.5,
grid_north_pole_longitude=170.0,
)
)
expected_cf = {
"semi_major_axis": 6378137.0,
"semi_minor_axis": crs.ellipsoid.semi_minor_metre,
"inverse_flattening": crs.ellipsoid.inverse_flattening,
"reference_ellipsoid_name": "WGS 84",
"longitude_of_prime_meridian": 0.0,
"prime_meridian_name": "Greenwich",
"horizontal_datum_name": "World Geodetic System 1984",
"grid_mapping_name": "rotated_latitude_longitude",
"grid_north_pole_latitude": 32.5,
"grid_north_pole_longitude": 170.0,
"north_pole_grid_longitude": 0.0,
}
cf_dict = crs.to_cf()
assert cf_dict.pop("crs_wkt").startswith("PROJCRS[")
assert cf_dict == expected_cf
```
```python
crs = ProjectedCRS(conversion=VerticalPerspectiveConversion(50, 0, 1, 0, 2,
3))
expected_cf = {
"semi_major_axis": 6378137.0,
"semi_minor_axis": crs.ellipsoid.semi_minor_metre,
"inverse_flattening": crs.ellipsoid.inverse_flattening,
"reference_ellipsoid_name": "WGS 84",
"longitude_of_prime_meridian": 0.0,
"prime_meridian_name": "Greenwich",
"horizontal_datum_name": "World Geodetic System 1984",
"grid_mapping_name": "vertical_perspective",
"perspective_point_height": 50.0,
"latitude_of_projection_origin": 0.0,
"longitude_of_projection_origin": 1.0,
"false_easting": 2.0,
"false_northing": 3.0,
}
cf_dict = crs.to_cf()
assert cf_dict.pop("crs_wkt").startswith("PROJCRS[")
assert cf_dict == expected_cf
```
> If it's not our own resource, we can't necessarily add to it
It is an open-source tool that accepts contributions. Are you not allowed to
contribute to other open-source projects where you work?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589670579
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
Dear @JimBiardCics I appreciate the point and I agree that we should not spend our time doing a less good job of something which is already available elsewhere. However I don't think that CF is fairly described as "reinventing the wheel" in this case. I can suggest a few reasons why we have our own set of `grid_mapping` definitions rather than relying on `proj4` for example. * An external resource might not include all the cases we need. Does `proj4` include rotated pole and vertical perspective, for instance? (If it does that is not noted in our App F). If it's not our own resource, we can't necessarily add to it, and if it's not comprehensive, users of CF might have to mix different conventions in their files, which would be less satisfactory. * An external resource might change in a way which didn't suit CF, meaning we'd have to do extra work in a hurry to replace it with something else, with the further penalty of backwards-incompatibility for CF. * An external resource might not present the information in a way which is easily usable in CF, because it's not organised in a similar fashion or doesn't match well to the CF data model. Therefore instead of "handing over" something to an external authority, I feel that in most cases it is better to import the external information to CF. This isn't an absolute rule, of course, but it seems fine for `grid_mapping` to me. However, your point is a good reason why we should make the choice of attributes as similar as we can to `proj4`. If we do that, it should be easy to import more of them, like new standard names on existing patterns, and it improves interoperability between conventions. If we find there is a use case which is *not* trivial to import, there's probably a good reason for that which will require some thought, like new standard names which propose new patterns. Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-589614662 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Add direction attribute for coordinate axis (#247)
Dear @JimBiardCics Yes, I agree that many projected coordinate systems look somewhat like east-north, but not all of them, for example stereographic. CF also allows rotated pole, which is not true east-north by construction, and and indeed any sort of X and Y grid with 2D lat and lon, such as the ocean tripolar grid, which is east-north for a lot of the world, but variably distorted north of a certain latitude as it approaches its two north poles. In such cases it would be misleading to label X and Y as east and north, I feel. Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/247#issuecomment-589607784 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
