Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
> But, if the user wants to check the values for consistency, then when they > conflict, the user should assume the CF value is correct. This gives the data > writer a little extra incentive to try to get things right when converting > the WKT metadata to CF. I think that if the values are not consistent, it does not make sense to default to CF or WKT as either one or both could be incorrect depending on your starting format of the CRS and how the conversion was done. In the proposal, it adds this clarification: > *If conflicts exist between the representations, you should inform the > provider so they can be addressed.* Reasoning for this wording mentioned in the proposal: > The CRS could originate from several different formats such as WKT, PROJ, or > SRS Authority Code. If there are errors in the conversion process to the CF > or WKT representation, only the provider would have the original CRS > representation. As such, if there are conflicts, the provider would be the > best source to go to in order to resolve the conflicts. -- 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-642734208 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)
Sounds like we should target the discussion towards the wording of the clarification to ensure all parties are on-board. -- 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-642706043 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)
Yes, to me [that](https://github.com/JonathanGregory) seems like a good solution. If a user wants to assume that when there are conflicts, the WKT values take precedence, then that's o.k. But, if the user wants to check the values for consistency, then when they conflict, the user should assume the CF value is correct. This gives the data writer a little extra incentive to try to get things right when converting the WKT metadata to CF. -- 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-642702610 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)
> Is the problem that it can be understood to imply that the data-reader must > read both versions and compare them? Yes, there are several data readers that have understood it this way. So, clarification on this would be a welcome addition. -- 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-642700383 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)
If I've understood your concern correctly, I don't see the problem with the existing wording. It's intended to give guidance for what to do if a data-user notices an inconsistency. Is the problem that it can be understood to imply that the data-reader must read both versions and compare them? If so, maybe we could address that concern by keeping the present wording, but adding some more words to say that the data-user can assume they are consistent, and therefore needs to read only one of them. 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-642695084 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)
> The statement of precedence is intended to resolve problems if they are > detected. Hence I don't think we need to change the convention to achieve the > aim stated (Allow CRS WKT to represent the CRS without requiring comparison > with grid mapping Parameters), if I've understood it correctly. It's already > OK. @JonathanGregory - does this mean you approve of the proposed wording change? If everyone approves of the wording change, then we could re-purpose the meeting to another CRS WKT topic, such as some issues you have mentioned in your post. -- 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-642682547 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)
We're going to discuss this issue today. I've just written the following in the google doc about it, because I can't say all this in the discussion, and I would like to explain where I'm coming from when we talk. The current position is that the `grid_mapping` takes precedence over WKT if both are present. To know whether this the case, the data-user would have to interpret both and compare them, and take the `grid_mapping` as correct if the two are inconsistent. If I understand correctly, the idea of the proposal is to remove the requirement of precedence, so that the data-user can read the WKT alone and not consider the `grid_mapping`. In fact, I think the data-user can behave in just that way as things stand. The data-user is not obliged to check that the dataset is self-consistent. They are entitled to assume that it is, because the onus is on the data-producer to ensure this. I believe that's what we had in mind when we decided the current convention, which was a sort of compromise. The statement of precedence is intended to resolve problems if they are detected. Hence I don't think we need to change the convention to achieve the aim stated (Allow CRS WKT to represent the CRS without requiring comparison with grid mapping Parameters), if I've understood it correctly. It's already OK. The discussion in this issue has gone further than that, however. A lot of it is about whether the `grid_mapping` should be able to represent the information in the WKT. I think this is a much more difficult question. As I've commented in the issue, I have serious concerns about this. I realise that other people have good reasons for suggesting it, and I hope we can find a consensus, as usual - honestly, I do! I have two kinds of concern, which are related. * If `grid_mapping` isn't required to represent everything, data-writers may chose to omit it. Some people would like that, because it would permit them to write WKT in the CF-netCDF file and allow it to be read and used as a “black box” required by certain software. I can see the practical advantage in that, but I think that's contrary to the general intention of CF, which has made it successful and popular. CF metadata is intended to be self-explanatory and intelligible to humans, designed to be read and written with minimal possibilities for mistakes. WKT looks to me more like code, it's not so self-explanatory because it doesn't label all its parts, the order in which things appear determines what they mean. It's not like CF-like. * I suspect that WKT may be inconsistent with the CF data model in some ways. I can't be sure unless we understand it thoroughly and how it relates to CF metadata. For instance, @snowman2 noted in the issue that, “The coordinate system and area of use currently don't have an equivalent in the CF conventions.” I don't know what they are exactly, but I think that coordinate system is an idea which is inconsistent with the CF data model, as an explicitly recognised part of the metadata. I recall also (but perhaps incorrectly) that there are defaults about directions and units, which may be inconsistent with CF. Because of these concerns, I continue to think that we should require data-procedures to describe everything they want to in `grid_mapping`, unless we can write down explicitly the mappings between CF metadata and WKT. We don't have to be able to carry out the conversion in software, but we should write down how to do it. When that has been done, we would have much greater clarity. We could be confident in stating that certain part of WKT were equivalent to CF metadata. It's possible that there are vocabularies in WKT which could be adopted by CF, and thus not maintained by CF. That idea is often suggested (e.g. by Jim in this issue) and it makes sense provided the vocabulary is one which can exactly “slot” into CF metadata. That is, it must suit our data model. It seems to me that this approach of mapping is what is being followed with the discussions about standard names and ontologies. It is not being suggested that standard names should be replaced by vocabularies from elsewhere, for the same kind of reason that there isn't a one-to-one correspondence. However, the mappings can be established to help with interoperability. But having written down the mapping between CF metadata and WKT, we would be able to write software that can do the conversion completely (@snowman2 already has such software, and probably others do). That could be used in the cf-checker to check that the `grid_mapping` and WKT are consistent, which is the problem we started with in this issue. -- 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-642659548 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu,
Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
Hello, The timings and order of the breakout groups for the CF meeting next week has now been set (see http://cfconventions.org/Meetings/2020-Workshop.html), and the discussion of this issue will be on Thursday 11 June from 16:00-17:30 UTC, in parallel with three other topics. Thanks. -- 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-639326340 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)
> @taylor13 I haven't been following this, but what about tripolar grids, > which are often used in ocean models? > @zklaus 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). >From our specific experience : Most ocean models use the so-called ORCA grids. These are not "just" a tripolar coordinate grid but use irregular sampling in various places. Most importantly : ***a grid is not a projection*** So, a grid like ORCA has 2D latitude and longitude values for cell corners (and centres). So that might *appear* to be like a coordinate-like space described by the grid indices. But this is misleading, because a projection would be a smooth, reversible, total function : Instead ... 1. you cannot define a point on the globe for an "interpolated" point in index-space like "ix=100.5, iy=101.3". The relationship is entirely defined by the (2d) X and Y values, there is no smooth function from (ix, iy) to (lat, lon). 1. there is no reverse mapping : you can't ask "where in the grid" a given point on the globe is. Only which cells it may fall within... 1. in fact not all parts of the globe are covered at all. The bottom of the space can be distorted to give extra detail in the Southern ocean, and does not cover the South pole. Also, some model cells actually *overlap* along the top seam, referred to as a 'north fold'. Thus... 1. ... returning to the 'reversal' question, a given global location can be in several gridcells, or none. In practice ORCA grids are particularly extreme case, in that the standard grids are defined _entirely_ by the provided 2D arrays of latitudes + longitudes, and there is no provided equation defining those numbers, as far as I can determine. -- 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-590368653 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)
@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] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)
@JonathanGregory said > If you have use cases for actual datasets that you want to put in CF but the > required projections are not supported in grid_mapping, it would be useful to > propose adding them to CF. I personally have a number of cases where CF doesn't provide the projection used. I come back to the question of why we feel the need to re-invent the wheel. I believe we need to learn to coexist with other standards and conventions that are at least as stable and reliable as CF rather than replicate them. -- 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-589108765 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)
> @rschmunk and @lesserwhirls, could panoply and netcdf-java use the Java > [geotools](https://github.com/geotools/geotools) library to handle [CRS > WKT](https://docs.geotools.org/stable/userguide/library/referencing/crs.html)? > > Would that be straightforward or a major effort? It would introduce a somewhat interesting circular dependency (they are using netCDF-Java 4.6.11, we're on 5.2.0). I've been looking at `proj4j` to see what they have for parsing WKT, at which point we'd need to setup a mapping to CF parameters and create a netCDF-Java Projection object. We have some (what looks to be) contributed code that does the parsing, mapping, and projection object creation, but it's not very forgiving in its parsing and not super capable at this point. -- 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-588525494 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)
First two sentences are duplicated in the second two sentences? -- 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-586659223 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 am removing the part about the standalone WKT to be discussed in another issue. Proposed WKT string statement modifications (modifications in italics): >There will be occasions when a given CRS property value is duplicated in both >a single-property grid mapping attribute and the crs_wkt attribute. In such >cases the onus is on data producers to ensure that the property values are >consistent. There will be occasions when a given CRS property value is >duplicated in both a single-property grid mapping attribute and the crs_wkt >attribute. In such cases the onus is on data producers to ensure that the >property values are consistent. *If both a crs_wkt and grid mapping attributes >exist, it is assumed that they do not conflict. As such, information from >either one (or both) may be used to represent the CRS of the file, recognizing >that the grid mapping parameters should always be completed as fully as >possible.* ~~However, in those situations where two values of a given property >are different, then the value specified by the single-property attribute shall >take precedence. For example, if the semi-major axis length of the ellipsoid >is defined by the grid mapping attribute semi_major_axis and also by the >crs_wkt attribute (via the WKT SPHEROID[…] element) then the former, being >the more specific attribute, takes precedence. Naturally if the two values are >equal then no ambiguity arises.~~ -- 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-586056569 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)
> This would be a non-trivial piece of work but until it is done I don't think > we can really know what we are missing in the CF attributes what WKT can > describe and needs to be included in use cases of CF datasets. @JonathanGregory, this is currently supported in `pyproj` master: https://github.com/pyproj4/pyproj/blob/6390041fc2bfb569e90f615adb7ba75160d41aa8/pyproj/crs/_cf1x8.py You can see the tests that were run to check the conversion to/from the CF format of the projection [here](https://github.com/pyproj4/pyproj/blob/6390041fc2bfb569e90f615adb7ba75160d41aa8/test/crs/test_crs_cf.py). I didn't find any parameters that weren't able to be supported by WKT. However, there are many projections that WKT can describe that aren't supported by CF. There is an extensive list [here](https://proj.org/operations/projections/index.html) for projections supported by PROJ. Only a subset is supported by CF conventions. -- 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-586055272 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)
@rmendels said > I have no idea what for example Panoply does, the Coastwatch tools, Thredds, > Seadas, and some others I can think of, and we should be very careful we > don't needlessly break things. Panoply uses the netCDF-Java library to read datasets. When dealing with projected grids, it looks for the variable named by the `grid_mapping` attribute and the CF specified projection parameters of that variable. For the 13 projections that Panoply supports, in 4 cases it uses projection code that is part of NJ but in the other 9 it uses its projection code to transform the grid. The reason for those 9 is that I'd already implemented them for other purposes, and the NJ library doesn't do the best job of performing sanity tests on the projection attributes that it finds in the dataset. FWIW, I only started looking through this thread because an issue regarding WKT was opened at Unidata/netcdf-java#191 earlier today. -- 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-577009147 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 think that writing down the mapping is a necessary piece of evidence in > deciding about that and would therefore be a useful first step. Here are some examples of the WKT version for the CF grid_mappings for the conversions: https://pyproj4.github.io/pyproj/latest/_modules/pyproj/crs/coordinate_operation.html This may also be useful: https://pyproj4.github.io/pyproj/latest/build_crs.html -- 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-576998642 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 whenever you see this :smile:, I would recommend checking the right hand side of this issue at the top to see if your subscribed to notifications:  -- 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-575667642 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'm not contributing much to this because GitHub is inexplicably not sending me the contributions to this issue. It may have decided for itself that it's better for all if I'm kept in the dark! I feel that the best solution for this would be for CF to maintain a document which describes the mapping between CF metadata and WKT, and for conformance to this mapping to be checked by the CF-checker. In that way a user could be reasonably confident of getting the same result by reading either of them, and errors would be identified. I think we already have some documents somewhere that are relevant (prepared years ago by Etienne Tourigny). This would be a non-trivial piece of work but until it is done I don't think we can really know what we are missing in the CF attributes what WKT can describe and needs to be included in use cases of CF datasets. It could be that CF `grid_mapping` attributes could eventually be replaced by WKT, as Jim would prefer, but I suspect that there is overlap with other parts of the CF data model, which would make this hard. It's certainly worth considering, but I think that writing down the mapping is a necessary piece of evidence in deciding about that and would therefore be a useful first step. -- 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-575565767 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)
> Are there known efforts or interest to develop some WKT-to-grid_mapping > translation modules? I brought this up in the past: https://github.com/OSGeo/PROJ/issues/1193. However, I think it would require more interest in the community and/or funding to make it happen. I have a basic implementation based on the [PROJ strings mappings](https://github.com/cf-convention/cf-conventions/wiki/Mapping-from-CF-Grid-Mapping-Attributes-to-CRS-WKT-Elements) in `pyproj`: - https://pyproj4.github.io/pyproj/stable/api/crs.html#pyproj.crs.CRS.from_cf - https://pyproj4.github.io/pyproj/stable/api/crs.html#pyproj.crs.CRS.to_cf However, the mapping back and forth is imperfect and misses quite a bit. I have plans to update grid mappings based on WKT as that will allow a more complete mapping. PROJ string mappings code [here](https://github.com/pyproj4/pyproj/blob/67ff137f8d734fbaa4aac32363b85dd5e33dad5c/pyproj/cf1x8.py). -- 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-574207697 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)
Moving toward WKT would be facilitated by a few software modules that interpret WKT and translate to familiar CF grid_mapping parameters, when reasonably compatible. @snowman2 wrote: > with the GDAL Barn changes (https://gdalbarn.com/), reading in a WKT is much > more practical with PROJ as a dependency. It also provides support for WKT2. > Additionally, GDAL can easily support the WKT form of the projection which > enables all the dependent software to read in the projection. "enables all the dependent software to read" -- Which language API's are supported or planned for this? Are there known efforts or interest to develop some WKT-to-grid_mapping translation modules? -- 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-573995875 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)
There are two perspectives in this thread (and the original WKT discussions) about what it means for optional 'containers' like WKT to be acknowledged as 'valid' in CF. In one view, the acknowledgement puts some or all of the responsibility for validating the container's content on CF, the CF validation software, and the CF tool developers. In the other view, it can be treated as a black box, with the responsibility for correctly including WKT content, verifying WKT content, and using WKT content relegated to the actual WKT providers and users. I think the acceptance of WKT as an 'allowed' container in those original proposals implicitly adopted the second view. To my understanding no tests for WKT content validity have been added, and tools have not been required to change anything. The gist of the proposal seemed in line with that view, because WKTs would still be optional and the CF attributes would still be required to the maximum extent possible. Therefore, I think the best approach is to modify the proposal to make it fully consistent with the second view, because that lets CF dynamically and quickly adapt to advanced needs of an important community. > _If the CRS cannot be represented using the grid mapping parameters, using > only the crs_wkt attribute is considered valid._ > > Sorry, but to my untrained eyes this essentially means software that purports > to be CF compliant will have to be able to deal with WKT. It is very simple, > I have a transformation that can't be represented by present grid mapping > parameters, I use the crs_wkt attribute, based on the standard that says the > file is CF-compliant but a lot of software that has been the basis for > CF-compliance will not be able to properly read that file. I must be missing > something here because I don't see anyway around this. It will create > CF-complaint files that present software will not be able to properly read. > Which will mean either a lot of incompatible files or possibly a lot of work > for the authors of the present software that are the backbone of > CF-compliance. I agree that the quoted sentence is ambiguous and inconsistent with other text. I'd prefer it went away; or at least be expressed as "If the CRS cannot be fully represented using the grid mapping parameters, the additional crs_wkt attribute can be used to augment the representation (while noting that support for reading and using the crs_wkt attribute in CF software remains entirely optional)." Still, there are oodles of CF-compliant data files that present software can't "properly" read, because they have various optional augmentations in them not understood by all software. The fact this particular optional augmentation is mentioned explicitly does not mean everyone, or even anyone, has to support it. It also does not mean that any testing or conformance software *has to* support or test WKT, any more than allowing multiple conventions in the convention attribute means you have to support and test all of the conventions that might be referenced by that attribute. > We would have to revise (or consider revising) CF whenever the definition of > WKT was amended. I'm not sure why. The only thing the WKT content can affect is another CF tool that reads WKT. All the existing tools that ignore WKT should not be impacted, they'll ignore WKT no matter what its definition is. Now, the tools that use WKT in CF might have to decide how to deal with WKT versions, but they could do that without ever having to require changes to the CF specification. -- 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-573382592 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)
_If the CRS cannot be represented using the grid mapping parameters, using only the crs_wkt attribute is considered valid._ Sorry, but to my untrained eyes this essentially means software that purports to be CF compliant will have to be able to deal with WKT. It is very simple, I have a transformation that can't be represented by present grid mapping parameters, I use the crs_wkt attribute, based on the standard that says the file is CF-compliant but a lot of software that has been the basis for CF-compliance will not be able to properly read that file. I must be missing something here because I don't see anyway around this. It will create CF-complaint files that present software will not be able to properly read. Which will mean either a lot of incompatible files or possibly a lot of work for the authors of the present software that are the backbone of CF-compliance. I am also concerned that not enough feedback has been coming from the authors of these software. Most telling was the inability of the people who have driven this to name such software (so that they are not aware of the possible implications of these changes), and even more that this is being driven to benefit GDAL so that GDAL doesn't have to change (read the original posts). I want to reiterate that it is not that I don't think going in this direction in the long-run is a good idea (that is a separate issue), I just don't think the implications have been entirely thought through, in particularly the ramifications for software developers who may not have the time and resources to deal with the changes.Which is why I keep saying we should go slow on this , perhaps create a lot of sample files, create ones that use CRS that presently can't be properly represented, and see what kind of havoc it does or does not create. Only after testing over as many programs as possible, then see how this should be worded. -- 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-572780372 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)
Just to be clear, this proposal does not propose to remove or override the `grid_mapping` parameters. It's main goal is co-existence with the CRS WKT. Proposed WKT string statement modifications (modifications in italics): > The crs_wkt attribute is intended to act as a supplement to other > single-property CF grid mapping attributes (as described in Appendix F); it > is not intended to replace those attributes. If data producers omit the > single-property grid mapping attributes in favour of the compound crs_wkt > attribute, software which cannot interpret crs_wkt will be unable to use the > grid_mapping information. Therefore the CRS should be described as thoroughly > as possible with the single-property attributes as well as by crs_wkt. *If > the CRS cannot be represented using the grid mapping parameters, using only > the crs_wkt attribute is considered valid. * >There will be occasions when a given CRS property value is duplicated in both >a single-property grid mapping attribute and the crs_wkt attribute. In such >cases the onus is on data producers to ensure that the property values are >consistent. There will be occasions when a given CRS property value is >duplicated in both a single-property grid mapping attribute and the crs_wkt >attribute. In such cases the onus is on data producers to ensure that the >property values are consistent. *If both a crs_wkt and grid mapping attributes >exist, it is assumed that they do not conflict. As such, information from >either one (or both) may be used to represent the CRS of the file, recognizing >that the grid mapping parameters should always be completed as fully as >possible.* ~~However, in those situations where two values of a given property >are different, then the value specified by the single-property attribute shall >take precedence. For example, if the semi-major axis length of the ellipsoid >is defined by the grid mapping attribute semi_major_axis and also by the >crs_wkt attribute (via the WKT SPHEROID[…] element) then the former, being >the more specific attribute, takes precedence. Naturally if the two values are >equal then no ambiguity arises.~~ -- 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-572767885 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)
> Are there any applications that actively read in and use the CF grid mapping > parameters? Not sure if I'm answering the right question here, but [Iris](https://github.com/SciTools/iris) ***definitely does*** explicitly interpret CF grid-mapping terms : we have explicit code for translating various types of grid-mapping to an [Iris 'coordinate_system'](). Currently supporting types : ``` albers_conical_equal_area azimuthal_equidistant lambert_azimuthal_equal_area lambert_conformal_conic lambert_cylindrical_equal_area latitude_longitude mercator orthographic polar_stereographic rotated_latitude_longitude stereographic transverse_mercator vertical_perspective ``` Most of these can also be produced as output. For instance, we are currently working on making let Iris accept a geostationary grid with missing false_easting/false_northing parameters : https://github.com/SciTools/iris/pull/3628 We currently don't support the WKT text, but could presumably consider this in future. -- 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-572643254 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 would suggest maybe going a little slow on this one, because my guess is many people are not following this discussion, so they will not be able to respond. I have no idea what for example Panoply does, the Coastwatch tools, Thredds, Seadas, and some others I can think of, and we should be very careful we don't needlessly break things. That is why I objected to the original proposal where the WKT string would take precedence. That would almost require that WKT strings be supported in software. -- 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-572637349 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)
GDAL is one more than I was aware of. I'm not aware of any others. -- 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-572632771 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)
@snowman2 Are there any applications that actively read in and use the CF grid mapping parameters? -- 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-572623255 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)
One minor addition: *"If the CRS cannot be represented using the grid mapping parameters, using only the CRS WKT is allowed. However, some applications will not be able to read in the CRS WKT form."* -- 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-572588900 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)
Or to deal with the edge cases and be consistent with our expectations: _"If both a CRS WKT and grid mapping parameters exist, it is assumed that they do not conflict. As such, information from either one (or both) may be used to represent the CRS of the file, recognizing that the grid mapping parameters should always be completed as fully as possible."_ -- 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-572287499 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)
> Should we also add something that emphasizes the points about "graceful > co-habitation" ? Are you thinking something along the lines of: *"If both a CRS WKT and grid mapping parameters exist, it is assumed that they are equivalent. As such, either one may be used to represent the CRS of the file."* -- 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-572246226 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)
Great strategy @JimBiardCics. Having contributed an attempted implementation to map CF conventions to WKT -- I know how error prone and hard it can be. Moving toward support of WKT as a fully fledged option within CF is unambiguously a good thing in my mind. @marqh's suggested text changes make a ton of sense to me. Should we also add something that emphasizes the points about _"graceful co-habitation"_ ? -- 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-570593687 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)
A few comments on the discussion to this point. I think the discussion is moving in the overall right direction. If seems to me that there was confusion at first between implementations and uses on the one hand and design and conventions on the other. I think we need to seriously consider how big a job it would be to "re-invent the wheel" by trying to add to CF, even piecemeal, all the parameters needed to represent all coordinate reference systems (CRSs). The vast majority of us are not geodesists. We need to acknowledge that this is a significant discipline that we know little about, and allow the experts in that field to be the experts. Let's use the standards they have developed rather than build an inferior substitute. CF added the ability to specify a few projected coordinate systems. We clearly must continue to honor those for backward compatibility purposes, but let's not add any new ones. I think we should encourage the use of WKT CRS declarations going forward and focus on what might need to be added to CF to resolve ambiguities that might be present. If I understood correctly, @JonathanGregory thought there were possible issues. I didn't see any specifics given, but I'd rather try to clear those up than follow a "make our own" approach any longer. I've worked with a few data providers that attempted to add grid_mapping variables to their netCDF files. The majority of them botched it. They would have been much better off if they could have copied and pasted a WKT string rather than try to figure out how to read CRS definitions and map elements to CF grid_mapping attributes. -- 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-570276738 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.
