[webservices] parsing units in FDSNStationXML

[Philip Crotwell]

Follow up question, there are seemingly two types of "units" in
FDSNStationXML, one used as an element and one as an attribute. The element
one, UnitType, appears to say follow the SEED convention, so you have units
with names like M/S, M and V. The unit attribute on FloatType is just a
string with no documentation on how it is to be used, but looking at
concrete uses of it in for example SecondType, VoltageType and
DistanceType, it appears that the string should be things like SECONDS,
VOLTS and METERS. So we have two different ways of specifying units in
FDSNStationXML with different  naming conventions.

Perhaps even more confusing, the SampleRateType specifies the fixed unit
string as SAMPLES/S, and which combines both unit naming conventions.

Can you clarify the unit naming scheme? I would like to be able to parse
the units, but it is much harder if there is not a clear mapping from unit
to/from strings.

Is this something that might be unified/simplified in a future version?

Also, should
   Delay and Correction in DecimationType be SecondType?
   Amplitude in ResponseListElement and Numerator and Denominator in
CoefficientsType be FloatNoUnitType as the units are in the enclosing
element?
   NumeratorCoefficient be FloatNoUnitType (or FloatType) to be like
CoefficientsType?


thanks
Philip


On Wed, Apr 10, 2013 at 12:22 PM, Philip Crotwell <crotwell at seis.sc.edu>wrote:

>
> Are there any guildlines for how the name of a unit in FDSNStationXML
> should be formed? Other than "do it like SEED"?
>
> I know the unit says it is the same as SEED blockette 34, but the SEED
> spec says use SI but use all uppercase, which contradicts the SI convention
> that case matters. So for example with prefixes m is milli and M is mega,
> and for units g is gram while G is gauss and s is second while S is
> siemens. I suppose most of seismology is covered by volt, meter, second and
> count, but there are more and more types of data begin recorded at seismic
> stations and so more varieties of units we need to support. And at some
> point it would be nice to get away from a "formatted as FORTRAN-like
> equations with all alphabetic characters in upper case" way of writing
> units and make us of the existing standards for better portability and
> exchange within and outside of seismology. It seems sad that the units are
> still just unstructured strings that make it challenging for code to parse
> and correctly interpret.  Following something like this might be useful:
> http://physics.nist.gov/cuu/Units/
>
>
>
> Just a thought,
> Philip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iris.washington.edu/pipermail/webservices/attachments/20130410/ae94ad4a/attachment.htm>