[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[UDUNITS #PIK-524714]: xlink dictionary references for GCM model output re udunits2 and ISO19115



John,

Sounds like you've got a lot of work on your hands.

The UDUNITS package was designed to parse string unit specifications as 
described by the NIST (see <https://physics.nist.gov/sp811>). It can handle a 
few other styles as well (e.g., a period instead of a half-high dot).

Although we developed the UDUNITS package, we're not familiar with the other 
references you mentioned -- so our help in those areas is limited.

The CF-conventions group has an active mailing-list, if that might help.

Feel free to contact us if you have any issues with the UDUNITS package.

> I seek some input as how to best handle unit references to satisfy
> both UCAR related (e.g. CF-conventions, THREDDS) and ISO19115 conventions.
> 
> Caveat:
> I have until Nov 2017 no experience with the world of Metadata/StyleSheets/
> Transforms/ISO19115/vocabularies.
> Along with NOAA,UCAR(NetCDF,Unidata,CF),ISO,W3 websites, I have also found
> those of IOOS and PACIOOS instructive helpful.
> 
> I have been tasked with creating MetaData for a number of products created
> or used at http://cw3e.ucsd.edu .
> To begin with, I am focusing on WRF model output and the MI_Metadata
> template. I hope that the metadata
> will lean in the direction with what I sense to be evolving standards, at
> least in the earth sciences
> community.
> 
> I used `ncdump -h` header information and NetCDF_ToolsUI_4.6 ncgm output to
> assist in populating the MI_Metadata entities.
> 
> In the process I used oXygen and (github) ncISO2.0/UnidataDD2MI.xsl to
> transform the ncgm into xml .
> Regarding variable units, the xml is populated with entries like:
> 
> <gmd:units xlink:href="http://example.org/someUnitsDictionary.xml#mm"/>
> 
> At this stage in my evolving understanding of ISO, NOAA, and UCAR
> conventions
> I perceive it would be beneficial to change these links to cite
> udunits2-*.xml files
> e.g.  https://www.unidata.ucar.edu/software/udunits/udunits-
> current/udunits/udunits2-prefixes.xml
> 
> I started to invent the wheel writing scripts to parse and match model
> units to udunits entities
> ... and eventually realized the scope and subtleties involved.
> 
> Simple issues:  the WRF model units are inconsistent, e.g. regarding
> denominators vs negative
> exponents, the use/meaning of blanks space, ...
> Additional complexity exists in the way udunits handle unit sub components,
> e.g. scaling
> prefixes in the file above, being separate from other components of a unit,
> the two of
> which would commonly be combined in model output metadata.
> Generally matching the plethora of potential aliases to base/common/derived
> units.
> 
> I searched for potential udunits2 tools and found links such as
> https://www.unidata.ucar.edu/software/udunits/udunits-2.0.4/udunits2lib.html
> 
> I have seen metadata which lacks unit dictionary references and wonder if
> I am attempting to take on too much for a novice.  Admittedly at this stage
> my head is swimming and the degree to which certain pieces of information
> are necessary to satisfy conventions (vs desirable to include) is still
> not completely clear.
> 
> Can anyone recommend a way forward?  A units parsing/processing tool ?
> Or advice as to how to handle the units issue more simply but with an
> eye to evolving conventions?   (A state of the art yet eloquently simple
> summary of any of the issues addressed herein :) )
> 
> (Of course, the local powers of be want all this yesterday)
> 
> Thanks for your time and any potential input!

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: PIK-524714
Department: Support UDUNITS
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.