MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] RE: OGC UoM Best Practices guidance
Gary and Rex -
Fully understand. The OGC UoM and related Observations and Measurements work
have been designed to insure that ALL metadata for a given measurement (say
from a sensor) can be accurately captured, encoded, and communicated. The
OGC members have determined that for our standards work related to sensors
etc that we must insure that the accuracy of measurement semantics,
measurement precision, and measurement accuracy and so forth must be
accommodated. This does not mean that an application needs to use all of the
capabilities - just that that they must be there if needed. Much of this
decision has to do with the level of ambiguity that an application can live
with. This is why UoM is important.
Anyway, attached is the latest OGC Observations and Measurement document.
The members approved release of this Discussion Paper last month. Has not
yet been posted to the OGC web site but will be soon.
There are numerous examples showing how UoM can be expressed as part of a
larger sensor observation encoding payload. Also shows use of GML, O&M and
UoM used in concert.
Not sure if this will make Gary's life any easier :-)
Cheers
Carl
----- Original Message -----
From: "Rex Brooks" <rexb@starbourne.com>
To: "Carl Reed OGC Account" <creed@opengeospatial.org>;
<emergency@lists.oasis-open.org>
Sent: Wednesday, March 29, 2006 9:32 AM
Subject: [emergency] RE: OGC UoM Best Practices guidance
> At the risk of catching a ration of flame from most all sides involved
> with this discussion, I tend to favor two ways of dealing with units of
> measure:
>
> 1. Specify that uom be specified either in the specification or that each
> implementation must specify what uom it uses, mandatory--and in web
> services, you just don't partner with companies whose uom in their wsdl
> does not match up with yours;
> 2. Specify metric system, period.
>
> Both are aimed at letting the marketplace enforce the standard, but
> Darwinism has a bad name in these parts, since it inevitablly means
> letting chips fall where they may, and in these parts chips are people so
> both of these are non-starters.
>
> In the choice arena between the concerns of programming realities on the
> ground versus getting critical information correct in critical moments, I
> tend to fall on the side of insisting on putting the burden on the quality
> assurance cycles in software development and test the bleep out of every
> last thing and just keep testing till it works 95% of the time. (Reality
> says 80% flies, but in this case, I have to remind folks that in these
> parts chips are people.)
>
> Ciao,
> Rex
>
> At 10:42 AM -0700 3/28/06, Carl Reed OGC Account wrote:
>>As I mentioned.
>>
>>
>>Carl Reed, PhD
>>CTO and Executive Director Specification Program
>>OGC
>>
>>The OGC: Helping the World to Communicate Geographically
>>
>>---------------------
>>
>>This communication, including attachments, is for the exclusive use of
>>addressee and may contain proprietary, confidential or privileged
>>information. If you are not the intended recipient, any use, copying,
>>disclosure, dissemination or distribution is strictly prohibited. If you
>>are not the intended recipient, please notify the sender immediately by
>>return email and delete this communication and destroy all copies.
>>
>>"The important thing is not to stop questioning." -- Albert Einstein
>>
>>
>>Attachment converted: Macintosh HD:Units_of_Measure_Rec#10783E.pdf (PDF
>>/�IC�) (0010783E)
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail. You may a link to this group and all your TCs in
>>OASIS
>>at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>
05-087r3_Observations_and_Measurements CNR Edited.doc
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]