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
