Re: [CF-metadata] [cf-convention/cf-conventions] Axis Order for CRS-WKT grid mappings (#223)
There seems broad support for this change and so far limited concern. Shall I proceed with making a targeted Pull Request with the changes as discussed here, to enable us to iterate on the fine detail with review comments? Please may I have a volunteer to adopt this ticket as moderator? thank you mark -- 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/223#issuecomment-570513597 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] Axis Order for CRS-WKT grid mappings (#223)
Hello @JimBiardCics > It might be useful to provide an example that used a projected CRS WKT. There is a useful example in the conventions at example 5.12 in section 5.6.1 http://cfconventions.org/cf-conventions/cf-conventions#use-of-the-crs-well-known-text-format this would be updated, with the line: * ~~temp:grid_mapping = "crs" ;~~ replaced with the line * temp:grid_mapping = "crs:x y" ; If a data producer chose to include 2D latitude and longitude coordinates, and defined a CRS definition for these, let's call that var: `crs_wgs84` as in example 5.11, then the `grid_mapping` attribute would be updated to read * temp:grid_mapping = "crs:x y crs_wgs84:lat lon" ; I would expect to update examples 5.11 and 5.12 as part of this change Jim: Do you think it worthwhile including this example: 1. in the conventions? 1. as an alteration to 5.12? 1. as an abridged example, combining 5.11 and 5.12 in short form as a new example? many thanks mark -- 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/223#issuecomment-570513219 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] Axis Order for CRS-WKT grid mappings (#223)
I think that it's valid CF to include the auxiliary coordinates in the extended grid_mapping format: `Temperature:grid_mapping = "Lambert_Conformal: lat lon x y";`, as is done in the example below. ``` dimensions: y = 228; x = 306; variables: int Lambert_Conformal; Lambert_Conformal:grid_mapping_name = "lambert_conformal_conic"; Lambert_Conformal:standard_parallel = 25.0; Lambert_Conformal:longitude_of_central_meridian = 265.0; Lambert_Conformal:latitude_of_projection_origin = 25.0; double y(y); y:standard_name = "projection_y_coordinate"; double x(x); x:standard_name = "projection_x_coordinate"; double lat(y, x); lat:standard_name = "latitude"; double lon(y, x); lon:standard_name = "longitude"; float Temperature(y, x); Temperature:units = "K"; Temperature:coordinates = "lat lon"; Temperature:grid_mapping = "Lambert_Conformal: lat lon x y"; ``` I see now that my language was wrong when I talked about "ascertaining" the order. I meant that any N-d auxiliary coordinate variables given by the grid_mapping attribute are to be ignored when mapping the named variables to the CRS-WKT axes. However, I have checked back with your text, and see that you have written that it is the order of the _coordinate variables_ that is used, so my point about ignoring auxiliary coordinates is already catered for, so I'm happy. Sorry for the diversion! -- 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/223#issuecomment-570516898 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] Axis Order for CRS-WKT grid mappings (#223)
If you dig into the WKT string to find the axes, shouldn't there be a pretty clean mapping between the WKT axis names and the coordinate variable standard names? What is the particular reason why people feel that this is insufficient? -- 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/223#issuecomment-570577411 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] Axis Order for CRS-WKT grid mappings (#223)
@marqh That makes much better sense. I think we need to make sure that we provide clear examples, as this can get confusing quickly. -- 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/223#issuecomment-570575178 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] Axis Order for CRS-WKT grid mappings (#223)
@davidhassell It seems to me that the issue is figuring out which variable maps to which part. The rotated pole projection is a particularly thorny example. If the goal is to allow for automated ordering, I think we'd have to lay out some pretty specific syntax rules if we aren't depending on looking inside the WKT string. -- 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/223#issuecomment-570578963 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] Axis Order for CRS-WKT grid mappings (#223)
Hi @marqh, I wasn't suggesting that you can't have both dimension coordinate and auxiliary coordinate variables explicitly associated with a grid mapping - quite the opposite: given that you can I was at first concerned on how the presence of N-d variables affected the mapping to CRS-WKT axes - a concern I have already withdrawn. You're right, though, that my example was a bit lacking; but I still think that it is possible to have 2-d latitude, longitude and 1-d (projection) coordinates explicitly linked to the same CRS. Consider: ``` char rotated_pole rotated_pole:grid_mapping_name = "rotated_latitude_longitude" ; rotated_pole:grid_north_pole_latitude = 32.5 ; rotated_pole:grid_north_pole_longitude = 170. ; rotated_pole:earth_radius = 620. ; ``` Then it would make sense to explicitly link (they're already implicitly linked) all four coordinates to "rotated_pole" grid mapping - the `lat` and `lon` variables can make use of the spherical earth definition. Thanks, David -- 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/223#issuecomment-570577780 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] Axis Order for CRS-WKT grid mappings (#223)
I want to make sure of the reason for this proposed change. This change is being made to provide a way for software to automatically order the coordinate variables correctly when handing a WKT string and coordinate values to a function that would do coordinate transformation. We are mapping variables by name to CRS axes. Is that right? As a comment on this, we are probably going to find that people will get this wrong a lot. -- 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/223#issuecomment-570576898 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] Axis Order for CRS-WKT grid mappings (#223)
@davidhassell there is text in 5.6 that states > which identifies one or more grid mapping variables, and with each grid > mapping associates one or more coordinate_variables, i.e. coordinate > variables or auxiliary coordinate variables. so this is already intended for use with coordinate variables and auxiliary coordinate variables. I think that the example you presented is mis-encoded. I think that the projected coordinates are defined with respect to a different CRS instance from the geodetic coordinates. I think the example you present is better encoded as: ``` dimensions: y = 228; x = 306; variables: int Lambert_Conformal; Lambert_Conformal:grid_mapping_name = "lambert_conformal_conic"; ... Lambert_Conformal:crs_wkt = ... int geodetic; geodetic.grid_mapping_name = "latitude_longitude" ; ... geodetic.crs_wkt = ... double y(y); y:standard_name = "projection_y_coordinate"; double x(x); x:standard_name = "projection_x_coordinate"; double lat(y, x); lat:standard_name = "latitude"; double lon(y, x); lon:standard_name = "longitude"; float Temperature(y, x); Temperature:units = "K"; Temperature:coordinates = "lat lon"; Temperature:grid_mapping = "Lambert_Conformal: x y geodetic: lat lon"; ``` Does this make sense as a preferred encoding for the example you have presented? thank you mark -- 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/223#issuecomment-570543211 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] Axis Order for CRS-WKT grid mappings (#223)
> @marqh -- I've not had time to really take this in yet, but I'll gladly act > as moderator. I'll edit the proposal by adding a summary of discussion above > as I have time -- should be later today or this weekend. thank you mark -- 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/223#issuecomment-570593236 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] Axis Order for CRS-WKT grid mappings (#223)
Hi @JimBiardCics > If you dig into the WKT string to find the axes, shouldn't there be a pretty > clean mapping between the WKT axis names and the coordinate variable standard > names? What is the particular reason why people feel that this is > insufficient? This is indeed the concern I am raising. That the pretty clean mapping does not exist in many cases. Understanding relations may require partial string matching, interpretation or inference, all difficult to encode into software. The vocabularies within CF and within CRS-WKT are similar but there are plenty of differences to manage, and I don't think it is worth the effort They also imply the parsing of the CRS-WKT to comprehend this aspect. For example, this example of a CS for a Projected CRS is stated in the WKT-CRS standard: ``` CS[Cartesian,2], AXIS["(E)",east], AXIS["(N)",north], LENGTHUNIT[“metre”,1.0] ``` The text in the quotes is optional and not controlled. In CF terms in this case, the coordinate variable definitions may use the standard_name `projection_x_coordinate` and `projection_y_coordinate` but these are optional. Given two sets of optional strings, one of which is not a controlled vocabulary, and implementing reference ordering based on this seems to me to be too much of a minefield. Hence I have come to the view that explicit is better here. This is where the broader conversations within #222 re-triggered this topic and motivated this activity. I prefer to use the already in place syntax and provide clear interpretation to enable a data producer to provide this information explicitly. This should enable my software to be set up to simply pass coordinate values and CRS-WKT strings to a suitable application, written by specialists, which can provide me with all of the rich functionality that referencing by coordinates delivers. There's minimal complication for me at this point. I hope that this will allow us to provide a set of good practice templates to provide to data producers to enable them to adopt. > I want to make sure of the reason for this proposed change. This change is > being made to provide a way for software to automatically order the > coordinate variables correctly when handing a WKT string and coordinate > values to a function that would do coordinate transformation. We are mapping > variables by name to CRS axes. Is that right? yes, this is my interpretation as well. I hope this is helpful clarification mark -- 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/223#issuecomment-570593171 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.
