It works with udunits:
https://urldefense.us/v3/__https://github.com/pyproj4/pyproj/issues/536*issuecomment-643013825__;Iw!!G2kpM7uM-TzIFchu!hEdA8YzmiXb6TckSFZMgaSdPP5nKJI5MX6_HTlhqW3-UfXlV4RBGVY7cX-z_kK3Xw-9ho1EjDig$
```python
>>> from cf_units import Unit
>>> u = Unit("0.5 m")
>>>
Closed #322.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for your response @sethmcg :+1:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for assisting getting this proposal accepted @JonathanGregory
--
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-667998805
This list forwards
@snowman2 pushed 1 commit.
459e514b35f3e9e81d278d016a16d106e622623a Update crs_wkt conflict section
according to discussion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Sounds good, just updated the PR
(https://github.com/cf-convention/cf-conventions/pull/282/commits/9ad24ca7768416f71c8056fe14e294d8a7564a76).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@snowman2 pushed 1 commit.
9ad24ca7768416f71c8056fe14e294d8a7564a76 Update crs_wkt conflict section
according to discussion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Sounds like a reasonable change to me.
Minor tweaks:
> compound crs_wkt attribute
I am thinking the `"compound"` word could be removed.
> the ellipsoid is defined by
I am thinking the `"is"` should be removed.
--
You are receiving this because you are subscribed to this thread.
Reply to
Minor tweak:
For example, if the semi-major axis length of the ellipsoid ~~is~~ defined by
the grid mapping attribute semi_major_axis **disagrees with** the crs_wkt
attribute (via the WKT SPHEROID[…] element), the value of this attribute
cannot be interpreted accurately.
--
You are
The three weeks have gone by without complaint, so I am moving forward with
this change.
# Release checklist
- [x] Closes #222 (See this issue for discussion of these changes)
- [x] Authors updated in `cf-conventions.adoc`?
- [ ] Next version in `cf-conventions.adoc` up to date? Versioning
Side note that pyproj may be useful when converting to CF:
https://pyproj4.github.io/pyproj/latest/build_crs_cf.html
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
That would require all applications to be able to support the WKT format.
Currently that is not possible due to software limitations (see comments in
this thread).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> should trigger an error (warning?) in a compliance checker?
I would say an error.
> Is the file compliant if the two are not the same?
I would say no based on this part: "in those situations where the two values of
a given property are different, the CRS information cannot be interpreted
The final wording from the breakout meeting:
There will be occasions when a given CRS property value is duplicated in both a
single-property grid mapping attribute and the crs_wkt attribute. In such cases
the onus is on data producers to ensure that the property values are
consistent. *If both
Follow on from: #248
Example: `units: 0.245 m`
--
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/277
This list forwards relevant notifications from Github. It is
> 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:
> 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
> 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
@JimBiardCics, thanks for your response, that is very helpful. We will plan on
leaving the value that was in the CRS WKT in the `*_name`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I am planning to go with the first one where the ones that are `unknown` will
be denoted as `unknown` for now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
In the notes of Appendix F it states:
```
Notes:
1.The various *_name attributes are optional but recommended when known as
they allow for a better description and interoperability with WKT definitions.
2.reference_ellipsoid_name, prime_meridian_name, horizontal_datum_name and
I think that is all I have to offer for clarifying information on this issue. I
will close it now since it seems that :-1: is the consensus here on the
proposal.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #248.
--
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/248#event-3088905534
This list forwards relevant notifications from Github. It is distinct from
@semmerson, you can go to http://www.epsg-registry.org/ and filter by the unit
of measure type. For example:
--
You are receiving this because you are subscribed to this thread.
Adding excerpt from: http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#35
```
Axis direction indicates the positive increment along an axis. The handedness
of a 2- or 3-dimensional coordinate system may be derived from the directions.
Requirement: the following constraints shall apply:
I have a list of units I would like to ensure are supported at a minimum here
to ensure a safe conversion from WKT to the CF convention (note: only the ones
with the type `length`). See:
> 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
# Title
Add unit_conversion_factor for units in coordinate axis to convert to meters
# Moderator
Any takers?
# Moderator Status Review [last updated: YY/MM/DD]
???
# Requirement Summary
Currently, in the WKT form, you can specify the conversion factor to meters
along with the name of the units
# Title
Add direction attribute for coordinate axis
# Moderator
(Any takers?)
# Moderator Status Review [last updated: YY/MM/DD]
???
# Requirement Summary
Add a direction for the coordinate system axis attributes to specify which
direction the coordinate goes in. This is useful when building a
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:
Forward from: https://github.com/OSGeo/PROJ/issues/1930
Currently the
[geostationary_projection](http://cfconventions.org/cf-conventions/cf-conventions#_geostationary_projection)
has the latitude_of_projection_origin defined without any defaults provided.
Based on the issue above in PROJ, the
@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"
> 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:
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
@JonathanGregory whenever you see this :smile:, I would recommend checking the
right hand side of this issue at the top to see if your subscribed to
notifications:
--
You are
> 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
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
>
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
> 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
@rsignell-usgs, that would definitely be nice. However, it will also require a
lot of work, so I imagine some kind of funding would be needed.
https://github.com/OSGeo/PROJ/issues/1193
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Thanks all for the comments! My desire here is to unite the geospatial (OSGeo)
and CF-conventions here to simplifying things when transitioning between the
communities.
Much of the inspiration for this thought came when attempting to match PROJ
parameters to the CF conventions as documented
Here is the WKT2 form of the `British National Grid` from:
https://cf-pcmdi.llnl.gov/trac/ticket/80
```python
>>> from pyproj import CRS
>>> cc = CRS("OSGB 1936 / British National Grid")
>>> cc
Name: OSGB 1936 / British National Grid
Axis Info [cartesian]:
- E[east]: Easting (metre)
- N[north]:
I am a GDAL/PROJ user, so from my biased perspective life would be much easier
from the WKT form :). Additionally, since WKT is already a standard from the
OGC geospatial community, most geospatial software should be able to support it.
> The WKT model of metadata is different from the CF one.
**Title:** Make CRS WKT dominant over grid mapping attributes
**Moderator:** ???
**Moderator Status Review [last updated: YY/MM/DD]:** ???
**Requirement Summary:** I propose instead that if the CRS WKT is present and
can be read in by the software program, that should be the official CRS of the
46 matches
Mail list logo
