: 14 March 2014 19:12
To: CF metadata
Subject: Re: [CF-metadata] Vertical datums (again)
Jonathan,
I thought this was already defined. In the second paragraph of section 5.6, it
says that if you aren’t specifying a projected coordinate system (or, I assume,
a Cartesian coordinate system
Dear Jim
Yes, I suppose you're right, on reflection. I was thinking of a situation in
which you were interested in the ellipsoid only for the sake of a vertical
datum, rather than as a horizontal datum (which is its usual purpose in
grid_mapping). However, I now understand from the discussion and
Jonathan,
Quite right. Even longitude and latitude depend on the choice of datum,
whether that be an ellipsoid or a geoid.
To add to the fun, you can have mixed mode coordinates, where the horizontal
coordinates use one datum, and the vertical uses another (an extreme example is
(02PM 11 Mar 14)
Date: Tue, 11 Mar 2014 14:29:25 +
From: Jonathan Gregory j.m.greg...@reading.ac.uk
To: cf-metadata@cgd.ucar.edu
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [CF-metadata] Vertical datums (again)
Dear David
I'm a bit confused as to the use of these grid_mapping
@cgd.ucar.edu
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [CF-metadata] Vertical datums (again)
Dear David
I'm a bit confused as to the use of these grid_mapping parameters with
vertical coordinates - do we need new grid_mapping_names? I'm
thinking, for example, of linking a geoid
Dear Jim
Given what you say, what would you suggest for the grid_mapping_name when the
grid_mapping supplies only the figure of the Earth and does not specify any
transformation of coordinate systems?
I agree that grid_mapping is itself an unsatisfactory name, which reflects
the purpose we had
Dear Rich
Thanks for keeping this going.
In CF, we have some of these parameters of the vertical coordinate
system specified with the units and positive attributes. And we
already have add_offset that could be used for the vertical shift.
So that just leaves the geoid-based Vertical Datum
Dear David
I'm a bit confused as to the use of these grid_mapping parameters with
vertical coordinates - do we need new grid_mapping_names? I'm
thinking, for example, of linking a geoid specification to a vertical
altitude coordinate.
That's a good point, thanks. I was thinking of the
Hi.
Regarding how ESRI represents vertical CRSs:
When ESRI specifies a particular vertical datum and doesn’t specify the
ellipsoid, it is because the specified vertical datum specifies the ellipsoid.
The fully realized definition still contains a specification of the ellipsoid
that the
Dear John and Jim
Thanks for your comments. John, I agree with your classification. I think the
concepts to which we give standard names are really quite simple. They are
distances above or below a reference surface (i.e. a surface which is a 2D
function of geographical position). The distance
Dear Helen
Thanks for your comments.
Whilst it is true that the specifics of the geoid used (model, degree and
order of expansion etc) are important, simply being able to correctly
identify 'sea surface height above reference ellipsoid' vs 'sea surface
height above geoid' gives us
John,
I like your idea of using distance to avoid automatic overloading of concepts!
The problem with defining altitude as being an orthometric distance above the
geoid is that neither satellite nor GPS vertical coordinates match this
definition. Similarly, height as “height above the
Although we've got plenty of food for thought already, here's an extra
helping:
How ESRI (arguably the largest purveyor of geospatial software, e.g. 10,000
users at their annual conference) handles vertical datums:
http://resources.arcgis.com/en/help/main/10.1/index.html#//003r001500
Dear all
Thank you for clarifications and further information.
We used altitude for height above geoid because that's what it most
commonly means, I think. However, it's unclear. To avoid confusion, we could
rename altitude as height_above_geoid, using aliases. There are 14 standard
names which
It looks like the OGC Met-Ocean Domain Working Group has also been
thinking about this:
http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206
This doc is two years old, so I'll ask Jeff DLB if he can summarize
for the list what they came up with.
-Rich
-R
On Mon,
Simple terms like height, depth, and altitude are great for onboarding --
though complicated usage ('geoid must always be defined in the grid_mapping'),
lessens the onboarding benefit. And if they are ambiguous, the long-term
usability is affected. (See: sea_surface_temperature.)
I want a
Subject: Re: [CF-metadata] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like temperatures
in different units) are not different except for their reference frame. I
agree
-0500
To: CF metadata cf-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
CC: Karl Taylor taylo...@llnl.gov
Subject: Re: [CF-metadata] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things
Dear Karl
I seem to recall that the normal to a geoid surface does not in
general point in the same direction as the normal to the ellipsoid
surface at the same place. If that is true, would that be added
justification for giving different standard names to heights
relative to those
Dear Balaji
I understand it's blurry, and I suppose all I'm
arguing for is some general vigilance against proliferation of
names.
I completely agree with that sentiment! The blurriness comes in places where
coordinates are discrete, from a permissible set, such as area_types. This was
done to
-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
CC: Karl Taylor taylo...@llnl.gov
Subject: Re: [CF-metadata] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like temperatures
Hi all,
I agree with Jim on this. The grid_mapping, rather than the standard
name, is the appropriate place for this information. Just as it is for
latitude and longitude (and X and Y). We don't have latitude-wgs84
or latitude-airy-1830.
Ethan
On 2/11/2014 11:51 AM, Jim Biard wrote:
Karl,
] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like temperatures
in different units) are not different except for their reference frame. I
agree that we don?t want to put
...@unidata.ucar.edu
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Vertical datums (again)
Hi all,
I agree with Jim on this. The grid_mapping, rather than the standard
name
...@unidata.ucar.edu -
Date: Wed, 12 Feb 2014 10:43:46 -0700
From: Ethan Davis eda...@unidata.ucar.edu
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Vertical datums (again)
Hi all,
I agree
-
From: Jim Biard jbi...@cicsnc.org
Date: Tue, 11 Feb 2014 13:51:56 -0500
To: CF metadata cf-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
CC: Karl Taylor taylo...@llnl.gov
Subject: Re: [CF-metadata] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard
Hi.
It seems to me that tacking on a description of the datum in the standard name
isn’t a good plan. It creates a linkage between standard names and grid
mappings / WKT blocks. The nature of the height of the sea surface is
not altered by the choice of datum. The values will be different,
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like temperatures in
different units) are not different except for their reference frame. I agree
that we don’t want to put the datum information in the units,
Dear Jim and Rich
Many thanks for your helpful comments. I see a prospect of my understanding
things a bit better than before!
Jim says that a vertical datum always has a reference ellipsoid. Sometimes a
vertical datum might *be* a reference ellipsoid. Sometimes it is a geoid, and
in that case,
Jonathan,
Thanks for the detailed explanation (and analogy) of why it's useful
to tack on the _above_geoid or _above_ellipsoid or
_above_tidal_datum to the standard-name.
So we do that and then specify the geoid, ellipsoid or tidal datum
elsewhere in the grid_mapping variable, right?
geoid:
Hi.
NAVD88 is a geoid adjusted to geodetic leveling measurements taken all over
North America and fixed to the “mean sea level” height at Rimouski, Quebec,
Canada. (http://en.wikipedia.org/wiki/North_American_Vertical_Datum_of_1988)
Jim
Visit us on
FacebookJim Biard
Research Scholar
instances are provided by EPSG
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Signell,
Richard [rsign...@usgs.gov]
Sent: 04 February 2014 11:47
To: CF metadata
Subject: [CF-metadata] Vertical datums (again)
CF folks,
On a telecon
mark
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Signell,
Richard [rsign...@usgs.gov]
Sent: 04 February 2014 11:47
To: CF metadata
Subject: [CF-metadata] Vertical datums (again)
CF folks,
On a telecon yesterday with a coastal
- Forwarded message from Jim Biard jbi...@cicsnc.org -
From: Jim Biard jbi...@cicsnc.org
Date: Fri, 7 Feb 2014 10:38:23 -0500
To: CF metadata cf-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
Subject: Re: [CF-metadata] Vertical datums (again)
Hi.
I think there is still value
@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
Subject: Re: [CF-metadata] Vertical datums (again)
Hi.
I think there is still value in adding an attribute to the grid_mapping set
where the name of the vertical datum can be supplied. The datums (data?)
have ?standard? names (not CF standard names
from Jim Biard jbi...@cicsnc.org -
From: Jim Biard jbi...@cicsnc.org
Date: Fri, 7 Feb 2014 10:38:23 -0500
To: CF metadata cf-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
Subject: Re: [CF-metadata] Vertical datums (again)
Hi.
I think there is still value in adding an attribute
Feb 2014 10:38:23 -0500
To: CF metadata cf-metadata@cgd.ucar.edu
X-Mailer: Apple Mail (2.1827)
Subject: Re: [CF-metadata] Vertical datums (again)
Hi.
I think there is still value in adding an attribute to the grid_mapping set
where the name of the vertical datum can be supplied
Dear Rich
Yes, I think your answer before is the answer now, but I'm just clear
on the details. Would you specify sea_surface_height above NAVD88
like this?
float zeta(y=1534, x=2122);
:standard_name = sea_surface_height_above_reference_datum;
:grid_mapping =
Dear Nan
DEPTH:reference=R;
where currently vetted values for R are mean_sea_level,
mean_lower_low_water,
wgs84_geoid and the default, sea_level.
DEPTH:coordinate_reference_frame=urn:ogc:crs:EPSG::5831; or
HEIGHT:coordinate_reference_frame=urn:ogc:crs:EPSG::5829;
5831 and 5829 can be
This question certainly pops up on a regular basis.
After a discussion on the MMI 'Ask' metadata discussion list, OceanSITES
decided to add 2 attributes to the Z axis variable, one is 'reference',
which
is intended for human readers, and the other is
'coordinate_reference_frame',
which
Jonathan,
Yes, I think your answer before is the answer now, but I'm just clear
on the details. Would you specify sea_surface_height above NAVD88
like this?
float zeta(y=1534, x=2122);
:standard_name = sea_surface_height_above_reference_datum;
:grid_mapping = Albers_Projection;
41 matches
Mail list logo
