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
