GEOPRIV M. Thomson Internet-Draft Andrew Expires: November 20, 2006 May 19, 2006 Geodetic Shapes for the Representation of Uncertainty in PIDF-LO draft-thomson-geopriv-geo-shape-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 November 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a set of shapes for the representation of uncertainty for PIDF-LO geodetic location information. This includes a GML profile and a schema that defines additional geometries. Further recommendations are made to restrict the use of geographic Coordinate Reference Systems (CRS) and units of measure restrictions that improve interoperability. Thomson Expires November 20, 2006 [Page 1] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. About Location Information . . . . . . . . . . . . . . . . 5 3.1.1. Coordinate Reference Systems . . . . . . . . . . . . . 5 3.1.2. Uncertainty . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Confidence . . . . . . . . . . . . . . . . . . . . . . 6 4. General Information . . . . . . . . . . . . . . . . . . . . . 8 4.1. GML Version and Profile . . . . . . . . . . . . . . . . . 8 4.2. Coordinate Reference Systems . . . . . . . . . . . . . . . 8 4.3. Units of Measure . . . . . . . . . . . . . . . . . . . . . 8 4.4. Approximations . . . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Lines and Distances . . . . . . . . . . . . . . . . . 9 4.4.2. Planar Approximation . . . . . . . . . . . . . . . . . 10 5. Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Point . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Polygon Upward Normal . . . . . . . . . . . . . . . . 13 5.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . . . 18 5.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Application Schema . . . . . . . . . . . . . . . . . . . . . . 20 7. GML Profile Schema . . . . . . . . . . . . . . . . . . . . . . 23 7.1. geometryPrimitives.xsd . . . . . . . . . . . . . . . . . . 23 7.2. geometryBasic2d.xsd . . . . . . . . . . . . . . . . . . . 27 7.3. geometryBasic0d1d.xsd . . . . . . . . . . . . . . . . . . 29 7.4. measures.xsd . . . . . . . . . . . . . . . . . . . . . . . 32 7.5. gmlBase.xsd . . . . . . . . . . . . . . . . . . . . . . . 33 7.6. basicTypes.xsd . . . . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:geoShape . . . . . . 36 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 Appendix A. Calculating the Upward Normal of a Polygon . . . . . 41 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44 Thomson Expires November 20, 2006 [Page 2] Internet-Draft PIDF-LO Geodetic Shapes May 2006 1. Introduction This document defines how geodetic location information is specified in a PIDF-LO [RFC4119] document. PIDF-LO [RFC4119] specifies that the feature schema from version 3.0 of GML be supported by all implementations. However, this is not practical for a number of reasons. The feature schema, and the schema that it relies upon, includes a sizable proportion of the GML data types. This includes parts of the geometry and temporal schema that are rarely applicable in the domain where PIDF-LO is used. This means that implementations are required to support portions of the GML specification that are not and, in some cases, cannot be used. GML is structured to be used within an application schema. An application schema being a schema constructed for a particular application that both limits GML to what is applicable and provides application-specific types. PIDF-LO does not define such a schema. As a result this increases the complexity of implementation and decreases the usability of GML within PIDF-LO. If PIDF-LO is to be usable in the internet domain, it requires that such a schema is defined. This document defines an application schema and profile for using GML within PIDF-LO. This includes a small subset of GML geometry that is expanded by a new schema that defines additional geometries. These geometries, or shapes, are designed to provide a simple representation of shapes that are in common usage. In particular, these shapes are useful for the representation of uncertainty that arises from location determination technologies. A range of these shapes arise from wireless location technologies, and others are suited to geodetic representations of civic features, such as buildings and residental allotments. These shapes enable easy translation from location information in other document formats into the PIDF-LO form. This document also updates the PIDF-LO specification to state that the geometry specified in this document is the only requirement for geodetic shapes. Thomson Expires November 20, 2006 [Page 3] Internet-Draft PIDF-LO Geodetic Shapes May 2006 2. Conventions used in this document 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 [RFC2119]. This document uses geodesy and mathematics terminology. While this has been limited as far as is practical, some degree of familiarity with these disciplines and their terminology is helpful. In particular, terminology following the definitions in GML 3.1.1 [OGC.GML-3.1.1] is used. When referring to XML element, attribute and type definitions by name, this document uses namespace prefixes to distinguish between elements in different namespaces. The "gml:" prefix refers to elements from the "http://www.opengis.net/gml" namespace [OGC.GML- 3.1.1]; the "gs:" prefix refers to elements from the "urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" namespace. Thomson Expires November 20, 2006 [Page 4] Internet-Draft PIDF-LO Geodetic Shapes May 2006 3. Overview PIDF-LO serves as a document for the representation of Location Information (LI). This LI identifies the spatial location of a Target; the Target being a generic entity that is likely to be either a person or a Device. LI is a component of the Target's presence information. The LI that forms the core of a PIDF-LO document originates in the Location Generator (LG). Depending on the specific circumstances, particularly the type of access network, the LG can use any number of methods to determine LI. The range of technologies available for determining LI are numerous and range from user-provided LI, to automatic methods such as wire mapping, radio timing, and GPS. PIDF-LO is designed to be consumed in a wide range of applications. In some cases the information is presented to a user, maybe in a graphical representation, as a way of identifying the location of the Target. Other applications use LI as input to assist in providing a service. 3.1. About Location Information Two forms of LI are defined for use in PIDF-LO. Geodetic information consists of coordinates that identify a location in a particular coordinate reference system; and civic addresses [I-D.ietf-geopriv- revised-civic-lo] that identify a location based on civic norms (countries, cities, streets, etc...). This document is concerned with geodetic LI only. The remainder of this section introduces location concepts that affect how geodetic LI is represented and interpreted. 3.1.1. Coordinate Reference Systems A coordinate reference system (CRS) specifies how coordinates are interpreted. For the shapes defined in thie document, only the two- and three-dimensional WGS84 coordinate reference systems (latitude, longitude, and perhaps altitude) are mandatory, see Section 4.2. The shapes defined in this document assume one or both of these CRSs and may not be applicable to other coordinate reference systems. 3.1.2. Uncertainty Under ideal circumstances LI would describe a point in space unambiguously. However, in reality, location determination methods are imprecise for a variety of reasons. Thomson Expires November 20, 2006 [Page 5] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Uncertainty can be quantified in measurement in a number of ways, usually depending on the method that is used to determine LI. An area or volume is the most common way of representing uncertainty. For example, an ellipsoid is common for representing uncertainty in GPS measurements; polygons may be used when LI is converted from a civic address form; or a circle or ellipse is often used to describe the coverage area of a radio antenna. Even if location determination results in a single point, uncertainty may be specified as a distance from that point. This form of uncertainty indicates the furthest distance from the given point that the actual Target is expected to be located given certain sources of measurement error. This still effectively defines a circular area, or spherical volume, in which the Target could be located. This document assumes that any method for determining location is subject to uncertainty. The absence of uncertainty does not indicate that there is none, or that the measurement was infinitely precise; instead, the absence of uncertainty data indicates that the value of uncertainty could not be (or was not) provided. 3.1.3. Confidence Confidence is also used in some cases to express the innate variability of location determination. Variability in determining location cannot always be addressed by uncertainty. Confidence is a statistical measure indicating the probability that the given region of uncertainty actually covers the Target's actual location. Confidence is typically affected by variation in measurement parameters. However, confidence can also account for the chance of human error in the form of data entry errors or exceptional software faults. Likewise, confidence can cover the probability of intentional modification of LI (location fraud) beyond the capability of providers or protocol to prevent. The application of confidence is controversial. Location determination methods do not often directly provide this sort of information, and likewise many applications do not use the value in any way. In most cases the confidence cannot be used to make a decision. For instance, one such decision that uses confidence is whether or not the LI can be used; however, many applications rely on the assumption that any LI is better than none, so uncertainty is not considered. Because uncertainty is difficult to manage, this document does not include a parameter for conveying confidence. Individual applications MAY recommend a target level of confidence, but this Thomson Expires November 20, 2006 [Page 6] Internet-Draft PIDF-LO Geodetic Shapes May 2006 information is not included in the core geodetic shape formats. Thomson Expires November 20, 2006 [Page 7] Internet-Draft PIDF-LO Geodetic Shapes May 2006 4. General Information 4.1. GML Version and Profile This document is based on the version 3.1.1 schema of GML [OGC.GML- 3.1.1]. This version updates RFC 4119 [RFC4119]. This document restricts the required set of GML. A profile schema is included in Section 7. This profile follows the guidelines of [OGC.GML-3.1.1], it is a copy of the GML schema with portions removed. GML compliant implementations MAY use the full GML schema or the "geometryPrimitives.xsd" schema in place of this profile, as identified by "urn:opengis:specification:gml:schema-xsd:geometryPrimitives:3.1.1". The GML profile defined in Section 7 removes all unused parts of GML from the schema definition. In particular, this includes cross references using XLink [W3C.REC-xlink-20010627]. The "gml:id" attribute is retained so that geometry objects MAY still be the target of a reference. 4.2. Coordinate Reference Systems Implementations are REQUIRED to support the following coordinate reference systems based on WGS 84 [NIMA.TR8350.2-3e]. These are identified using the European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset, as formalized by the Open Geospatial Consortium (OGC): 3D: WGS 84 (latitude, longitude, altitude), as identified by the URN "urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS. 2D: WGS 84 (latitude, longitude), as identified by the URN "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. The most recent version of the EPSG Geodetic Parameter Dataset SHOULD be used. A CRS MUST be specified using the above URN notation only, implementations do not need to support user-defined CRSs. Implementations MUST specify the CRS using the "srsName" attribute on the outermost geometry element. The CRS MUST NOT be respecified or changed for any sub-elements. The "srsDimension" attribute SHOULD be omitted, since the number of dimensions in these CRSs is known. 4.3. Units of Measure GML permits a range of units of measure for all parameters. This document restricts this set to a single length unit and two angle Thomson Expires November 20, 2006 [Page 8] Internet-Draft PIDF-LO Geodetic Shapes May 2006 units. Length measures MUST be specified using metres, which is identified using the URN "urn:ogc:def:uom:EPSG::9001". Angular measures MUST use either degrees or radians. Measures in degrees MUST be identified by the URN "urn:ogc:def:uom:EPSG::9102". Measures in radians MUST be identified by the URN "urn:ogc:def:uom:EPSG::9101". The units of measure MUST be specified on the property element that contains the value. 4.4. Approximations The shapes provided in this document are primarily intended to represent areas of uncertainty. Uncertainty is a product of the inexact science of determining a location estimate. These estimates are subject to a range of errors. For these shapes, using approximations in processing this data does not significantly affect the quality of the data. Several approximation methods are described in this document that can be used to reduce the complexity of algorithms that use these shapes. Applications and algoritms that rely on this data SHOULD tolerate small errors that could arise from approximation. The guidance in this document on approximation techniques are not appropriate for shapes that cover large areas, or for applications where greater precision is required. Any guidance on approximations is appropriate to the application of these shapes to personal location, but might not be appropriate in other application domains. 4.4.1. Lines and Distances In this document, all lines and measurements are formed by straight lines. When joining two points, linear interpolation is used, that is, the shortest path in space rather than the path across the surface of the ellipsoid (geodesic interpolation). Likewise for distances, the distance is the length of the shortest path in space. Implementations MAY use geodesic interpolation between points and for distance measurement. A geodesic is a line that follows the surface of a geoid or ellipsoid, which in this context is usually the WGS 84 ellipsoid. Geodesic interpolation can produce a small difference from straight line interpolation. For use in uncertainty this error can be accepted, but it is RECOMMENDEDthat this variation is constrained to approximately 3% of the total distance. Thomson Expires November 20, 2006 [Page 9] Internet-Draft PIDF-LO Geodetic Shapes May 2006 For WGS84, the error between a geodesic and a straight line reaches 3% of the distance of the line at approximately 382km at the equator. This distance becomes approximately 131km in the East-West direction at 70 degrees latitude (North or South). Therefore, for the representation of uncertainty it is RECOMMENDED that the maximum distance between two points in a shape be less than 130km. Shapes that have an absolute latitude of more than 70 degrees SHOULD be smaller before any approximation is used. 4.4.2. Planar Approximation A common approximation used for geodesy applications treats the the surface of the ellipsoid as if it were a plane over a small area. This approximation is more intuitive and simplifies mathematical operations. Implementations MAY use this approximation method in interpreting the shapes in this document providing that the size of the shape is within the guidelines in Section 4.4.1. Thomson Expires November 20, 2006 [Page 10] Internet-Draft PIDF-LO Geodetic Shapes May 2006 5. Geometry This document defines a set of geometry that is appropriate for the encoding of the sorts of LI described in Section 3.1. This section describes how geometries can be represented using the application schema defined in Section 6. Pre-existing GML geometries, "gml:Point" and "gml:Polygon" are also described with examples. This section clarifies the usage of the zero dimensional Point (Section 5.1). The following two dimensional shapes are either clarified or defined: Polygon (Section 5.2), Circle (Section 5.3), Ellipse (Section 5.4) and Arc Band (Section 5.5). The following three dimensional shapes are defined: Sphere (Section 5.6), Ellipsoid (Section 5.7) and Prism (Section 5.8). A description of the Point, Circle, Ellipse, Sphere, Ellipsoid, Polygon and Arc Band, including descriptions of their parameters and explanatory diagrams, can be found in [3GPP.TS23032]. 5.1. Point The point shape type is the simplest form of geodetic LI, which is natively supported by GML. The "gml:Point" element is used when there is no known uncertainty. A point also forms part of a number of other geometries. A point MAY be specified using either WGS 84 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). This is shown in the following examples: -34.407 150.883 -34.407 150.883 24.8 5.2. Polygon A polygon uses the "gml:Polygon" element. A polygon is specified by a sequence of points. A polygon requires at least four points, where the first and last point MUST be the same. Points specified in a polygon MUST be coplanar. However, implementations SHOULD be prepared to accept small variations that Thomson Expires November 20, 2006 [Page 11] Internet-Draft PIDF-LO Geodetic Shapes May 2006 might occur depending on whether the the polygon is specified on a plane in space, or only relative to the ellipsoid. To avoid implementation complexity, implementations MAY choose to not support polygons that include varying altitude. Therefore, two polygon forms are permitted: polygons specified using EPSG 4326, and polygons specified using EPSG 4979 with a constant altitude value. Interpolation between points is linear, as defined for the "gml:LinearRing" element. Note that this interpolation is different for that specified in [3GPP.TS23032], which uses geodesic interpolation. Since geodesic interpolation is non-trivial to implement and some error is acceptable in both [3GPP.TS23032] and this document, implementations SHOULD minimize this error by ensuring that the sides of polygons are as short as possible. Note: [3GPP.TS23032] limits the number of unique points to 15 for a polygon. Therefore, if interoperability is required, polygons should not have more than 16 points in total. The following example shows a polygon that is specified using EPSG 4326 and the "gml:pos" element. No altitude is included in this example, indicating that altitude is unknown. 42.556844 -73.248157 42.549631 -73.237283 42.539087 -73.240328 42.535756 -73.254242 42.542969 -73.265115 42.553513 -73.262075 42.556844 -73.248157 Thomson Expires November 20, 2006 [Page 12] Internet-Draft PIDF-LO Geodetic Shapes May 2006 The following alternative example shows the same polygon with a constant altitude included that is specified using EPSG 4979 and the "gml:posList" element. 42.556844 -73.248157 36.6 42.549631 -73.237283 36.6 42.539087 -73.240328 36.6 42.535756 -73.254242 36.6 42.542969 -73.265115 36.6 42.553513 -73.262075 36.6 42.556844 -73.248157 36.6 The "gml:posList" element is interpreted as a list with the dimension of the CRS indicating how many values are required for each point. 5.2.1. Polygon Upward Normal The upward normal of a polygon determines the orientation of the surface. The upward normal of a polygon is important for the definition of the Prism (Section 5.8). [OGC.GML-3.1.1] describes the upward normal of a surface as a unit vector pointing to the side of the surface from which the exterior boundary appears counterclockwise. It is RECOMMENDED therefore that polygons are specified in a counterclockwise direction, so that their upward normal corresponds to an actual _up_. The upward normal can also be determined using the _Right Hand Rule_. Take your right hand and curl the fingers in the predominant direction that the polygon is defined; your thumb then points in the direction of the upward normal. Polygons with four or more unique points that are specified with constant altitude are unlikely to be perfectly coplanar. An approximate method for determining the upward normal of a polygon that is not guaranteed to be coplanar is described in Appendix A. Thomson Expires November 20, 2006 [Page 13] Internet-Draft PIDF-LO Geodetic Shapes May 2006 5.3. Circle The circular area is used for coordinates in two-dimensional CRSs to describe uncertainty about a point. The definition is based on the one-dimensional geometry in GML, "gml:CircleByCenterPoint". The centre point of a circular area MUST be specified using a two dimensional CRS; in three dimensions, the orientation of the circle cannot be specified correctly using this representation. A point with uncertainty that is specified in three dimensions SHOULD use the Sphere (Section 5.6) shape type. 42.5463 -73.2512 850.24 5.4. Ellipse An elliptical area describes an ellipse in two dimensional space. The ellipse is described by a center point, the length of its semi- major and semi-minor axes, and the orientation of the semi-major axis. Like the circular area (Section 5.3), the ellipse MUST be specified using a two dimensional CRS. 42.5463 -73.2512 1275 670 43.2 Thomson Expires November 20, 2006 [Page 14] Internet-Draft PIDF-LO Geodetic Shapes May 2006 The "gml:pos" element indicates the position of the center, or origin, of the ellipse. The "gs:semiMajorAxis" and "gs:semiMinorAxis" elements are the length of the semi-major and semi-minor axes respectively. The "gs:orientation" element is the angle by which the semi-major axis is rotated from the first axis of the CRS towards the second axis. For WGS 84, the orientation indicates rotation from Northing to Easting, which, if specified in degrees, is roughly equivalent to a compass bearing (if magnetic north were the same as the WGS north pole). Note: An ellipse with equal major and minor axes lengths is a circle. 5.5. Arc Band An arc band is a section of a circular area that is constrained to an arc between two radii. The arc band shape is most useful when radio timing technologies are used to determine location, based on a single wireless transmitter. These technologies provide a result that is a range from the transmitter, which might also be constrained in direction. An arc band is defined by the center point of the circle, an inner and outer radius, a start angle, and an opening angle. The following figure shows a sample arc band, with the center point "c", inner radius "r(i)", outer radius "r(o)", start angle "a(s)", and opening angle "a(o)" indicated. Thomson Expires November 20, 2006 [Page 15] Internet-Draft PIDF-LO Geodetic Shapes May 2006 N ^ ,.__ | / `-. | a(s) / `-. |--. / `. | `/ \ | /__ \ | . `-. \ | . `. \ |. \ \ . ---c-- a(o) -- | | --> |. / ' | E | . / ' | . / ; .,' / r(i)`. / `. / `. ,' `. ,' r(o)`' The center point, "gml:pos", MUST be specified in a two dimensional CRS. The inner radius, "gs:innerRadius", defines the minimum distance from the center point. The outer radius, "gs:outerRadius", defines the maximum distance from the center point. The start angle, "gs:startAngle", and opening angles, "gs:openingAngle", define where the arc begins and ends. The arc covers an arc the size of the opening (or included) angle that begins at the start (or offset) angle. Angles are measured clockwise from North (Northing to Easting). Thomson Expires November 20, 2006 [Page 16] Internet-Draft PIDF-LO Geodetic Shapes May 2006 The following example includes an arc band shape. This arc band starts at 266 degrees and has a 120 degree opening; therefore, the end of the band is at a 26 degree bearing. 42.5463 -73.2512 1661.55 2215.4 266 120 Note: An arc band with an inner radius of zero, and equal start and opening angles is a circle. 5.6. Sphere The sphere is a volume that provides the same information as a circle (Section 5.3) in three dimensions. The sphere MUST be specified using a three dimensional CRS. The following example shows a sphere shape, which is identical to the circle example, except for the addition of an altitude in the provided coordinates. 42.5463 -73.2512 26.3 850.24 Thomson Expires November 20, 2006 [Page 17] Internet-Draft PIDF-LO Geodetic Shapes May 2006 5.7. Ellipsoid The ellipsoid is a volume that is based on the ellipse (Section 5.4) shape, with the addition of a third dimension. A single value, vertical uncertainty, is added to the ellipse to form an ellipsoid. A full specification of an ellipsoid would include three angles in order to be able to orient the ellipsoid in three dimensions. This representation is limited to a single orientation angle, which is the same value that is used for the ellipse. This limits the major and minor axes of the base ellipse to a plane that is parallel to the surface of the WGS 84 ellipsoid at the given latitude and longitude. Implementations MAY also choose to place these axes on the surface of the WGS 84 ellipsoid. The difference between these two interpretations are not considered significant. The third length measurement, "gs:vertical", indicates the length of the third axis of the ellipsoid, which is a line that is always perpindicular to the surface of the WGS 84 ellipsoid, that is, it is vertical. This ellipsoid representation is similar to that described in [3GPP.TS23032]. The following example shows an ellipsoid. 42.5463 -73.2512 26.3 7.7156 3.31 28.7 142 Note: An ellipsoid with equal major, minor and vertical axes lengths is a sphere. Thomson Expires November 20, 2006 [Page 18] Internet-Draft PIDF-LO Geodetic Shapes May 2006 5.8. Prism The prism is a volume that is commonly used to represent a shape that has a constant cross section along one axis. For the purposes of PIDF-LO, a prism is most useful when representing a building, or single floor of a building. A prism is defined by its base, which is a two dimensional surface specified using a three dimensional CRS, and a height. The height is a scalar value that is projected in the direction of the upward normal of the base surface, see Section 5.2.1. It is strongly RECOMMENDED that the base shape for a prism is level, that is, it exists at the same altitude for all points. Implementations MAY reject prisms that have a base that is not at the same altitude. The following hexagonal prism might be used to represent a floor of a building in geodetic form. 42.556844 -73.248157 36.6 42.549631 -73.237283 36.6 42.539087 -73.240328 36.6 42.535756 -73.254242 36.6 42.542969 -73.265115 36.6 42.553513 -73.262075 36.6 42.556844 -73.248157 36.6 2.4 The Circle (Section 5.3) and Ellipse (Section 5.4) shapes do not have a defined upward normal, so they cannot be used as the base of a Prism. Thomson Expires November 20, 2006 [Page 19] Internet-Draft PIDF-LO Geodetic Shapes May 2006 6. Application Schema GEOPRIV Geodetic Shapes This document defines geodetic shape types for PIDF-LO. Thomson Expires November 20, 2006 [Page 20] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 21] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 22] Internet-Draft PIDF-LO Geodetic Shapes May 2006 7. GML Profile Schema This section defines a profile of GML that follows the recommendations in Section 22 of [OGC.GML-3.1.1]. The _copy and delete_ method has been employed to generate this schema. The profile includes abridged version of the files: "geometryPrimitives.xsd", "geometryBasic2d.xsd", "geometryBasic0d1d.xsd", "measures.xsd", "gmlBase.xsd", and "basicTypes.xsd". Note that "units.xsd" and "dictionary.xsd" are excluded from this profile. For the purposes of brevity, all comments and annotations from the original GML schema have been removed. Schematron [ISO.19757-3.2005] validation has also been removed. 7.1. geometryPrimitives.xsd The following file is the profile version of "geometryPrimitives.xsd". Thomson Expires November 20, 2006 [Page 23] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 24] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 25] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 26] Internet-Draft PIDF-LO Geodetic Shapes May 2006 7.2. geometryBasic2d.xsd The following file is the profile version of "geometryBasic2d.xsd". 7.3. geometryBasic0d1d.xsd The following file is the profile version of "geometryBasic0d1d.xsd". Thomson Expires November 20, 2006 [Page 29] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Thomson Expires November 20, 2006 [Page 30] Internet-Draft PIDF-LO Geodetic Shapes May 2006 7.4. measures.xsd The following file is the profile version of "measures.xsd". Thomson Expires November 20, 2006 [Page 32] Internet-Draft PIDF-LO Geodetic Shapes May 2006 7.5. gmlBase.xsd The following file is the profile version of "gmlBase.xsd". Thomson Expires November 20, 2006 [Page 33] Internet-Draft PIDF-LO Geodetic Shapes May 2006 7.6. basicTypes.xsd The following file is the profile version of "basicTypes.xsd". Thomson Expires November 20, 2006 [Page 34] Internet-Draft PIDF-LO Geodetic Shapes May 2006 8. Security Considerations It is believed that this document does not have any security considerations. If this information is included within a PIDF-LO document, the security considerations of [RFC4119] apply, especially those that are related to privacy. Thomson Expires November 20, 2006 [Page 35] Internet-Draft PIDF-LO Geodetic Shapes May 2006 9. IANA Considerations This section registers the application schema for geodetic shapes and its namespace with IANA. 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:geoShape This section registers a new XML namespace, "urn:ietf:params:xml:ns:pidf:geopriv10:geoShape", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:pidf:geopriv10:geoShape Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: BEGIN GEOPRIV GML Application Schema

Namespace for GEOPRIV GML Application Schema

urn:ietf:params:xml:ns:pidf:geopriv10:geoShape

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 9.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:pidf:geopriv10:geoShape Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). Thomson Expires November 20, 2006 [Page 36] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Schema: The XML for this schema can be found as the entirety of Section 6 of this document. Thomson Expires November 20, 2006 [Page 37] Internet-Draft PIDF-LO Geodetic Shapes May 2006 10. Acknowledgements The author would like to thank Carl Reed and Ron Lake of the OGC for their help in understanding geodesy and GML. The author would also like to thank Cullen Jennings for asking intelligent questions when noone else did. Thomson Expires November 20, 2006 [Page 38] Internet-Draft PIDF-LO Geodetic Shapes May 2006 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OpenGIS 03-105r1, April 2004, . 11.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [I-D.ietf-geopriv-revised-civic-lo] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in progress), April 2006. [W3C.REC-xlink-20010627] Maler, E., DeRose, S., and D. Orchard, "XML Linking Language (XLink) Version 1.0", W3C REC REC-xlink-20010627, June 2001. [NIMA.TR8350.2-3e] US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000. [EPSG.GN7-2] European Petroleum Survey Group, "Coordinate Conversions and Transforms including Formulas", EPSG Guidance Note 7, part 2 , November 2005, . [3GPP.TS23032] 3GPP, "Universal Geographical Area Description (GAD)", 3GPP TS 23.032 v6.0.0, December 2004. Thomson Expires November 20, 2006 [Page 39] Internet-Draft PIDF-LO Geodetic Shapes May 2006 [ISO.19757-3.2005] International Organization for Standardization and International Electrotechnical Commission, "Document Schema Definitions Languages (DSDL): Part 3 - Rule-based validation - Schematron", ISO/IEC FDIS 19757-3, 2005. [Sunday02] Sunday, D., "Fast polygon area and Newell normal computation.", Journal of Graphics Tools JGT, 7(2):9- 13,2002, 2002, . Thomson Expires November 20, 2006 [Page 40] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Appendix A. Calculating the Upward Normal of a Polygon For a polygon that is guaranteed to be convex and coplanar, the upward normal can be found by finding the vector cross product of adjacent edges. For more general cases the Newell method of approximation described in [Sunday02] may be applied. In particular, this method can be used if the points are only approximately coplanar, and for non-convex polygons. This method can be condensed to the following set of equations: Ux := sum from i=1..n of (y[i] * (z[i+1] - z[i-1])) Uy := sum from i=1..n of (z[i] * (x[i+1] - x[i-1])) Uz := sum from i=1..n of (x[i] * (y[i+1] - y[i-1])) For these formulae, the polygon is made of points (x[1], y[1], z[1]) through (x[n], y[n], x[n]). Each array is treated as circular, that is, x[0] = x[n] and x[n+1] = x[1]. Note: This method assumes a cartesian coordinate system, this SHOULD NOT be applied to coordinates specified in the WGS 84 (latitude, longitude, altitude) CRS. Coordinates specified in a geographic CRS SHOULD be transformed to a cartesian, geocentric CRS (such as EPSG 4978) before this method is applied, see [EPSG.GN7-2] and [NIMA.TR8350.2-3e] for details. Thomson Expires November 20, 2006 [Page 41] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Appendix B. Change Log [[The RFC Editor is requested to remove this section at publication.]] Changes since -00: o Removed 16 point limit on Polygons. o Resolved outstanding issues (no changes). Changes since -01: o Added more guidance on applicability. o Added more guidance on approximations methods and the limits to those methods. Thomson Expires November 20, 2006 [Page 42] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Author's Address Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ Thomson Expires November 20, 2006 [Page 43] Internet-Draft PIDF-LO Geodetic Shapes May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thomson Expires November 20, 2006 [Page 44]