Subject: Re: [Geopriv] building GML in PIDF

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Mar 2008 00:31:25 -0800

On Feb 29, 2008, at 2:04 PM, Brian Rosen wrote:

>   I think everyone would agree that you send what you have, so
> that if you have 49.03, 114.00, you send that, and don't drop  
> significant
> digits.

I thought that Carl said the opposite of that was typically use of  
GML. IE, we might do something more like form a GML four vertex  
polygon out of the points from 40.03+/-0.005 and 114.00+/-0.005  When  
I tried to look at GML specs, I could not find anything that suggested  
the numbers should be treated as anything other than floating point  
doubles.

The place where it would get really hairy to assume significant digits  
were meaningful in GML would be when you have a polygon where each  
vertex has a different number of significant digits. Even guaranteeing  
such a polygon is not self intersecting is not easy and computing the  
intersection of two such polygons in a spherical coordinate systems  
certainly hurts my head.

Anyways, I'm not arguing what we should do but when I thought people  
disagreed on the point about how you would send 49.03, 114.00 in GML.

Cullen <i hate writing this - with my individual contributor hat on>

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 02:37:07 -0600

This isn't quite the take from Carl that I took.

I took from Carl that we could, if we wanted to, provide meta-data for a specific point to suggest that it had a certain amount of error associated with it. I personally don't want to take this approach as it is still unclear to me what an end-pint or other entity would do with this information.

If, however, the working group decided that it did want to do this, then I would advocate most strongly that this be restricted to point representation only and not be applicable to vertices of a polygon. I would go so far as to lobby for updates to PIDF-LO profile to require this in our format recommendations.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Cullen Jennings
Sent: Sat 3/1/2008 2:31 AM
To: Brian Rosen
Cc: 'GEOPRIV'; 'Robert Sparks'
Subject: Re: [Geopriv] building GML in PIDF

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Mar 2008 01:10:47 -0800

On Mar 1, 2008, at 12:37 AM, Winterbottom, James wrote:

> I took from Carl that we could, if we wanted to, provide meta-data  
> for a specific point to suggest that it had a certain amount of  
> error associated with it. I personally don't want to take this  
> approach as it is still unclear to me what an end-pint or other  
> entity would do with this information.
>
Agree - I had that part wrong. It still seems the implication of that  
is that, unless some meta data was defined, typical GML would not use  
significant digits to provide this. Did I get that part of suggestion  
right?
>
>
> If, however, the working group decided that it did want to do this,  
> then I would advocate most strongly that this be restricted to point  
> representation only and not be applicable to vertices of a polygon.  
> I would go so far as to lobby for updates to PIDF-LO profile to  
> require this in our format recommendations.
>
> Cheers
> James
>
Cullen <individual rat>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Mar 2008 11:17:03 +0200

I would be interested to hear whether this special usage of GML might 
cause other problems.
To me it seems non-standard GML usage. Smells like a new set of problems 
we about to move into.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 10:13:05 -0500

I think we should not be implying anything with significant digits, and I
don't think we should be ignoring them.  You send what you get, no more, no
less, and what is being expressed in the DHCP geo option is a point, not a
polygon.

I don't think we should be making up meta-data.  If we want to express
meta-data, then we should send it in the DHCP option.

Look at it this way:  use of DHCP or use of HELD (or for that matter,
LLDP-MED) is an implementation choice, but it's a TRANSPORT of information.
We probably should not, in the protocol definition, discriminate between
methods of what we call "location determination", that is, how I determined
what the location is that I'm sending via the protocol.  DHCP and HELD and
LLDP should be able to be used with any location determination mechanism,
and have the results be the same, or at least nearly the same, with whatever
protocol is used to send it ("location configuration" of the endpoint).  

If you read a location off of a GPS unit, I don't care if we use HELD or
DHCP or LLDP to send it to the endpoint.  What we measured represents the
same thing; if it's a point, it's a point.  If there is meta-data, then we
should send it.  If there isn't, then we send what we have and we don't make
something up.

Carl is trying to be helpful and points out how flexible GML is.  I don't
think that is at issue.  If all the location determination mechanism
delivers is a point with significant digits, then all we can send is a point
with significant digits.  If there is a spec somewhere for that unit that
states what its confidence and uncertainty is, fine, send that.  If there is
an interface to get it, better, send it.  If there isn't, tough.

Brian

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, March 01, 2008 4:11 AM
> To: Winterbottom, James
> Cc: Brian Rosen; GEOPRIV; Robert Sparks

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Mar 2008 10:04:30 -0800

On Mar 1, 2008, at 7:13 AM, Brian Rosen wrote:

> don't think we should be ignoring them.
>
I have to tease you a little about this. I worried about an  
interoperable standard that says where we say, hey these bits are  
important, don't ignore them, but I refuse to tell you what they mean  
or what you might do with them.

But on a more serious note, do you see the res parameters in 3825 as  
meta data about the point or do you think of the meta data as  
something else?

Cullen <with my individual contributor hat on>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Mar 2008 20:30:43 +0200

I am not sure what you are suggesting.

Are you saying that we shouldn't do anything?

Brian Rosen wrote:
>>> ------------------------------------------------------------------------
>>>       
>> ------------------------
>>     
>>> ------------------------------------------------------------------------
>>>       
>> ------------------------
>>     
>>> [mf2]
>>>
>>>       
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 14:14:11 -0500

I see the res data in 3825 as a method to express significant digits in the
coordinates of a point.  I do NOT think they are meta data.

I understand your reservation, but when dealing with reality, it's best to
go with the flow.  Marc has pointed out a basic truism: despite the
geodist's preference for expressing precision/error with confidence and
uncertainty, many devices only report a coordinate pair.  Some of them use
significant digits, others don't.  Our protocol does not define location
determination, and it doesn't define location use.  It's only a mechanism to
move the location from the LIS to the endpoint.  I think it should be
transparent - transport whatever the determination mechanism came up with.

We always make choices, and thus we don't usually achieve the ideal.  In
this case, the original choice (ignore confidence and uncertainty, only send
significant digits) was, I think, too limiting.  I think we should add the
ability to send confidence and uncertainty.  

Actually, I'm kind of unhappy with just that, but I do think it's right
anyway.  My unhappiness is that many devices give you an error which, I
believe, really is close to Gaussian error distribution.  Confidence and
uncertainty don't let you express that: the actual location is equally
likely anywhere in the uncertainty region.  Of course equal probability
distribution encompasses Gaussian, but I do regret not being able to express
Gaussian (which is, after all, the way most error is expressed).  Henning
has pointed that out several times, and my understanding of actual GPS error
sources seems to indicate that the reality is that GPS error is fairly close
to Gaussian: the center point IS more likely to be right than the edges of
the uncertainty region.

But then the mobile guys come along, and for various reasons, even if they
use GPS, their actual measured results are NOT Gaussian distributed; they
really are happy with equal probability.  If you look at the literature, it
really does seem to say equal probability distribution is the expected way
to express error.  

So, I think we should carry confidence and uncertainty in all the LCPs.

Brian

> Sent: Saturday, March 01, 2008 1:05 PM
> To: Brian Rosen
> Cc: Winterbottom, James; GEOPRIV; Robert Sparks

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 14:16:36 -0500

NO!

I think we should carry confidence and uncertainty in all LCPs.
That is a change.  DHCP (and at present, LLDP-MED) doesn't do that.

I think we should leave the rez stuff in DHCP.

I think we must have some text which discusses these issues.  That is a
change.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, March 01, 2008 1:31 PM
> To: Brian Rosen
> Cc: 'Cullen Jennings'; 'Winterbottom, James'; 'GEOPRIV'; 'Robert Sparks'

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Mar 2008 21:36:49 +0200

Brian,

I would appreciate if we are more specific in this discussion.

I receive a PIDF-LO with geodetic location of a point. I have no idea 
how the Target got that information.
So, what does it mean?

Here is a practical example. I receive the following PIDF-LO:

    <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
         xmlns:gml="http://www.opengis.net/gml"
         xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
         entity="pres:[email-masked]">
       <dm:device id="mikepc">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>38.8986 -77.037</gml:pos>
               </gml:Point>
             </gp:location-info>
             <gp:usage-rules/>
             <method>Wiremap</method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
         <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
       </dm:device>
     </presence>

What does it mean?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Mar 2008 21:40:29 +0200

> I think we should carry confidence and uncertainty in all LCPs.
OK

> That is a change.  DHCP (and at present, LLDP-MED) doesn't do that.
OK

> I think we should leave the rez stuff in DHCP.
If you use rez in the sense of uncertainty then you are not describing a 
point but an area.
You are fine with describing an area rather than a point?

> I think we must have some text which discusses these issues.  That is a
What would the text say in your opinion?

Ciao
Hannes

>>> I think we should not be implying anything with significant digits, and
>>>       
>> I
>>     
>>> don't think we should be ignoring them.  You send what you get, no more,
>>>       
>> no
>>     
>>> less, and what is being expressed in the DHCP geo option is a point, not
>>>       
>> a
>>     
>>> polygon.
>>>
>>> LLDP-MED) is an implementation choice, but it's a TRANSPORT of
>>>       
>> information.
>>     
>>> methods of what we call "location determination", that is, how I
>>>       
>> determined
>>     
>>> what the location is that I'm sending via the protocol.  DHCP and HELD
>>>       
>> and
>>     
>>> LLDP should be able to be used with any location determination
>>>       
>> mechanism,
>>     
>>> and have the results be the same, or at least nearly the same, with
>>>       
>> whatever
>>     
>>> DHCP or LLDP to send it to the endpoint.  What we measured represents
>>>       
>> the
>>     
>>> same thing; if it's a point, it's a point.  If there is meta-data, then
>>>       
>> we
>>     
>>> should send it.  If there isn't, then we send what we have and we don't
>>>       
>> make
>>     
>>> something up.
>>>
>>> Carl is trying to be helpful and points out how flexible GML is.  I
>>>       
>> don't
>>     
>>> delivers is a point with significant digits, then all we can send is a
>>>       
>> point
>>     
>>> with significant digits.  If there is a spec somewhere for that unit
>>>       
>> that
>>     
>>> states what its confidence and uncertainty is, fine, send that.  If
>>>       
>> there is
>>     
>>>>> ----------------------------------------------------------------------
>>>>>           
>> --
>>     
>>>> ------------------------
>>>>
>>>>         
>>>>> ----------------------------------------------------------------------
>>>>>           
>> --
>>     
>>>> ------------------------
>>>>
>>>>         
>>>>> [mf2]
>>>>>
>>>>>
>>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 1 Mar 2008 15:50:04 -0500

> You are fine with describing an area rather than a point?

I can't speak for Brian, but maybe the guideline is to preserve as  
much of the original information returned by, say, GPS as possible.  
This seems to imply an area around a "fuzzy" point, since GPS appears  
to deliver data with a certain number of digits and, sometimes, some  
uncertainty/confidence region. During the transformation from GPS to  
DHCP to GML, you don't want to create information that didn't exist in  
the first place. Given the decimal-to-binary conversion, that seems  
difficult to do, however.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 1 Mar 2008 16:12:11 -0500

I'm not sure I understand the reference to Gaussian vs. uniform  
density. The confidence region simply indicates that 95% (or whatever)  
of the probability mass is contained in a certain region. It doesn't  
say anything about whether 99% is concentrated in 1/10th the radius  
and the remainder is "smeared" in 9/10th of the radius, or whether  
this is Gaussian or whether it's uniform. (Uniform is unlikely, since  
that would likely imply that a circle with an area 5% larger contains  
all of the probability mass.) In other words, the confidence and  
uncertainty work for any distribution and have the same meaning.  
However, unless you know the distribution parameters, you just can't  
deduce anything else. For example, you can't say

"Since the 90% confidence radius is 100m, the 95% confidence is 200m"

unless you know the distribution. Naturally, if you know that this is  
Gaussian, you can deduce the variance of the distribution and compute  
any other desired point (95%, 80%, ...). In this case, roughly 95% of  
the values are within two standard deviations and 99.7% are within  
three standard deviations. Thus, for the 100m example, you'd know that  
the standard deviation is 50m, so 99.7% of measurements should be  
within 150m radius and 68% within 50m.

Things get dangerous if, as has happened during some of the area  
matching discussions in ECRIT, people assume that the probability  
density function within the uncertainty region is constant.

Uniform does not "encompass" Gaussian, at least not in any statistical  
sense that I'm aware of.

A separate issue is that error distributions are only likely to be  
Gaussian in some average sense, across all points in the measurement  
area. If you were to take 100 measurements, with different GPS units,  
at a specific point, you'd get different results. Unless somebody  
tells you, you don't know whether  the provider of that information  
simply used the same confidence region for every point, maybe based on  
the information provided by the GPS manufacturer, or went through the  
trouble of recording uncertainty and confidence for the point you are  
at. If you've gone geocaching, you know that the uncertainty  
information changes pretty dramatically even if you stand still and  
even if the center point doesn't change. Thus, the answer you'd record  
into DHCP, say, would depend on when you measured it.

Thus, much of this information has to be taken with a rather large  
grain of NaCl, despite the "scientific" precision that these metrics  
imply.

See pictures at http://en.wikipedia.org/wiki/Normal_distribution (in  
1D, rather than 2D, but the same basic idea applies). Or http://en.wikipedia.org/wiki/Uniform_distribution_%28continuous%29

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 16:23:21 -0600

Yes that is what I believe what you are saying is right.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: Sat 3/1/2008 3:10 AM
To: Winterbottom, James
Cc: Brian Rosen; GEOPRIV; Robert Sparks
Subject: Re: [Geopriv] building GML in PIDF

Cullen <individual rat>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 16:28:58 -0600

Hannes,

There is an option d), which is redefine the meaning of the resolution bits so that they are useful for conveying uncertainty.
See http://tools.ietf.org/html/draft-thomson-geopriv-3825bis-01

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sat 3/1/2008 1:09 AM
To: Robert Sparks
Cc: GEOPRIV
Subject: Re: [Geopriv] building GML in PIDF
 
Thanks for the nice summary.

There are essentially three ways to solve this issue (based on my 
understanding):

(a) Express RFC 3825 information in GML
(b) Provide rules on how to transform RFC 3825 parameters into GML
Example can be found in 
http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-05#appendix-B
(c) Provide a way to make the translation simple
Example can be found at 
http://tools.ietf.org/wg/geopriv/draft-tschofenig-geopriv-dhcp-circle-00.txt

Case (a) is essentially telling the GML folks that they were wrong with 
what they did in the past. I would be interested to see how they react.

Case (b) leaves us with a fairly simple description but with some errors 
as that version of the PIDF-LO document explained.

Case (c) requires more work.

None of the approaches sound particularly great to me.

Ciao
Hannes

Robert Sparks wrote:
> I've spent the last couple of days reading and re-reading the binary- 
> lci related threads.
>
> I'm thinking hard about how the group can make progress, and what the  
> truly important things to make progress are on here.
> Feel free to help me figure that out (change the subject line if  
> that's what you are responding to - this subject is for the rest of  
> the message).
>
> Agreement about one thing in this thread is clear: GEOPRIV needs to  
> clearly state how to build a PIDF document when handed a bare pair of  
> lat/long coordinates.
>
> There are a bunch of other things in those threads, but lets focus on  
> that one thing for a moment.
>
> To help separate this from DHCP and the discussions around the  
> clarifications in the binary-lci document, let me put forth this use  
> case.
> It's a little (but only a little) contrived, but I hope it teases out  
> one of the things we need to get clarity on.
>
> Imagine an operator getting a call from someone where the transport  
> or source of the call gave them no help on identifying where the  
> problem spot was.
> The only way that information is conveyed is verbal.
> This could be someone radioing in from a boat, or someone with an old  
> CB radio talking to a family member with a land line - whatever.
> The person with the problem has some way to know their lat/long  
> (lunars and declinations, an old GPS, something scribbled on the  
> brass in the rock, again, whatever).
>
> The operator gets, verbally, that the problem is at 49.0N, 114.0W.
>
> What should the system the operator feeds that into emit (as a PIDF- 
> LO in, for example, a LOST query)?
>
> How is the answer different if operator gets 49.03N, 114.00W?
>
> (For those who haven't followed the threads, there's growing  
> understanding that simply putting those values in as
> GML 3.0 points isn't the right thing to do, and we're trying to  
> figure out what the right thing is).
>
> Thanks,
>
> RjS

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 17:42:53 -0500

It means you have a point, conveyed with 6 significant digits in one
latitude and 5 in longitude, and you have expressed no confidence and
uncertainty.  

This particular PDIF-LO could be assembled by an endpoint using the current
DHCP option.

Brian

> Sent: Saturday, March 01, 2008 2:37 PM
> To: Brian Rosen
> Cc: 'Cullen Jennings'; 'GEOPRIV'; 'Robert Sparks'

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 16:55:26 -0600

Actually no.

If you take 3825 as it is written today, it will produce a polygon with 4 sides.

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Sat 3/1/2008 4:42 PM
To: 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'Robert Sparks'
Subject: Re: [Geopriv] building GML in PIDF

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 18:05:45 -0500

> You are fine with describing an area rather than a point?
Nope, I don't agree.  You are describing a point.  That is the way GML works
as currently defined. 

It would be great if we always had a confidence and uncertainty, and if the
number of significant digits expressing the coordinates matched or exceeded
the error implied with confidence and uncertainty.  If we always had that,
we wouldn't be having this discussion.

I want the IETF to punt on how you evaluate error when you only have
significant digits and no expressed uncertainty and confidence.  There is no
generally accepted way to do so, and we have no expertise.  

If the device only gives you significant digits and no confidence and
uncertainty, send it.

If the device gives you a coordinate which is expressed with more
significant digits than the confidence/uncertainty implies, send it.

If the device gives you a coordinate which is expressed with fewer
significant digits than the confidence/uncertainty implies, send it.

The IETF is not able to offer any better answer.  I don't think we should
define how you interwork significant digits and uncertainty.  It's not in
our area of expertise.  We are protocol designers.  We can design a protocol
that transports the data without losing information (or inventing
information that doesn't exist).  That is enough. 

That has one implication that I think is worth pointing out:
If you get location expressed in binary with some number of significant
bits, you should express that with the closest equivalent number of
significant decimal digits if you have to convert (i.e. construct a
PIDF-LO).  You don't just create a float and convert the float, you preserve
the data as best you can.

> What would the text say in your opinion?
Pretty much what I said above.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 18:17:02 -0500

I know you keep saying that, but it doesn't say that, and I don't think we
want to change it so it does.  It describes how you encode a binary number
with some number of significant bits of fractional degrees.  The text calls
that "precision".  It does not discuss, or imply a polygon, and I don't
think we should change it to do so.

I do think some text is warranted on the subject of what the bits mean, but
as I have stated in prior email, I don't think we need to, or can
authoritatively say what they mean.  Nor do we have to.  We can simply
preserve the information provided by the determination mechanism and
transport it over a variety of protocols.  The recipient can make whatever
they want out of the information we transport.

Ignoring the difference between binary and decimal, what RFC3825 describes
is the same thing a GML point description has.  The point has two
coordinates with some number of significant bits in the fractional part of
the coordinates.  GML does not describe that as a polygon.  You can make
whatever inferences you want to make with whatever significant digits are
sent in the fractional part, especially when you don't send values for
confidence and uncertainty.

Hannes provided an example of a PIDF-LO which expressed a point with some
significant digits (different in lat and lon) and no confidence and
uncertainty.  It would be very feasible to construct that PIDF from an
RFC3825 result.  No bits would be harmed in the creation of the PIDF. No
data would be lost, no implication of what it means would be gained.  It's a
point.  Full stop.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Saturday, March 01, 2008 5:55 PM
> To: Brian Rosen; Hannes Tschofenig
> Cc: GEOPRIV; Robert Sparks
> Subject: RE: [Geopriv] building GML in PIDF
> 
> 
> Actually no.
> 
> > > I see the res data in 3825 as a method to express significant digits
> in
> > the
> > > I understand your reservation, but when dealing with reality, it's
> best
> > to
> > > this case, the original choice (ignore confidence and uncertainty,
> only
> > send
> > > to Gaussian: the center point IS more likely to be right than the
> edges
> > of
> > > the uncertainty region.
> > >
> > > really are happy with equal probability.  If you look at the
> literature,
> > it

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 1 Mar 2008 18:31:07 -0500

As I understand it the way confidence and uncertainty are defined by the geo
crowd, the actual location can be any point in the defined uncertainty
region with equal probability (and with the stated confidence).  

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, March 01, 2008 4:12 PM
> To: Brian Rosen
> 1D, rather than 2D, but the same basic idea applies). Or
> http://en.wikipedia.org/wiki/Uniform_distribution_%28continuous%29
> 
> > edges of

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Mar 2008 16:20:24 -0800

I see three different topics coming up here

1) how should a device that receives the bits described in 3825  
interpret the meaning of the bits

2) should we have done something more descriptive that 3825

3) how do do we represent information in GML such as I am somewhere in  
the area covered by latitude 38.896816 north to latitude 38.8985596  
and extends from -77.0372314 degrees to -77.0371094 degrees longitude.

I'm pretty interested in 1 and 3 because 2 seems like a very long  
conversation.

Cullen <with my individual hat on>

On Mar 1, 2008, at 3:17 PM, Brian Rosen wrote:

>> If you take 3825 as it is written today, it will produce a polygon  
>> with 4
>> sides.
>>
>>
>>
>>>> uncertainty, many devices only report a coordinate pair.  Some of  
>>>> them
>>> use
>>>> transparent - transport whatever the determination mechanism came  
>>>> up
>>> with.
>>>>
>>>> We always make choices, and thus we don't usually achieve the  
>>>> ideal.
>> In
>>>> significant digits) was, I think, too limiting.  I think we  
>>>> should add
>>> the
>>>> anyway.  My unhappiness is that many devices give you an error  
>>>> which,
>> I
>>>> believe, really is close to Gaussian error distribution.   
>>>> Confidence
>> and
>>>> distribution encompasses Gaussian, but I do regret not being able  
>>>> to
>>> express
>>>> has pointed that out several times, and my understanding of  
>>>> actual GPS
>>> error
>>>> sources seems to indicate that the reality is that GPS error is  
>>>> fairly
>>> close
>>>> But then the mobile guys come along, and for various reasons,  
>>>> even if
>>> they
>>>> use GPS, their actual measured results are NOT Gaussian  
>>>> distributed;
>>> they
>>>> really does seem to say equal probability distribution is the  
>>>> expected
>>> way
>>>> to express error.
>>>>
>>>>>> I think we should not be implying anything with significant  
>>>>>> digits,
>>>>>> and I

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 19:28:13 -0600

I think i agree with this in principle Cullen.
I do think that if we solve 1 and 3 in a way that makes 3825 useful then we will ultimately end up changing how the resolution bits are interpreted such we have to touch on 2.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 1 Mar 2008 19:48:59 -0600

Actually I don't think we agree on some of these points Brian and it is important that we do in order to effectively move forward.

GML points and LCI points are not equivalent, and you are suggesting that they are.
3825 has normative examples showing that it expresses an area, something that quite a number of us now I think agree it shouldn't do. If we step sideways now, some would argue that it is simply a point with a degree of "thickness", and this thickness is governed by the number of significant digits it has. This concept is fundamentally at odds with a point in GML, that has explicit statements saying that a point has no physical dimensions.

So the upshot is, that we need either :

1) a normative fix to 3825 that either allows it to express areas without introducing major errors, see the draft I pointed at in my previous email for one way to do this.

2) A normative fix to 3825 that says just encode this as point, don't talk about errors, but do show how yo convert this to a PIDF-LO. This will, like it or not, basically make the res parameters redundant.

There is a third option and that is to introduce the notion of fat points to GML, describe how to did, update PIDF-LO profile to say what this means and that it acceptable, and update LoST to have a profile that will allow sending this new fat point to the LoST server.

Personally I am not interested in doing 3.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Sat 3/1/2008 5:17 PM
To: Winterbottom, James; 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'Robert Sparks'
Subject: RE: [Geopriv] building GML in PIDF

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 12:16:26 +0200

I again have to agree with Cullen here.

> and extends from -77.0372314 degrees to -77.0371094 degrees longitude.
.... and here I believe we have the answer with GML already. This can be 
done using the shapes available.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 12:17:12 +0200

> Nope, I don't agree.  You are describing a point.  That is the way GML works

I might not be the GML expert but I know enough to say that a point in 
GML does not allow you to express an uncertainty area.

I think that the entire business of significant digits is a dead end.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 12:40:48 +0200

I wonder how we should continue.

I understand that there are different views on this subject.

 From the example of 
http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-05 the 
following value -34.41667, 150.53333 represents a point whereas 
-34.4167, 150.5333 represents an area.
One can also find a similar example in RFC 3825, Appendix A.1 with a 
point described as +38.89868 and -77.03723 and a number of examples that 
then represent an area.

I doubt that we (i.e., folks in the group) can find a solution to this 
issue. I would consult unbiased location experts at this point in time. .

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 2 Mar 2008 05:43:43 -0500

I don't really think you need to do 1.  You need to describe how you convert
the bits in 3825 to a PIDF.

I don't think we need to do 2 other than provide uncertainty and confidence.

I don't know why we need to do 3, but I'm not opposed to doing it.

Brian

> Sent: Saturday, March 01, 2008 7:20 PM
> To: GEOPRIV
> Cc: Brian Rosen
> >> -----------------------------------------------------------------------
> ---
> >> ----------------------
> >> -----------------------------------------------------------------------
> ---
> >> ----------------------
> >> [mf2]
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 13:02:07 +0200

> the bits in 3825 to a PIDF.

Since there are two approaches they have more or less semantic associated:

* the thick point approach: Just copy the values you receive with RFC 
3825 into a PIDF-LO with a point within the <location-info> element.
* the uncertainty approach: translate the values received with RFC 3825 
into a PIDF-LO as a polygon describing an uncertainty area.

Both approaches are some form of "clarifying the semantic" to RFC 3825. 

> I don't think we need to do 2 other than provide uncertainty and confidence.
You can obviously provide "default" values in the specification without 
conveying additional information in the protocol.

> I don't know why we need to do 3, but I'm not opposed to doing it.
Since you are advocating the thick point approach there is no area for 
you as such.

Ciao
Hannes

>>>>>> geodist's preference for expressing precision/error with confidence
>>>>>>             
>>>> and
>>>>         
>>>>>> significant digits, others don't.  Our protocol does not define
>>>>>>             
>>>> location
>>>>         
>>>>>> determination, and it doesn't define location use.  It's only a
>>>>>>             
>>>>> mechanism to
>>>>>           
>>>>>> Actually, I'm kind of unhappy with just that, but I do think it's
>>>>>>             
>>>> right
>>>>         
>>>>>> likely anywhere in the uncertainty region.  Of course equal
>>>>>>             
>>>> probability
>>>>         
>>>>>> Gaussian (which is, after all, the way most error is expressed).
>>>>>>             
>>>>> Henning
>>>>>           
>>>>>> So, I think we should carry confidence and uncertainty in all the
>>>>>>             
>>>> LCPs.
>>>>         
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>
>>>>>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 2 Mar 2008 08:15:50 -0600

I believe that the correct interpretation on receipt of a point is that
it is an indicative location. There definitely is uncertainty, but the
uncertainty has not been communicated.

All other shapes actually communicate a quantified value of uncertainty.

You can see from my discussion with Cullen on the lci-binary thread that
I think 3825 was only designed for communicating a point; he feels it
was designed for communicating specific rectangular areas of uncertainty
albeit in a somewhat limited way. I want 3825 to be explicit about what
it's communicating so that there is no miscommunication once it's
encoded in GML.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Sunday, 2 March 2008 6:37 AM
To: Brian Rosen
Cc: 'GEOPRIV'; 'Robert Sparks'
Subject: Re: [Geopriv] building GML in PIDF

Brian,

What does it mean?

Ciao
Hannes

> I see the res data in 3825 as a method to express significant digits
in the
> I understand your reservation, but when dealing with reality, it's
best to
and
location
mechanism to
> this case, the original choice (ignore confidence and uncertainty,
only send
right
probability
Henning
edges of
> really are happy with equal probability.  If you look at the
literature, it
LCPs.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 2 Mar 2008 16:43:31 -0600

Regarding:

> (Uniform is unlikely, since
> all of the probability mass.)

The convention that I've used is that uniform density applies to the
interior of the area.  Once you say 100m @ 95% w/ rectangular/uniform
PDF, you can't say anything about the exterior of that area.  Confidence
doesn't increase when you increase uncertainty.  Decreasing is OK: 50m @
23.75% w/ rectangular, increasing doesn't do anything for you: 200m @
95% w/ unknown.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 2 Mar 2008 18:24:38 -0500

I think it's best to simply say that the density within the interior  
(and exterior) is unknown and unspecified. Everything else is likely  
to be wrong from a measurement perspective, leads to counterintuitive  
results (such as the ones I mentioned) and not terribly helpful. This  
does indeed imply that drawing any conclusions about larger  
uncertainty regions is pointless, as you seem to indicate, if I  
understand your message below. I can't imagine that anybody with  
training in probability or measurement would suppose that the interior  
density is or has to be uniform.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 2 Mar 2008 18:30:21 -0600

In general, it is best to avoid reliance on the distribution altogether.
As you say, even if it is approximately accurate, most uses only degrade
the quality of the result.  Certainly, from a location service
perspective (be it presence, LIS, LoST or otherwise), anything that
relies too heavily on assumptions like that are likely to produce poor
results.

However, if the information is there, you shouldn't prevent its use
entirely.  It is sometimes necessary to make assumptions.  Like the
assumption that is made in selecting a point from a region of
uncertainty, or those that are made when determining whether a Target is
within a particular area.

M

> Sent: Monday, 3 March 2008 10:25 AM
> To: Thomson, Martin
---------------------------------------------------------------------
> ---------------------------
---------------------------------------------------------------------
> ---------------------------
> > [mf2]
> >
>

---

From: [email-masked]
Date: Mon, 3 Mar 2008 15:24:10 +0000

> I think that the entire business of significant digits is a dead end.

I agree entirely.

The fundamental problem with significant digits is that by definition they 
force the region of uncertainty to be aligned on digit boundaries.  They 
don't allow for an arbitrarily precise center-point with a different 
precision uncertainty.

Digit boundies are artificial, though, because they depend on the number 
base you're working in.  That's putting a mathematical constraint on which 
ranges are valid that doesn't happen in the real world.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 3 Mar 2008 12:00:55 -0500

In-line.. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, March 03, 2008 10:24 AM
> To: [email-masked]
> The fundamental problem with significant digits is that by 
> definition they force the region of uncertainty to be aligned 
> on digit boundaries.  They don't allow for an arbitrarily 
> precise center-point with a different precision uncertainty.
> 
> Digit boundies are artificial, though, because they depend on 
> the number base you're working in.  That's putting a 
> mathematical constraint on which ranges are valid that 
> doesn't happen in the real world.

No, the majority of the 'real world' lives with using significant digits,
even in geo-location.  It simply works for the application.

-Marc-

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 3 Mar 2008 10:25:09 -0700

I will be jumping into various points in this discussion.

GML is agnostic as to how to express the actual coordinates for defining a geometry element (whether a point, circle, polygon, etc). The documented OGC policy is that a GML payload should follow the axis order and coordinate expression as defined in the CRS (coordinate reference system). In the case, the CRS can be thought of as metadata that defines not just the projected coordinate system being used but also the units of measurement for the coordinates (feet, meters, decimal degrees, and so forth). Conversely, you can define the rules for how a coordinate is expressed and encode the metadata definition for this coordinate encoding as either part of the GML payload or via some external mechanism. The key is to have the agreement and then document that agreement as part of the payload. 

So any of the following encodings are just fine in GML. The first is from GeoRSS - typical geographics encoding following the CRS rules. The second is for an archeology application of GML for stating the position of ceramic discoveries at a dig using an arbitrary grid. The third example is from a gazetteer application in Canada that shows how additional metadata can be used to more explicitly state how the point geometry is encoded.

1.
    <gml:Point xmlns:gml="http://www.opengis.net/gml"> 
      <gml:pos>35.669998 139.770004</gml:pos> 
    </gml:Point> 

2.   <gml:coord>
        <gml:X>14625.166504</gml:X>
        <gml:Y>13709.92893965028</gml:Y>
      </gml:coord>
      <gml:coord>

3.     <gml:Point srsName="EPSG:4326">
          <gml:coordinates decimal="." cs="," ts=" ">
             -79.5,43.6
          </gml:coordinates>
        </gml:Point> 
In summary, unlike KML or GeoRSS (at least thus far) GML does NOT assume a single, fixed coordinate system. It must be specified by the creator of the data. The coordinate system is specified (what OGC calls a Coordinate Reference System) using the srsName attribute. This is attached to a geometry object as shown in the following example: 

<gml:Point gml:id="p1" srsName="#srs36">
    <gml:coordinates>100,200</gml:coordinates>
</gml:Point>
The value of the srsName attribute is a URI. It refers to a definition of the coordinate reference system that is used to interpret the coordinates in the geometry. This definition may live in a document (e.g. a flat file) or in an online web service.

The srsName URI may also be a URN. This then provides a well known string for referencing common CRS definitions. The OGC has developed a set of URN strings for some common coordinate systems. It is intended that these URN's resolve through a URN resolver to CRS definitions.  You may use the URN approach to define your own CRS rules.

Also, check out SRSReferenceGroup and SRSInformationGroup for suggested mechanisms for specifying other information related to how a coordinate is encoded in GML. For example, SRSReferenceGroup has an optional element that allows the application to express whether the coordinate is integer, float, etc.

Finally, check out the use of GML Dictionaries and how these can be used to document application specific CRS requirements, such as encoding lat-long as 45N, 114W. http://books.google.com/books?id=YObBoIK8hbcC&pg=PA192&lpg=PA192&dq=gml+coordinate+encoding&source=web&ots=5pj1G5BrzY&sig=_bIlzvE1FiNZibUplucvt5mUSwo&hl=en#PPA199,M1

Totally unrelated: If anyone is interested in a fairly simple GML tutorial (on-line), go to https://courseware.e-education.psu.edu/courses/geog585/content/lesson06/1.html. While this tutorial does not answer the issues being discussed in this list, for those who wish to know more about GML and not read the GML standard (550 page document) . . .

Regards

Carl

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 3 Mar 2008 10:32:00 -0700

Brian -

Thanks!

If this group can provide me one or more use cases of what is trying to be
accomplished, then I can work with the OGC membership to provide valid and
unambiguous examples of GML encodings that meet the requirements of the use
cases.

And Brian is correct in terms of a point geometry moving through the value
chain from collection to application. If a point geometry has 5 significant
digits being packaged into a GML payload, then it will be sent with the 5
significant digits and will arrive at the destination point with those 5
significant digits. The receiving application then needs to know what to do
with those 5 significant digits and what they mean. Hence the need for
metadata. Where that metadata is provided may or may not be a GML related
issue.

Cheers

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Cullen Jennings'" <[email-masked]>; "'Winterbottom, James'"
<[email-masked]>
Cc: "'GEOPRIV'" <[email-masked]>; "'Robert Sparks'"
<[email-masked]>
Sent: Saturday, March 01, 2008 8:13 AM
Subject: Re: [Geopriv] building GML in PIDF

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 3 Mar 2008 11:21:18 -0700

Cullen -

Yes, your assumption is correct regarding the first point.

Carl

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 3 Mar 2008 11:05:41 -0800

Thank you that is very helpful. The questions I would be interested in  
is the following.  (please note this is just me that is interested in  
this and the WG may or may not be interested in this - I do understand  
that questions can be somewhat loaded and that some people will no  
doubt object to this question). I tried to make these two  
possibilities match what I think Hannes was proposing but perhaps I  
misunderstood Hannes.

Say you want to represent an
        area that is latitude 38.896816 north to latitude
        38.8985596 and extends from -77.0372314 degrees to -77.0371094
        degrees longitude.

Which of the following two GML documents seem the most reasonable way  
to do this, or is there some third way we should use.

Option A:

               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:exterior>
                    <gml:LinearRing>
                      <gml:pos>38.896816   -77.0372314</gml:pos> <!-- 
A-->
                      <gml:pos>38.8985596 -77.0371094</gml:pos> <!--B-->
                      <gml:pos>38.8985596 -77.0371094</gml:pos> <!--C-->
                      <gml:pos>38.896816   -77.0372314</gml:pos> <!-- 
D-->
                      <gml:pos>38.896816   -77.0372314</gml:pos> <!-- 
A-->
                    </gml:LinearRing>
                  </gml:exterior>
                </gml:Polygon>

Option B:

                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>-38.89 -77.037</gml:pos>
                </gml:Point>

Hopefully I did not mess up the GML but I was trying to make option A  
a four vertex polygon around the area and option B a point where the  
number of significant digits implied something that bounded the area.

I have read the spec and understand how Option A could be interpreted  
to mean this but if the answer is option B, I'd be very interested in  
pointers to understanding why. If the answer is B, I would also be  
interested if it was required by the GML spec that implementation   
libraries represented the gml:pos elements in a form that persevered  
significant digits or if a floating point double representation is all  
that is required.

Thanks, Cullen

On Mar 3, 2008, at 9:32 AM, Carl Reed wrote:

> ----- Original Message ----- From: "Brian Rosen" <[email-masked]>
>> there
>> is

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Mar 2008 14:41:21 -0500

I am not advocating a thick point approach.  I don't want the IETF to define
what significant digits mean.  I want to have the IETF define a mechanism to
transport a measurement from a location determination mechanism, through a
Location Configuration Protocol to an endpoint, and from an endpoint to a
recipient without losing or gaining information.

That means if I have two protocols (say DHCP as an LCP and SIP Conveyance)
that have different representation of data, I need to define how to
interwork the representations.

In this case, I want to say: take the representation of the numbers in DHCP,
convert them from a binary fractional degree representation to a decimal
fractional degree representation, preserving the significant digits, and
construct a GML point description using the coordinates.

That is NOT a thick point.

It isn't an area either.

I don't think I need any default values.

Brian

> Sent: Sunday, March 02, 2008 6:02 AM
> To: Brian Rosen
> Cc: 'Cullen Jennings'; 'GEOPRIV'

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Mar 2008 14:44:15 -0500

On this aspect, we agree.

I think it should communicate a point, with no uncertainty.  

Of course, I think we should preserve significant digits.  I think it's up
to the recipient to do whatever it wants with them, and I don't think we
need to say what they mean.  They are what we got from the measurement
mechanism, and we carry them reasonably faithfully through the Internet.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Sunday, March 02, 2008 9:16 AM
> To: Hannes Tschofenig; Brian Rosen

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Mar 2008 14:48:54 -0500

Well, again, they define it as equal probability anywhere in the area.

I've been told what Martin said about not being able to make an assumption
about the exterior is true, except that there are ways people attempt to
convert uncertainty at one confidence level to uncertainty at another
confidence level so that they can compare two measurements.  I am told that
it's very hard to do that, but in some environments, they do it anyway.

Brian

> Sent: Sunday, March 02, 2008 6:25 PM
> To: Thomson, Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Mar 2008 14:59:02 -0500

I brought this subject of distribution up because, I am told, GPS error is
fairly close to Gaussian, and definitely is more probable near the stated
coordinate than at the edges of any uncertainty area ascribed to it.  Since
that is a real common case, it sure would be nice to know it.

In fact, you have to look REALLY hard to find any discussion of a confidence
and uncertainty value for GPS.  They will list the error sources and pretty
commonly describes the result in meters. 

Having said that, I don't know how to communicate error distribution
sensibly, so I may have caused more confusion that is warranted.  

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Sunday, March 02, 2008 7:30 PM
> To: Henning Schulzrinne

---

From: Richard Barnes <[email-masked]>
Date: Mon, 03 Mar 2008 15:17:18 -0500

> That is NOT a thick point.

You're right, it's an infinitely precise point because GML defines 
coordinates as IEEE floats, which have no notion of precision, and this 
is how standards-compliant implementations will treat them.

This is the issue: Because GML coordinates (vs. metadata) have no notion 
of precision or significant digits, implementations of GML (parsers, 
etc) will treat limited-precision information as full-precision.  So 
there's not point to encoding significant figures in GML coordinates 
because standards-compliant implementations will ignore it.  What's 
worse, if someone tries to convert back from a GML point to an LCI 
point, ALL the digits will be significant, even if they weren't in the 
original LCI point.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 03 Mar 2008 15:22:56 -0500

Carl, Cullen,

I would state this slightly differently.  The use case we're concerned 
about is when you want to represent a point with finite-precision 
coordinates.

This maps Cullen's options to the following:

A) Encode the point as the rectangle/prism containing all points allowed 
by the precision

B) Encode the point as a GML Point, expressing precision in the number 
of digits in the coordinates

Also, based on Carl's previous messages, I believe there is a third option

C) Encode the point as a GML Point, expressing precision directly in 
metadata.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 3 Mar 2008 16:05:26 -0500

> Well, again, they define it as equal probability anywhere in the area.

I'd like to see that definition and who "they" are. I would hope that  
geo folks have more clue than that, unless they all slept through  
Intro to Statistics :-)

> it's very hard to do that, but in some environments, they do it  

I've explained why this is not just "hard", but a fool's errand unless  
you know the distribution.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Mar 2008 17:22:10 -0600

At 04:55 PM 3/1/2008, Winterbottom, James wrote:

>with 4 sides.

sez who?

Where is this written?

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 3 Mar 2008 17:26:09 -0600

Actually James you have said this more times than I can count, if I had
the time I would find a few references in the archives to this point.
There is also an appendix full of normative examples in 3825 to show
that this is what it is intending to represent. Need I go?

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 4 March 2008 10:22 AM
> To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
> > > > move the location from the LIS to the endpoint.  I think it
should
> be
> > > > transparent - transport whatever the determination mechanism
came up
ideal.
> > > > significant digits) was, I think, too limiting.  I think we
should
> add
> which, I
Confidence
> > > > distribution encompasses Gaussian, but I do regret not being
able to
> > > > has pointed that out several times, and my understanding of
actual
> GPS
even
> if
distributed;
> > > >> important, don't ignore them, but I refuse to tell you what
they
> mean
> > > >> But on a more serious note, do you see the res parameters in
3825
> as
--
> -----------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Mar 2008 17:34:59 -0600

At 07:48 PM 3/1/2008, Winterbottom, James wrote:
>Actually I don't think we agree on some of these points Brian and it 
>is important that we do in order to effectively move forward.
>
>3825 has normative examples showing that it expresses an area,

James - where are these normative example in RFC3825? What section(s) 
and what page(s) are they on?

I think you're referring to the appendixes, which aren't normative.

>something that quite a number of us now I think agree it shouldn't 
>do. If we step sideways now, some would argue that it is simply a 
>point with a degree of "thickness", and this thickness is governed 
>by the number of significant digits it has. This concept is 
>fundamentally at odds with a point in GML, that has explicit 
>statements saying that a point has no physical dimensions.
>
>1) a normative

answer the Qs above first

>  fix to 3825 that either allows it to express areas without 
> introducing major errors, see the draft I pointed at in my previous 
> email for one way to do this.
>
>2) A normative

answer the Qs above first

>fix to 3825 that says just encode this as point, don't talk about 
>errors, but do show how yo convert this to a PIDF-LO. This will, 
>like it or not, basically make the res parameters redundant.
>
>There is a third option and that is to introduce the notion of fat 
>points to GML, describe how to did, update PIDF-LO profile to say 
>what this means and that it acceptable, and update LoST to have a 
>profile that will allow sending this new fat point to the LoST server.
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Mar 2008 17:38:59 -0600

Hannes

Aren't the two lines you wrote above completely contradicting each other?

Line #1 - GML only does points
Line#2 - no significant digits allowed

So, unless all Targets are only on integer degrees (i.e., 23.0), then 
they cannot have their locations expressed at all.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 3 Mar 2008 17:37:32 -0600

Actually they are directly referred to from the normative text to
illustrate how something is to be used. In any sane person's
interpretation that makes them normative!

> Sent: Tuesday, 4 March 2008 10:35 AM
> >I know you keep saying that, but it doesn't say that, and I don't
think
> >I do think some text is warranted on the subject of what the bits
mean,
> but
> >coordinates with some number of significant bits in the fractional
part
> > > This particular PDIF-LO could be assembled by an endpoint using
the
> > > current
> > > > > go with the flow.  Marc has pointed out a basic truism:
despite
should
> > > > > transparent - transport whatever the determination mechanism
came
should
> > > > > distribution encompasses Gaussian, but I do regret not being
able
actual
even
they
3825
> ----
> ----
--
--

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Mar 2008 18:21:27 -0600

>that this is what it is intending to represent. Need I go?

no appendix is normative in IETF docs

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 4 Mar 2008 10:46:20 -0700

Cullen -

No, you did not "butcher" any of the GML :-)

You may also encode the 4 point polygon in the form:
      <gml:Polygon>
         <gml:exterior>
            <gml:LinearRing>
               <gml:posList>

            45.256 -110.45 46.46 -109.48 43.84 -109.86 45.256 -110.45
               </gml:posList>
            </gml:LinearRing>
         </gml:exterior>
      </gml:Polygon>or as

      <gml:Envelope>
         <gml:lowerCorner>42.943 -71.032</gml:lowerCorner>         <gml:upperCorner>43.039 -69.856</gml:upperCorner>      </gml:Envelope>I need to dig a bit more in terms of your questions regarding option B.

One thing that I have not mentioned is that when working with geographics, one needs to consider the fact that whatever approach is used to specify the fuzziness factor for a point geometry, that the mapping from geographics to some other coordinate reference system, such as UTM, will result in a geometry that is no longer a circle or a rectangle. 

Cheers

Carl