Re: [CF-metadata] [cf-convention/cf-conventions] Axis Order for CRS-WKT grid mappings (#223)
Closed #223 via #224. -- 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#event-2993901868 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 volunteer to do the merge, and update the history appendix, unless anyone else was already planning to do so. If it hasn't happened by tomorrow afternoon (UTC), I'll go ahead. 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/223#issuecomment-579847722 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)
No objection from me, either. -- 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-579843909 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've got no objection. We just didn't want to hold up 1.8. -- 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-579837467 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)
Yes, I think we should merge this in a few days to get it into 1.8 if 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/223#issuecomment-579832451 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 @dblodgett-usgs Given the imminent release of CF 1.8 and the discussion and support for this change, do you feel it is reasonable and appropriate to consider https://github.com/cf-convention/cf-conventions/issues/223#issuecomment-573097178 (19 days ago) as the start of the 3 weeks to merge? I know that https://github.com/cf-convention/cf-conventions/issues/223#issuecomment-577230633 was only added 7 days ago, but this was simply a confirmation of the previous update. This functionality is potentially really useful and it would be of great value to have this within the 1.8 release. It seems to me worth raising whether this can be expedited in this case in order to deliver this into the release? 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-579805470 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)
It looks like we have sufficient agreement to start the clock on agreeing to merge #224. If there are no substantive modifications or objections, it can be merged in three weeks per the [contribution guidelines.](https://github.com/cf-convention/cf-conventions/blob/master/CONTRIBUTING.md) -- 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-577669154 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 @JimBiardCics I like the text in line 474 in the PR (https://github.com/cf-convention/cf-conventions/pull/224/files#diff-0eab4e85fe4c323f70ce4bce0229dbe6R474), and so I'm happy with the proposal. Thanks for adding that. (If there's any discussion still to be had on general grid mapping syntax, it can happen at another time and place.) -- 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-577230633 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)
@snowman2 I can relate to your desire and I like the idea of the attribute on the coordinate variable. I don't think this issue is the place for this proposal. If you'd like to open a new issue for this, I think that would be worthwhile. -- 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-577205543 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)
@JimBiardCics How about specifying the axis attributes in the coordinate variable attributes? For example: ``` double y(y); y:standard_name = "projection_y_coordinate"; y:axis_order = 1 y:axis_name = "Northing" y:axis_abbreviation = "Y" y:axis_direction = "north" y:axis_unit = "metre" double x(x); x:standard_name = "projection_x_coordinate"; x:axis_order = 0 x:axis_name = "Easting" x:axis_abbreviation = "X" x:axis_direction = "east" x:axis_unit = "metre" float Temperature(y, x); Temperature:units = "K"; Temperature:grid_mapping = "Lambert_Conformal: x y"; ``` Side note: I have found in my experience the explicit is better than implicit. See [Zen of Python](https://www.python.org/dev/peps/pep-0020/). -- 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-577191303 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)
@snowman2 I read the definitions at your link. It seems to me that this is out of scope. Could you please explain what is gained by specifying direction (by some as yet unknown means) with the coordinate name tuple? I would assume that the directionality is implicit in the particular coordinate system chosen. -- 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-577180336 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 would recommend adding the `direction` to the axis order as well. For example `NORTH_POLE_EASTING_SOUTH_NORTHING_SOUTH` or `SOUTH_POLE_EASTING_NORTH_NORTHING_NORTH`: See axis maps here: https://pyproj4.github.io/pyproj/latest/_modules/pyproj/crs/coordinate_system.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/223#issuecomment-576998067 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 I think that line 474 in the PR https://github.com/cf-convention/cf-conventions/pull/224/files#diff-0eab4e85fe4c323f70ce4bce0229dbe6R474 explicitly addressed this, placing the expectation on the data producer that if the CRS WKT is provided and the coordinates provided then these are expected to be consistent with eachother. It also notes that this is not a conformance requirement due to the consistency being contingent on the CRS WKT definition -- 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-573097178 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 You could use CamelCasing. In my own work, I tend to use the construction to indicate a placeholder. -- 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-572131304 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 wondered at the use case where a grid mapping would have a single coordinate variable associated with it, but then I thought of the example of zonal data that had latitudes but no longitudes. It's a somewhat odd case, but it represents a valid identification. -- 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-572130735 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)
@JimBiardCics my concern around this presentation is the use of space characters in labels that are parts of a space separated list. how to I separate the elements when reading? is there a different separator that I could use, instead of the underscore '_' ? perhaps a character that is not allowed by the netCDF attribute naming syntax now where's that allowed character list? -- 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-572130264 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)
The use of underscores like that can be problematic, for sure. Fixing that overall would be a long-term project. What about some markup like this? In the second format, it is a blank-separated list of words "**`grid mapping variable`**: **`associated variable`** [**`associated variable`** …] [**`grid mapping variable`**: …]", which identifies one or more grid mapping variables, and associates one or more coordinate or auxiliary coordinate variables with each grid mapping variable. -- 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-572128489 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 I think there is some level on which the checker needs to get > involved. It needs to check consistency in the **`grid_mapping`** attribute > string - verifying that the CRS (grid mapping) variables exist and the > variable names associated with each CRS variable exist and have matching > dimensionality. The checker could even verify that the variables associated > with a given CRS represent a proper set using standard names and/or units. > None of this would require parsing the WKT string. I agree with the principle here @JimBiardCics Myself, I'd put less onus on the checker, as long as the variables exist, I'd let this pass. I expect this to be the limit of the current conformance expectations. Checking for matching dimensionality, standard name, units and so on feels to me (at first glance) like adding complication to the checker that is difficult to encode to meet all cases. A balance between good protection and minimal false alerts may be difficult to strike in these cases, I fear. As always, 'What is proportionate?' is a useful detail aspect for us to reach consensus on within this ticket and I welcome this aspect of the discussion. cheers 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-572125674 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)
@JimBiardCics as in https://github.com/cf-convention/cf-conventions/pull/224/files#diff-0eab4e85fe4c323f70ce4bce0229dbe6L210-R212 it is a placeholder in a string definition that is to be replaced by a variable name within the conventions text. So, it's not an attribute, it's defining the syntax for this complicated string representation. I'm open to any discussion on how to put this text into the conventions document to try and be clear and explicit and avoid confusion where possible. these labels are not marked up as though they are CF attribute names in the text -- 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-572123728 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 I think there is some level on which the checker needs to get involved. It needs to check consistency in the **`grid_mapping`** attribute string - verifying that the CRS (grid mapping) variables exist and the variable names associated with each CRS variable exist and have matching dimensionality. The checker could even verify that the variables associated with a given CRS represent a proper set using standard names and/or units. None of this would require parsing 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-572123426 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 Is there an actual attribute named **`coordinates_variable`**? If not, I would avoid this usage. -- 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-572120791 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 that's okay, I'll try to explain things as I see them in different ways and see if I can help. Be careful of reused terminology, which doesn't always mean the same thing in different contexts. There is no 'mapping' of 2D variables representing coordinate values to one axis. I'll try name-spacing, to see if this helps. A cf_axis is not the same concept as a crs_wkt_axis. A crs_wkt_axis is a coordinate reference system concept and is all about how the basis vectors in the CRS are defined and how individual positions are represented as an ordered tuple of coordinate values. A cf_axis is a data structure concept which is all about how the data and locational metadata are laid down as a set of structured arrays with dimension references. Given: * two 2-d auxiliary coordinate variables, each of which span the same two cf_axes. Wanted: * pairs of values (tuples) from each of these auxiliary coordinate variables * within each pair, the order of values is defined by the crs_wkt_axis order So, we take the two 2-d variables and for each index location, make a tuple, ordered by the crs_wkt_axis order e.g. CDL ``` foo:grid_mapping = "crs:x y" x = [[1, 2, 3], [4, 5, 6]] y = [[11, 12, 13], [14, 15, 16]] ``` crs_wkt application ready output ``` coord_tuples = [[(1, 11), (2, 12), (3, 13)], [(4, 14), (5, 15), (6, 16)]] ``` does this help to demonstrate the different concepts at work here? 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-571998387 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 must not be understanding how CRS-WKT works, but if I stuck on the fact that 2-d auxiliary coordinate variable span two axes, thus making the mapping of those coordinates to one axis impossible. Does that make sense? -- 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-571986206 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 @davidhassell > I would still like it to be clear that all this only applies to coordinate > variables (as opposed to auxiliary coordinate variables). I disagree with this point. This capability applies to coordinate variables and auxiliary coordinate variables equally. That is a key part of the purpose of introducing this syntax in the first place and remains a key capability. The current published version, 1.7, explicitly states: > In the second format, it is a blank-separated list of words > "grid_mapping_variable: coordinate_variable [coordinate_variable …] > [grid_mapping_variable: …]", 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. stating that this applies equally to coordinate variables and auxiliary coordinate variables. I aim to keep this as published in the previous version. Indeed, I think that making this apply to coordinate variables only would result in certain CF1.7 datasets being deemed not conforming to the conventions for CF1.8, which I think is a result that is to be avoided. Please may I ask? What is the aim of limiting this capability to netCDF Coordinate Variable instances only? Is exploring such a limitation part of this ticket on stating Axis order for CRS WKT? (or is it an independent discussion topic?) 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-571973352 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)
Thanks for the PR, Mark. I would still like it to be clear that all this only applies to coordinate variables (as opposed to auxiliary coordinate variables). I think this could be done with a very simple change to the proposed text (~~old~~, **new**): > Where an extended "grid_mapping_variable: coordinates_variable > [coordinates_variable]" entity is defined, then the order of the > ~~coordinates_variable~~ **coordinate variable** references within the > definition provides an explicit order for these coordinate value variables, > used if they are to be combined into individual coordinate tuples. Would that be OK? Thnaks, 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-571957430 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)
The description has been updated with my summary. I think this issue is at a point where a pull request with suggested modifications would be helpful. -- 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-570966005 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.
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)
@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] 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)
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)
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)
@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 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)
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)
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)
@marqh It might be useful to provide an example that used a projected CRS WKT. -- 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-570287996 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 If I am understanding @marqh's proposal correctly, you should have only x and y for the coordinates associated with crs in the grid_mapping attribute in your example. The implication of the coordinate variables x and y in your example is that the coordinate system is a projected coordinate system. In that case, the axes in the WKT string would not be latitude and longitude. -- 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-570287758 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 @davidhassell I don't understand the last example you presented. please could you explain in words and/or examples what is meant by four different coordinates all 'grid mapping' to the same CRS? 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-570236765 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)
Re. the order in being in the CRS-WKT - that makes sense, thanks. My other comment on N-d variables was referring to the case when dimension coordinate and auxiliary coordinate variables are attached to the same grid_mapping, which I think is allowed: ``` dimensions: x = 18 ; y = 36 ; variables: double x(x) ; double y(y) ; double lat(y, x) ; double lon(y, x) ; float temp(lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs: lat lon x y" ; ``` -- 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-570229648 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 Mark, Many thanks for the explanation - just what I needed - I now wholly understand the reason for the proposal. In your CDL example, you also have the axis order encoded in the CRS-WKT string: ``` AXIS["latitude",north,ORDER[1]], AXIS["longitude",east,ORDER[2]], ``` Was that intentional? If it is there, then should the variable order in the grid_mapping be ignored? It might be worth also mentioning that if any N-d coordinates (N>1) are listed in the grid_mapping attribute, then they must be ignored when ascertaining the order. -- 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-570225142 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)
Dear Mark I think your proposal makes sense, if you're sure that the variables listed in the `grid_mapping` attribute (in the extended form) always correspond to the coordinate variables of the OGC CRS, do they? Maybe it's obvious that they must be - I'm not familiar with it. In your text, I think it would be good to say that the order of the variables in the `grid_mapping` attribute is significant only if `crs_wkt` is also specified, because it doesn't have a meaning for the CF metadata, in which order is not defined. 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/223#issuecomment-570213822 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 @davidhassell > Are you saying the CRS-WKT stored as an attribute of the grid_mapping > variable can contain the actual coordinate values in plain text, as well as > the projection definition? I think no, that is not what I am saying. The CRS definition does not contain any actual coordinate values. It is only the CRS definition. The CRS-WKT definition includes a definition of a Coordinate System, a system of coordinates: which is a component part of a Coordinate Reference System. (careful with the similar but distinct terminology) For example, https://secure-web.cisco.com/1u1qVqVl4U8bOVyeL3aTqt2NywDHotMA2uzimI-1NkFb7z7AaesfUVgLr3zOL9JnAffI_ZBC3lAO0m35KADvStsiqttXvI9OiO0mP8lBlJyvpLa_8mXj_6tTZ81Cu0vQyGAHGzNEbQO0NvRKRzrNUVeHrQlw04fYli_Kj-TI2LHyT3EsYWuLBRmJfYT5XutcyvA4MrpWp3vHQTx_z91TPfcIUOSpFHfe7fHPcorKh7mJrSu_YpjbM7bQBijlUVX6JjvyQjSQozXP3w9zhqooGYBN0iMpa0S8UtQvQcG9at1O6dnSpAmz1nR3ygKVG7uoKuKYxu5ewAY1n2wAUbXj24NCu4eCFGqsOYKTMa8UiccuCmAUmJE6VPPVyTSDYiHB00AgGc8TdfY_8jILtJ4Lt4w/https%3A%2F%2Fwww.epsg-registry.org%2Fexport.htm%3Fwkt%3Durn%3Aogc%3Adef%3Acrs%3AEPSG%3A%3A4326 contains the definition ``` CS[ellipsoidal,2], AXIS["latitude",north,ORDER[1]], AXIS["longitude",east,ORDER[2]], ``` This includes a dimensionality, in this case 2, and an ordered list of AXIS definitions, which shall be the size of the dimensionality. The key information here is that a single position is defined with respect to the CRS by providing that position in the form of a coordinate tuple, which is ordered. Thus, a coordinate value defined with respect to this CRS shall be of the form * ( , ) It is fine to provide a list, or array, of coordinate tuples, as long as individual tuple order is consistent, e.g.: * [ ( , ) , ( , ) ] It is not correct to provide (Axis inversion is banned in coordinate value to CRS referencing) * ~~( , )~~ It is not correct to provide * ~~[ , ...]~~ This is only of import when providing coordinate values and CRS-WKT to an application which is aware of these technologies and trying to process the spatial information. Given that a significant majority of CF data will have separate variables storing an x and a y coordinate, (lets call them lat and lon) then the only additional information I want to provide here is explicit information on whether a coordinate values for a single location shall be presented to CRS-WKT aware software should be presented as (lat, lon) or (lon,lat) It would be really useful to be explicit about providing this single piece of relation information for implementers and users of CRS-WKT. in this case, I would like to see a netCDF file encoded (pseudo CDL) ``` dimensions: lat = 18 ; lon = 36 ; variables: double lat(lat) ; double lon(lon) ; float temp(lat, lon) ; temp:long_name = "temperature" ; temp:units = "K" ; temp:grid_mapping = "crs:lat lon" ; int crs ; crs:grid_mapping_name = "latitude_longitude" crs:semi_major_axis = 6378137 ; crs:inverse_flattening = 298.257223563 ; crs:crs_wkt = "GEODCRS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]], CS[ellipsoidal,2], AXIS["latitude",north,ORDER[1]], AXIS["longitude",east,ORDER[2]], ANGLEUNIT["degree",0.01745329252], ID["EPSG",4326]]" ``` the line: ``` temp:grid_mapping = "crs:lat lon" ; ``` is the crucial one, providing an explicit definition that i am relating (lat, lon) coordinate value pairs, from the `lat` and `lon` variables, not ~~(lon,lat)~~ coordinate value pairs. This syntax is already available in CF, but it does not yet carry the meaning which I am suggesting that we add. 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-570189260 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.
