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: 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
>
>
> _______________________________________________
> 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/c681a497/attachment.html>
Received on Thu Sep 08 2011 - 08:25:01 BST
