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
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> 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
