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
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
> @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
@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
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 -
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
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
@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:
@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
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;
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
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
12 matches
Mail list logo
