> 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
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:
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
> 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
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?
> 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
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
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.
--
> @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
@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
@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,
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
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:
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:
> 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
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
@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
> @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
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
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
> 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:
@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,
> 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:
@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
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
> 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
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
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
_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
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
>
> 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
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
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
@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:
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
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
> 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
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
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
39 matches
Mail list logo