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: cf-metadata-bounces at cgd.ucar.edu <cf-metadata-bounces at cgd.ucar.edu>
To: cf-metadata at cgd.ucar.edu <cf-metadata at cgd.ucar.edu>
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 : p.kennedy at fugro.com.au <mailto:p.kennedy at fugro.com.au>
Skype : p.kennedy.fugro.com
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
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
jim.biard at noaa.gov
828-271-4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110908/6aca94d4/attachment-0001.html>
Received on Thu Sep 08 2011 - 07:29:07 BST
