Subject: [Geopriv] FYI: [Geo-Shape document and OGC]

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 21 Dec 2006 13:21:27 -0700

Last week the OGC members approved the draft-thomson-geopriv-geo-shape-03.txt document as an OGC Best Practices paper. Martin worked with me to put the document in the correct OGC standards template format. The approved document will be posted to the OGC pubic web site sometime next week after a final proof read (posted at http://www.opengeospatial.org/standards/bp). An OGC Best Practices document is an official position of the OGC membership. As such, it can be viewed as stable enough for implementation, vetted by the membership, and in the correct format.

Regards

Carl Reed, PhD
CTO and Executive Director Specification Program
OGC

The OGC: Helping the World to Communicate Geographically

---------------------

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein 
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller 

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Dec 2006 19:25:03 -0600

This is excellent news!

Great achievement Martin

________________________________

From: Carl Reed OGC Account [mailto:[email-masked]] 
Sent: Friday, 22 December 2006 7:21 AM
To: [email-masked]
Subject: [Geopriv] FYI: [Geo-Shape document and OGC]

Last week the OGC members approved the
draft-thomson-geopriv-geo-shape-03.txt document as an OGC Best Practices
paper. Martin worked with me to put the document in the correct OGC
standards template format. The approved document will be posted to the
OGC pubic web site sometime next week after a final proof read (posted
at http://www.opengeospatial.org/standards/bp). An OGC Best Practices
document is an official position of the OGC membership. As such, it can
be viewed as stable enough for implementation, vetted by the membership,
and in the correct format.

Regards

Carl Reed, PhD

---------------------

This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender  immediately by
return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein 
"Security is mostly a superstition. It does not exist in nature. Life is
either a daring adventure or nothing." -- Helen Keller 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Dec 2006 08:01:08 +0100

Hi Carl,

that was really fast. Thanks for pushing it forward!

Ciao
Hannes

Carl Reed OGC Account wrote:
> ------------------------------------------------------------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Dec 2006 20:10:29 +0100

Hi all,

I read through the two available drafts on this subject. I would like to 
hear something about the high-level strategy. What do we want to accomplish?

a) Allow a point (lat/long/alt) to be returned?
b) Allow a way to reduce the precision?
A rectangular prism would be returned but the Target is located 
somewhere within this
rectangular prism (random placement, not in the center).
c) Allow a way to offer uncertainty information? (see James/Martin draft)
d) Allow more complex shapes to be returned?
(e.g., a rectangular prism)

Everything is fine for me. Obviously the description is different for 
each time.

In some sense I would also be interested to learn what the main use 
cases for RFC 3825 are. I can see the civic version being more useful in 
a number of places. The use cases might actually give some hint about 
the required functionality.

Ciao
Hannes

PS: I would also remove the floor level way to specifying the altitude.

---

From: John Schnizlein <[email-masked]>
Date: Wed, 27 Dec 2006 16:09:14 -0500

The high-level strategy AFAICT is to proceed as indicated by the San 
Diego meeting
<http://www3.ietf.org/proceedings/06nov/minutes/geopriv.txt>.
There is no consensus that a revision of RFC 3825 is necessary.
You may have been surprised by the unsolicited -bis personal 
submission, as I was.

I have debugged the sample code in the geopriv-binary-lci draft, and 
added the explicit indication requested in San Diego that the appendix 
of RFC 3825 does not specify arbitrary region boundaries.  This WG 
draft should appear soon in the Internet-Draft repository.

As to what "we want to accomplish", the WG has been fairly clear that 
the interpretation of RFC 3825 as specifying regions with arbitrary 
boundaries should be clarified.  That is what the binary-lci draft 
does.  The purpose of RFC 3825 has not changed from its original intent 
to configure a host with its location (presumably on a wired network 
attachment).

Answers to your questions embedded in context:

On Dec 27, 2006, at 2:10 PM, Hannes Tschofenig wrote:

> Hi all,
>
> I read through the two available drafts on this subject. I would like 
> to hear something about the high-level strategy. What do we want to 
> accomplish?
>

It does just that.

> b) Allow a way to reduce the precision?

It does that through the ability to include a lower resolution than 
measured.

> rectangular prism (random placement, not in the center).

While interpretations of the implication of the resolution parameters 
as regions have been shown to be fraught with (unnecessary IMHO) 
controversy, these implications are explored in the appendix of RFC 
3825.

> c) Allow a way to offer uncertainty information? (see James/Martin 

My favorite definition of uncertainty is from Claude Shannon's 
Mathematical Theory of Communication
H = sum (p * log (p)) - the top of page 11 of
http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

Those who want background on the widely understood concept of 
uncertainty should review
http://en.wikipedia.org/wiki/Uncertainty

Significant figures (which RFC 3825 specifies) are mentioned there as a 
use of uncertainty in engineering.  Special interpretations from 
cellular telephone contexts are not applicable.

> d) Allow more complex shapes to be returned? (e.g., a rectangular 
> prism)

The purpose of RFC 3825 is to configure the location of a host, not a 
region of space. No good reason has been justified for changing this.  
As Henning has pointed out in the emergency-response case, determining 
which region of jurisdiction contains a point is difficult enough - 
determining which region a region is in is much more difficult.  Why 
add complexity that makes this life-and-death case more difficult?

> cases for RFC 3825 are. I can see the civic version being more useful 
> in a number of places. The use cases might actually give some hint 
> about the required functionality.
>
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Dec 2006 23:00:06 +0100

point + resolution is fine for me.  I will read closer into the 
resolution parameter story. More later.

H.

John Schnizlein wrote:
> does.  The purpose of RFC 3825 has not changed from its original 
> intent to configure a host with its location (presumably on a wired 
> network attachment).
>
> controversy, these implications are explored in the appendix of RFC 3825.
>
> Significant figures (which RFC 3825 specifies) are mentioned there as 
> a use of uncertainty in engineering.  Special interpretations from 
>> d) Allow more complex shapes to be returned? (e.g., a rectangular prism)
>