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