Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread Alan D. Snow
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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread taylor13
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread JonathanGregory
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?

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-11 Thread JonathanGregory
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-06-05 Thread David Hassell
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. --

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-24 Thread Patrick Peglar
> @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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread JonathanGregory
@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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread JimBiardCics
@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,

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread JonathanGregory
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread Klaus Zimmermann
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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread taylor13
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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-21 Thread JonathanGregory
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-20 Thread JimBiardCics
@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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-19 Thread Sean Arms
> @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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-15 Thread John Graybeal
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-13 Thread Alan D. Snow
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-02-13 Thread Alan D. Snow
> 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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-21 Thread R. Schmunk
@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,

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-21 Thread Alan D. Snow
> 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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-17 Thread Alan D. Snow
@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: ![image](https://user-images.githubusercontent.com/8699967/72623135-2e738400-390a-11ea-99ab-345ce13d5d4f.png) -- You are

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-17 Thread JonathanGregory
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-14 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-13 Thread Dave Allured
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-11 Thread John Graybeal
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread Roy Mendelssohn
_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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread Alan D. Snow
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 >

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread Patrick Peglar
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread Roy Mendelssohn
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread JimBiardCics
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread JimBiardCics
@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:

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-09 Thread Alan D. Snow
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-08 Thread John Graybeal
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-08 Thread Alan D. Snow
> 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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-03 Thread David Blodgett
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

Re: [CF-metadata] [cf-convention/cf-conventions] Allow CRS WKT to represent the CRS without requiring comparison with grid mapping parameters (#222)

2020-01-02 Thread JimBiardCics
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