Geopriv WG James Polk Internet-Draft Allan Thomson Expires: September 25, 2009 Marc Linsner Intended Status: Standards Track (PS) Cisco Systems Updates: RFC 4119 (if published as an RFC) March 25, 2009 Defining a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO) draft-polk-geopriv-centerpoint-element-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 25, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Polk Expires September 25, 2009 [Page 1] Internet-Draft Geo Centerpoint March 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document creates a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Centerpoint Coordinate Element in PIDF-LO . . . . . . . . . . 4 3. Unit of Measurement Altitude Element in PIDF-LO . . . . . . . 5 4. Centerpoint Schema . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Introduction In the Presence Information Data Format - Location Object (PIDF-LO), as defined in RFC 4119 [RFC4119], location can currently be expressed in 2 forms, geo-coordinates and civic (i.e., country, state, county, street, landmark, etc - which is similar to postal addresses). Within the geo-coordinate realm, GML [OpenGIS] is the borrowed XML for expression of these coordinates. GML can describe dozens shapes as well as points/lines/arcs/etc in many ways. One shape in particular is a polygon. Polygons are quite useful representations of areas when using coordinates. A polygon is a Polk Expires September 25, 2009 [Page 2] Internet-Draft Geo Centerpoint March 2009 series of points connected by straight or arced lines, usually polygon is what GML calls a Linear Ring, in which the first coordinate point and the last coordinate point are the same. This effectively completes the circular pattern, indicating the machine or observer that the polygon is now closed, with no more additional points in the polygon. For example, there needs to be at least 4 points to express a polygon, which is 3 unique points and the 4th point, which is a repeat of the first point. point point B C +-------------------+ | | | | | | | | | | | | | | +-------------------+ A D point point Figure 1. Minimum Points in a Polygon In Figure 1., there are 4 points in this polygon, however, there needs to be 5 points in the linear ring, shown this way in XML (where each point is in a element. These are represented in a linear ring in this order: point A, point B, point C, point D, point A Something that GML does not express within a polygon is its calculated centerpoint, shown as point E in figure 2. Many applications that use location information may only represent location of an entity based on a point in space rather than the generally accepted view that location results are represented better as a polygon due to the errors and inaccuracies in determining the entity's location. Another aspect of concern is how location information is shown to the user of location applications. Some applications may provide location based on a textual representation rather than a graphical form. Therefore in textual applications showing the user a list of points that represent location can be unwieldy and unfriendly. Generally, the ability to represent the location of an entity using a single point is more useful than the more technically correct Polk Expires September 25, 2009 [Page 3] Internet-Draft Geo Centerpoint March 2009 polygon representation. For example, when drawing the position of an entity on a floorplan, the entity image will be drawn around the centerpoint of the polygon rather than the upper left corner of the polygon. By having the supplier of the location object, containing the polygon definition calculate the centerpoint, the recipient of the location information can avoid a possibly computationally intensive operation and potentially use the centerpoint directly in textual outputs. point point B C +-------------------+ | | | centerpoint | | E | | + | | | | | | | +-------------------+ A D point point Figure 2. A Polygon with a Centerpoint This document creates the centerpoint XML element . 2. Centerpoint Coordinate Element in PIDF-LO This document creates the XML element to indicate the centerpoint of a polygon. Polygons are not supported by the mandatory to implement schema contained within RFC 4119, only the feature.xsd is [RFC4119], shown here urn:opengis:specification:gml:schema-xsd:feature:v3.0 In order to support a polygon, the geometryPrimatives.xsd MUST be supported from GML3.1.1 or later, which is here urn:opengis:specification:gml:schema-xsd:geometryprimatives:v3.1.1 The European Petroleum Steering Group (EPSG) [Geoshape] provides the datum to be used in the urn in XML. Specifically, EPSG::4326 indicates the WGS84 datum in 2 dimensions, and EPSG::4979 indicates the WGS84 datum in 3 dimensions. An example urn for WGS84 in 2D is here Polk Expires September 25, 2009 [Page 4] Internet-Draft Geo Centerpoint March 2009 srsName="urn:ogc:def:crs:EPSG::4326" For 2D, here an example of the just the centerpoint contained within the element of a PIDF-LO. 32.6 -86.6 A more complete XML example for a 2D polygon with centerpoint is shown here 32.1 -86.1 32.1 -87.1 33.1 -87.1 33.1 -86.1 32.1 -86.1 32.6 -86.6 3. Unit of Measurement Altitude Element in PIDF-LO The unit of measurement for altitude of a centerpoint, if present is expressed in two ways, - either in the element as the 3rd number, where the X and Y coordinates are the first 2 numbers. The unit of measurement in this case MUST be in meters only. or - in the civic format as floors of a building . For 3D, here an example of altitude (Z-Coordinate) in meters: Polk Expires September 25, 2009 [Page 5] Internet-Draft Geo Centerpoint March 2009 32.6 -86.6 10 For 3D, here an example of altitude (Z-Coordinate) in civic floors: 32.6 -86.6 10 2 Caution SHOULD be used if this new centerpoint element has altitude included. If altitude is included in a centerpoint element, a much less complex scenario has either the centerpoint being the only element with an altitude, or the altitude in the centerpoint element is the same altitude as all the other points in the polygon (that include altitude). It is possible, configurations MAY want the centerpoint altitude to be the average (or mean) of all the points in the polygon, even when no points of the polygon are at that exact altitude. 4. Centerpoint Schema TBD 5. Security considerations The security considerations are the same as is in RFC 4119 [RFC4119]. 6. IANA considerations This document IANA registers the following... tbd 7. Acknowledgments Your name here... or if you contribute a fair amount of text, you can be a co-author. Polk Expires September 25, 2009 [Page 6] Internet-Draft Geo Centerpoint March 2009 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [OpenGIS] - http://www.opengeospatial.org/standards/gml [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation 8.2. Informative References There currently are no informative references within this document. Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Allan Thomson Cisco Systems, Inc. San Jose, California, USA Email: althomso@cisco.com Marc Linsner Cisco Systems, Inc. Marco Island, Florida, USA Email: mlinsner@cisco.com Polk Expires September 25, 2009 [Page 8]