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
@neumannd yes - whereas I think it would be best if the sample data sets these
values to 0 by omitting them. This is to make sure that the merge is in line
with the [rules for changing the
Conventions](http://cfconventions.org/rules.html):
> Once the summary has been made, if the test netCDF
The external files are fine, but there's one problem with using the
'references' attribute; that term is defined as a global attribute in CF. Most
netCDF software does not handle a situation where a term is used as a global
and a variable attribute the way you might expect - that's apparently
@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:
@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
@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
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`** …]
> @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
@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
@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
@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:
@ngalbraith for the upcoming version of our 'IOOS Metadata Profile' that
incorporates these new standard names into a quality flagging scheme for
QARTOD, we decided to leverage the `references` attribute to suggest data
providers link to external web pages or web-accessible files (e.g. JSON)
erget approved this pull request.
Perfect, 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/pull/225#pullrequestreview-339897904
This list forwards relevant
> I'm starting the 3 weeks timer, after which I will merge provided that a
> sample file has been provided (@neumannd can you please do this?) and [...].
@erget: Do you mean a sample netCDF file that is uses this new feature (some
projection information with `false_easting = 0` and
@erget: Thanks for the info. I updated the text accordingly.
--
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/pull/225#issuecomment-572075650
This list forwards relevant
I think that this is essentially correct. The naming issues are also not
insurmountable. Finite element has its own conventions, but they are just
naming conventions. If UGRID has finite difference naming then this will merely
be a bit confusing for finite element users.
In the specific cases
Hello,
I have been looking at the Finite Element based CF proposal for Unstructured
Grid data model
(https://publicwiki.deltares.nl/display/NETCDF/Finite+Element+based+CF+proposal+for+Unstructured+Grid+data+model)
which was written up some time ago by Bert. This proposes an encoding for the
PR #225 looks OK to me. I've requested a formatting change that won't affect
content in any way.
Current status looks like consensus to me and >2 committee members have
expressed support. I'm starting the 3 weeks timer, after which I will merge
provided that a sample file has been provided
erget commented on this pull request.
Content looks fine, I've requested 2 formatting changes to be able to trace
changes better moving forward.
> @@ -433,7 +433,9 @@ to a reference direction.
| Applied to all abscissa values in the rectangular
coordinates for a map projection in order
@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 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
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
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
24 matches
Mail list logo
