<http://www.uncertml.org/>
On Jan 19, 2010, at 12:00 PM, Carl Reed wrote:
> Since the discussion involved how to express uncertainty, I would
> encourage the group to at least consider the information model used
> in UnCertML. Understanding that 3825 is a binary encoding, use of a
> common info model for uncertainty that could be expressed in binary,
> as XML, as whatever would be quite nice - and easier for the
> implementation community. UnCertML is (from their website):
>
> UncertML is a conceptual model, with accompanying XML schemata, that
> may be used to quantify and exchange complex uncertainties in data.
> The interoperable model can be used to describe uncertainty in a
> variety of ways including:
> a.. Realisations or sampled data
> b.. Statistics including means, variances, standard deviations and
> quantiles
> c.. Probability distributions including both marginal and joint
> distributions and mixture models
> The OGC community is working closely with the statistical gurus who
> represent the UnCertML community. Much joint work in the information
> fusion domain, where expressing uncertainty using a common model is
> extremely important.
>
> Cheers
>
> Carl
>
> ----- Original Message ----- From: "Winterbottom, James" <James.Winterbottom@andrew.com
> >
> To: "James M. Polk" <jmpolk@cisco.com>; "Thomson, Martin" <Martin.Thomson@andrew.com
> >; "Bernard Aboba" <bernard_aboba@hotmail.com>; <geopriv@ietf.org>
> Sent: Monday, January 18, 2010 12:39 PM
> Subject: Re: [Geopriv] Issue #3: GML Mapping
>
>
>> Martin I am sure will add to this but this is my take on what the
>> issues with your statements below are.
>>
>> Firstly, you are trying to represent uncertainty using significant
>> figures, and a number of very credible references have been cited
>> indicating that this is a very bad idea.
>>
>> Secondly, when you turn this into XML, there is no way to express
>> the difference between the two numbers you describe below. When the
>> XML is interpreted, they are both represented by exactly the same
>> IEEE double. This means that your intent of representing
>> uncertainty through significant figures is completely lost and you
>> are misrepresenting the location, and indeed the area of
>> uncertainty around it.
>>
>> To my mind, these are the main issues for us BISing this document
>> in the first place.
>>
>> Cheers
>> James
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
>>> On Behalf
>>> Of James M. Polk
>>> Sent: Tuesday, 19 January 2010 6:02 AM
>>> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
>>> Subject: Re: [Geopriv] Issue #3: GML Mapping
>>>
>>> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
>>> > > [BA] Any recommendations on how we should
>>> > resolve the remaining aspects of Issue #3?
>>> >
>>> >I still don’t really know what resolution means.
>>>
>>> well... that's silly (so I'm expecting this to
>>> actually be a trap question), as several folks
>>> have explained this to you (and others) over the years.
>>>
>>> To fall into your trap, let me explain again
>>> (even though John S. explains it best):
>>>
>>> The resolution field indicates how many bits to
>>> be considered valid (left to right) when looking
>>> at a Lat, Long or Alt field value.
>>>
>>> The analogy is a subnet mask, but I know most
>>> here don't understand that -- where the mask
>>> doesn't indicate the length of the host part but
>>> of what shouldn't be viewed at all.
>>>
>>> This was never really meant to indicate less than
>>> all integers within a Lat/Long/Alt value, but it
>>> could. It is meant to indicate the number of
>>> decimals to account for (i.e., is the number X.1
>>> or X.100000 -- which are two different numbers entirely).
>>>
>>> put another way, albeit loosely defined -
>>> resolution is a left to right length field within
>>> the binary to indicate how many bits to convert
>>> from binary to decimal for a particular
>>> Lat/Long/Alt value. All bit values to the right
>>> of the resolution indication are to be ignored.
>>>
>>> Marc or John S can correct me.
>>>
>>> James
>>>
>>> >That lies at the heart of the problem. Hence my
>>> >preference to defer to James P. (or one of his colleagues) at
>>> this >point.
>>> >
>>> >As far as I can extract from the history of the
>>> >issue, there are two possible interpretations, and maybe more:
>>> >
>>> > (1) If resolution is roughly analogous to
>>> > uncertainty, then I don’t see an easy way to
>>> > provide a GML->3825 mapping. Following the
>>> > same process that I used for the uncertainty
>>> > mappings just leads to weird results (the 32 degree crossover
>>> problem).
>>> >
>>> > The 3825->GML mapping is easy enough for this
>>> > case, and it could be based on the old
>>> > examples, but there are a few minor
>>> > mathematical errors (for instance, the very
>>> > first point states that res2 is -1 to 128,
>>> > which is inconsistent with res5 at -64 to -80;
>>> > I think that res2 should be 0 to -128).
>>> >
>>> > (2) If resolution is simply a way of encoding
>>> > significant digits (i.e., 3 bits =~ 1 decimal
>>> > digit; 10 bits =~ 3 decimal digits), then the
>>> > mapping is simply a GML point<->3825 mapping,
>>> > but the examples would have to be entirely replaced.
>>> >
>>> >I don't have any particular preference.
>>> >
>>> >--Martin
>>> >
>>> >
>>> >_______________________________________________
>>> >Geopriv mailing list Geopriv@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
