Paul,
The standard name grammar does not have any place for addition of words
that aren't in the defined set (standard names plus specifiers plus
modifiers). I have recently had to deal with a similar issue. Others
may correct me, but I think the little CDL example below shows what you
could do. Keep in mind, this example is not complete. I am leaving out
a whole host of attributes, such as projection, etc.
dimensions:
CorrEasting = UNLIMITED; // (0 currently)
variables:
float RawEasting(CorrEasting=0);
:units = "meters";
:long_name = "Raw easting";
:standard_name = "projection_x_coordinate";
float CorrEasting(CorrEasting=0);
:units = "meters";
:long_name = "Corrected easting";
:standard_name = "projection_x_coordinate";
:axis = "X";
float Measurement(CorrEasting=0);
:coordinates = "RawEasting";
Note that I labeled the corrected easting with the same name as the
dimension. This makes the variable into a "coordinate variable", which
has special status in CF. The RawEasting variable is considered an
auxiliary coordinate variable, and is identified as such in the
coordinates attribute on the measurement variable. This is, of course,
assuming that the corrected easting is the one that you would prefer
that people use for most purposes.
There is, in addition, a requirement to have additional auxiliary
variables that contain the longitude and latitude of each point when the
primary coordinate variables are projection coordinates. CF is
currently strongly biased towards having geographic coordinate
variables. There is an ongoing discussion about how to support
projection coordinate systems.
Feel free to contact me directly if I can help further offline.
Grace and peace,
Jim
On 9/8/2011 9:29 AM, Kennedy, Paul wrote:
Hi Jim,
Many thanks for getting back to me. I would have thought I would need
to differentiate using different variable names
We will certainly set the correct standardname attribute.
Our current systems maintain both unprocessed and final data in the
same file so we can rapidly compare and contrast. This has worked well
in the past, so I prefer to keep hold of it for a while.
My thoughts were to use the standard names where possible for our
'final' data such that other systems can recognise the variables we
would expect them to consume.
With this in mind, for our raw easting, would it more appropriate to
use the term
"projection_x_coordinate_raw".
Or
"raw_projection_x_coordinate".
?
I could not figure if the descriptor should come first or last
BTW. I really like the metadata fields.
Geeting NetCDF into an OGC standard will see it proliferate.
Well done
----- Original Message -----
From: [email protected] <[email protected]>
To: [email protected] <[email protected]>
Sent: Thu Sep 08 20:39:27 2011
Subject: Re: [CF-metadata] Mapping from internal data conventions to
CF conventions
Paul,
As far as the standard_name attribute for the variable CorrEasting, I
think it is perfectly OK to use the same standard name as used for the
variable Easting. You would differentiate them in the names of the
variables, and in the free-text long_name attributes for each. The
standard_name attribute is used to indicate the "class" of measurement
stored in the variable, without much regard for the method of
acquisition or types of processing applied. Since both variables
contain measurements of easting, they both are properly labeled with a
standard_name of "projection_x_coordinate".
Grace and peace,
Jim
On 9/8/2011 1:20 AM, Kennedy, Paul wrote:
hi,
I am attempting to map from our existing conventions to CF
conventions. Most of the mappings appear straight forward, but I do
have a few curly ones. I read the "Guidelines for Construction of CF
Standard Names" page, but it did not help my situation.
As you can see, I may 'Easting" to CF
convention:'projection_x_coordinate', where easting represents raw
UTC coordinates.
However, I also have 'CorrEasting' which represents the
corrested (despiked, smoothed) easting for the same observation. We
need to maintain both the raw and the corrected value (for QC
purposes) Any ideas how I should map my data? If you can give me a
clue, I am sure my other tables will follow the same pattern.
One example data table is as follows...
Field Name <http://osdwiki.fugro/?title=Starfix_POS_file_format>
Description / Data Type
<http://osdwiki.fugro/?title=Starfix_POS_file_format>
CFConvention
<http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/18/cf-standard-name-table.html>
<http://osdwiki.fugro/?title=Starfix_POS_file_format>
Time;
double purpose(MSG_PURPOSE_TIME_GPS)
The time stamp of the observation. This is the time of
applicability, NOT the time of reception. The units are seconds since
6-1-1980 (Gps Origin).
time
FFID;
double;
This is typically the same as the shotpoint, but it can also
be used as a 'Fiducial Fix Identifier' a unique fix number)
FFID (no convention available)
ShotPoint
double
This is the shotpoint, also know as the fix number
Shotpoint (no convention available)
Easting
double purpose(MSG_PURPOSE_EASTING)
The RAW unprocessed, projected eastings (in metres) in the
projected coordinate system for that project.
projection_x_coordinate
Northing
double purpose(MSG_PURPOSE_NORTHING)
The RAW unprocessed, projected northings (in metres) in the
projected coordinate system for that project.
projection_y_coordinate
Height
double purpose(MSG_PURPOSE_HEIGHT)
The orthometric height in metres.
height
Kp
double purpose(MSG_PURPOSE_KP)
The kilometre post in metres (also called chainage, 'M' in
other packages).
Kp (no convention available)
Offset
double purpose(MSG_PURPOSE_OFFSET)
The distance cross course, in metres, where -ve is to the left
of the route, and positive is to the right of the route.
Offset (no convention available)
LineName
char[64]
The route linename. This can be a pipe route, cable route or
survey line.
LineName
ProcFlags
long purpose(MSG_PURPOSE_PROCFLAGS)
ProcFlags
CorrEasting
double purpose(MSG_PURPOSE_EASTING)
The FULLY processed, projected eastings (in metres) in the
projected coordinate system for that project.
CorrNorthing
double purpose(MSG_PURPOSE_NORTHING)
The FULLY processed, projected northings (in metres) in the
projected coordinate system for that project.
CorrHeight
double purpose(MSG_PURPOSE_HEIGHT)
The FULLY processed, orthometric height (in metres) in the
projected coordinate system for that project.
Speed
double purpose(MSG_PURPOSE_SPEED)
The vessel speed in metres per second. this is typically based
on the raw positions, not the 'Corr' positions.
Paul Kennedy
Technical Development Manager
Fugro Survey Pty Ltd
24 Geddes St, Balcatta
Western Australia 6021
ABN: 81 009 172 990
Ph : +61 (0)8 6477 4400
Direct: +61 (0)8 6477 4418
Fax : +61 (0)8 6477 4499
Mobile: +61 (0)439 518 265
Email : [email protected] <mailto:[email protected]>
Skype : p.kennedy.fugro.com
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
[email protected]
828-271-4900
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
[email protected]
828-271-4900
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
