Subject: [Geopriv] Issue #3: GML Mapping

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Jan 2010 23:18:32 -0800

A good portion of Issue #3 was resolved in RFC 3825bis-05:
http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis

However, as Martin notes, we do not have GML mapping examples for the resolution fields (or fixes for errors in the current examples):

"...and I forgot, I cannot provide examples of GML mappings for the
resolution fields. The current examples have some errors as well. I
recommend that James Polk look at these."

[BA] Any recommendations on how we should resolve the remaining aspects of Issue #3?

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 18 Jan 2010 07:17:18 +0800

> [BA] Any recommendations on how we should resolve the remaining aspects of Issue #3?

I still don’t really know what resolution means.  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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Jan 2010 13:02:17 -0600

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.
>
>_______________________________________________ 
>Geopriv mailing list [email-masked] 
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jan 2010 03:39:02 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Tuesday, 19 January 2010 6:02 AM
> To: Thomson, Martin; Bernard Aboba; [email-masked]
> Subject: Re: [Geopriv] Issue #3: GML Mapping
> 
> >I still donâ€™t really know what resolution means.
> 
> > uncertainty, then I donâ€™t see an easy way to

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 18 Jan 2010 15:32:33 -0500

James W: Re-visiting the utility of the resolution representation is  
not germane here.  What's needed for the -bis is a clear explanation  
of what it means, which I believe James P is trying to provide.

Martin: You're correct that mapping GML->3825 is difficult; the point  
of the "uncertainty encoding" is to provide an easier represtation.   
But we still need a 3825->GML mapping to give the "representation  
encoding" an unambiguous semantic.

James P: Could you turn your description below into an algorithm?   
That is given a coordinate and a resolution value, how do you  
determine the minimum and maximum values for that coordinate?   
Repeating that algorithm for each coordinate should provide a mapping  
between 3825 and a GML polygon/prism.

Thanks,
--Richard

On Jan 18, 2010, at 2:39 PM, Winterbottom, James wrote:

> 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.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 19 Jan 2010 06:48:08 +0800

Hi James,

I'm not interesting in playing petty games.  I understand your explanation; but that's never been the problem.  I'm just not certain how the theory reduces to practice.

If you could produce the GML mapping algorithm as Richard suggests, 3825 -> GML, that would clear this all up.  That way, me being dense becomes irrelevant.

--Martin

> From: James M. Polk [mailto:[email-masked]]

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 19 Jan 2010 10:00:34 -0700

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" <[email-masked]>
To: "James M. Polk" <[email-masked]>; "Thomson, Martin" 
<[email-masked]>; "Bernard Aboba" <[email-masked]>; 
<[email-masked]>
Sent: Monday, January 18, 2010 12:39 PM
Subject: Re: [Geopriv] Issue #3: GML Mapping

> 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.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 19 Jan 2010 12:12:22 -0500

For those who are unfamiliar:
<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:
> 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" <[email-masked] 
> >
> To: "James M. Polk" <[email-masked]>; "Thomson, Martin" <[email-masked] 
> >; "Bernard Aboba" <[email-masked]>; <[email-masked]>
>> 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.
>>
>>> >preference to defer to James P. (or one of his colleagues) at  
>>> this >point.
>>> >