INTERNET-DRAFT Mari Korkea-aho Internet Engineering Task Force Haitao Tang Document: draft-korkea-aho-spatial-dataset-01.txt David Racz Expires: November 2001 Nokia James M. Polk Cisco Kenji Takahashi NTT May 2001 A Common Spatial Location Data Set < draft-korkea-aho-spatial-dataset-01.txt > Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This work proposes a common data set of expressing spatial location information in the Internet. The design aims at bridging various existing/proposed data representation formats, as well as meeting the requirements of existing/proposed location-aware applications/services. Contents 1. Introduction 2 2. Existing Spatial Location Expressions 2 3. Location Information Required by Services 3 4. Common Location Data Set 4 4.1 The Elements of the Data Set 4 4.2 Syntax of the Elements 6 4.3 Encoding of the Elements 8 4.3.1 XML DTD for the Data Set 8 4.3.2 XML Schema for the Data Set 8 Internet Draft A Common Spatial Location Data Set May 2001 4.4 An XML-encoded Location Example 10 5. Extendibility of the Data Set 11 6. Security Considerations 11 7. Acknowledgements 11 8. References 12 9. Author's Addresses 13 1. Introduction Currently many organizations are working on location-related technologies, and how to express and provide location information to services and applications in the Internet. Such organizations are IETF, OpenGIS, 3GPP, LIF, WAP Forum, W3C, etc. Each of them basically specifies its own way of providing and expressing location information to services and applications. This raises a serious problem - the various location information formats, services, and applications will not be interoperable in the Internet. Therefore, a common way of expressing location information for services and applications in the Internet is needed. One way of reaching interoperability is to have a common data set to express spatial location information with in the Internet. This draft proposes such a set. The design aims at bridging various existing/proposed data representation formats, as well as meeting the requirements of existing/proposed location-aware services. A more general framework enabling interoperability is presented in the draft "Spatial Location Payload" . The payload allows the combination of several location data sets. It enables e.g., the common spatial location data set to be extended with application specific elements, or to express the same location in different ways. 2. Existing Spatial Location Expressions There are many existing or proposed location expressions from a number of organizations (e.g. IETF, OpenGIS, 3GPP, LIF, WAP Forum, and W3C). Some of them are listed below: - Expression standardized for GSM and UMTS to be used internally in the mobile networks (called here "3GPP") [1] - An interface towards mobile networks in consideration by LIF [2] - The Geography Markup Language by the OpenGIS Consortium (GML) [3] - NaVigation Markup Language (NVML) [4] and Point Of Interest eXchange Language (POIX) [5] submitted to the W3C Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 2] Internet Draft A Common Spatial Location Data Set May 2001 - GeoTags for HTML resource discovery [6,7] - National Marine Electronics Association (NMEA) interface and protocol [8] often used by GPS receivers - VCard and ICalendar [9, 10, 11] include elements to specify position - A Means for Expressing Location Information in the Domain Name System(DNS-LOC) [12] - Proposed Simple Text Format for the Spatial Location Protocol (SLoP) [13] In brief most of the formats express location with latitude, longitude, using WGS84 as reference datum. GML, LIF, NAVML, and POIX also enable expressions using other coordinate systems and reference datum. Some allow altitude, if the data is available. In the location expressions, altitude usually means the height above WGS84 reference ellipsoid, while it is unclear in some cases. Most of the formats focus on the specification of the location of a point object, whereas others include also the expression of object shapes (3GPP, LIF, and GML). In DNS-LOC and NVML radial size of object can be defined. When the accuracy for estimating a location is defined, it is mostly expressed as horizontal and vertical error. Though, the 3GPP proposal includes more complex accuracy descriptions. LIF, POIX, NMEA, and 3GPP include also fields for velocity/speed. It is expressed as horizontal speed in all the cases except 3GPP. The 3GPP proposal defines horizontal velocity (horizontal speed + bearing) and vertical velocity (vertical speed + vertical direction). Direction of movement is also included in LIF, POIX, and NMEA, using true and/or magnetic North. POIX and NMEA include possibility to define the course as well. 3. Location Information Required by Services Many different types of location-aware services have been identified, e.g. information services (e.g. yellow pages, point-of-interest services), navigation & guidance, notifications (ads, traffic alerts, weather services, etc.), information memorizing & association, tracking & resource management, authorization, location specific resource management and discovery, location sensitive billing, network management. Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 3] Internet Draft A Common Spatial Location Data Set May 2001 It appears that most of the different services will primarily need absolute spatial location information as input. This is also the format that most existing location measurement systems can provide. Some of the services also need descriptive location such as addresses, regions, etc. This kind of information is generally created by manual input or via transformation services. Altitude and accuracy information will bring added value to services, but most of them can live without it. It is quite evident that in addition to location information it is important to attach the time of measurement to the location. This can be essential to the processing and management of location information. Other information that could bring added value to services include the orientation of the object, its moving direction, intended course, and speed. What about the size and shape of the object? This information could principally be used in two ways; firstly to describe the object which is positioned in order to determine what region it is covering (e.g. in finding, guidance, notification, tracking, authorization, resource discovery, billing and management services), secondly to indicate the region of interest or object to attach information to (finding information and information memorizing & association). Since most of the objects for positioning are of minor size (<10 m), the size and shape of an object usually do not have significance for the location of the object. It is also difficult to express shapes and sizes in an interoperable way. In fact, size and shape can be understood and specified as attributes associated to a location rather than location itself. 4. Common Location Data Set 4.1 The Elements of the Data Set The proposal of a common data set is based on identified elements important to applications, and on the available data from different devices and interfaces. Coordinates and Datum (mandatory) When reviewing the various existing interfaces and data representation formats, we find that most of them support coordinates expressed in latitude, longitude, and altitude (optional) using WGS- 84 datum. Thus we propose to use these in the common data set, where latitude and longitude would be mandatory. In order to keep the common data set simple, no other datum or coordinate systems are supported. We have chosen to enable the optional altitude to be expressed both as the WGS-84 reference ellipsoid and mean sea level as reference. Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 4] Internet Draft A Common Spatial Location Data Set May 2001 Location Accuracy (optional) Location accuracy is the estimation/measurement error of a location. The different interfaces include different types of accuracy information. We propose to include the most common way to express this, i.e. horizontal accuracy, by circle of radius from the positioned point, and height accuracy, by range from the positioned point. Time (mandatory) Time is the time of a measurement/fix of a location of an object. It is an important factor for location information. With the help of the time it is easier to manage location information and it enables different kinds of approximations. It is a mandatory element. Speed (optional) Speed is indicated as horizontal ground and vertical speed. This expression is chosen because many systems are able to indicate horizontal ground and vertical speed. Direction (optional) Direction indicates the direction of movement. It is expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North. Course (optional) Course indicates the direction from the current position to a defined destination. It is expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North. Orientation (optional) Orientation describes the orientation of the positioned object. Orientation is often given with a local coordinate system as reference. Since this reference frame can be different for different objects, it will be difficult to make a common expression based on this. One possibility would be to attach an object type indicating directly the used reference framework. Instead of such a solution, we propose a method where the orientation is expressed in a 2-dimensional (horizontal) frame indicated by the magnetic (or true) North, and a vertical element expressed by the angle between horizontal plane and the main axis of the object. Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 5] Internet Draft A Common Spatial Location Data Set May 2001 4.2 Syntax of the Elements Some of the existing data formats allow different optional ways to express the data elements and include syntax information. However, in order to keep processing as simple as possible we prefer only one single way of expression. The syntax of the elements in the common data set is as follows (For more details see ABNF notation in Appendix A and formatting details in Appendix B). Element Expression format Example Coordinates -Latitude [N|S]degree.minute.second.f, N60.08.00.235556 (mandatory) degree range [0-90], decimal fraction f in arbitrary length -Longitude [E|W]degree.minute.second.f, E25.00.00 (mandatory) degree range [0-180], decimal fraction f in arbitrary length -Altitude above [(+)|-]x.f meter from WGS-84 +12 datum reference ellipsoid, + above, (optional) - below, decimal fraction f in arbitrary length -Altitude above [(+)|-]x.f meter from mean sea, +10 mean sea level level, + above, - below, optional) decimal fraction f in arbitrary length Location Accuracy -Horizontal by circle of radius from the 50.0 accuracy positioned point in (+)x.f meter, (optional) decimal fraction f in arbitrary length -Altitude in (+)x.f meter, decimal 2.5 accuracy fraction f in arbitrary length (optional) Time [14, 15] Real time of the measurement/fix (mandatory) 1999-08-15T11:16:31.0+2:00 YYYY-MM-DDThh:mm:ss.sTZD, where YYYY = four-digit year MM = two-digit month (01=January, etc.) Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 6] Internet Draft A Common Spatial Location Data Set May 2001 DD = two-digit day of month (01-31) hh = two digits of hour (00-23) mm = two digits of minute (00-59) ss = two digits of second (00-59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) Speed - Ground speed (+)x.f [ms|kmh|mph|knot], 2.0 ms (optional) where default meter/second (ms), decimal fraction f in arbitrary length - Vertical speed (+)x.f [ms|kmh|mph|knot], 1.0 ms (optional) where default meter/second (ms), decimal fraction f in arbitrary length Direction magnetic/true direction, M240 (optional) 360 degrees from North clockwise [M|T][0-360].f degrees, where fractional degrees f in arbitrary length, M default Course magnetic/true direction, M30 (optional) 360 degrees from North clockwise [M|T][0-360].f degrees, where fractional degrees f in arbitrary length, M default Orientation - Horizontal magnetic/true direction, (optional) 360 degrees from North clockwise M240 [M|T][0-360].f, degrees, where fractional degrees f in arbitrary length, M default - Vertical (pitch) [(+)|-][0-180].f degrees, fractional 0 (optional) degrees f in arbitrary length Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 7] Internet Draft A Common Spatial Location Data Set May 2001 4.3 Encoding of the Elements The data elements can be encoded in many different ways, e.g., text based attribute-value pairs, binary, MIME, XML, etc. In order to enable interoperability, again, we need a common way of encoding the parameters. We propose XML. The advantages of XML are that the encoding is easily understandable, human readable, and standard tools and parsers can be used. In addition to this, many of the other proposals make use of XML. A possible disadvantage of using XML is that it is quite verbose. 4.3.1 XML DTD for the Data Set The XML DTD for the common data set is: 4.3.2 XML Schema for the Data Set XML Schemas provide a means for defining the structure, content and semantics of XML documents more precisely than the DTDs. With help of the XML Schema we can express the constraints on the different data elements better. Below is the XML-Schema for the common spatial location data set. Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 8] Internet Draft A Common Spatial Location Data Set May 2001 Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 9] Internet Draft A Common Spatial Location Data Set May 2001 4.4 An XML-encoded Location Example Here is an example of a location described using the common location data set and its XML Schema: N60.08.00.235556 E025.00.00 +12.99 010 50 2.5 Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 10] Internet Draft A Common Spatial Location Data Set May 2001 2.0 1 M240 M30 T25 179 5. Extendibility of the Data Set The common spatial location data set includes only a specific set of elements with clearly defined contents (The element "un-specified attributes" existing in the previous version was removed from the data set). In this manner we can keep the data set unambiguous and unique. This simplifies transformation and validation of the data set. XML Schema [16] provides general extension mechanisms with which SLO or elements of it can be incorporated in other data sets. However, in order to simplify transformation and processing of the different data sets, we recommend that application specific extensions should be defined as own data sets and attached to the common location data set as described in the draft "Spatial Location Payload" [17]. 6. Security Considerations Location alone usually means nothing but a "point" somewhere. However, when associated with a meaningful target such as a person, the location is potentially private or sensitive even though some parties may like to release their location information to the public. The authors believe that there must be security and policy mechanisms available to protect the information whenever needed. These issues are, however, out of the scope of the definition of a common location data set. We let the location-dealing applications or protocols define or select their own specific security mechanisms for authorization, authentication, encryption, key exchange, etc. 7. Acknowledgements The authors would like to thank all those who have provided comments to this document. Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 11] Internet Draft A Common Spatial Location Data Set May 2001 8. References [1] 3rd Generation Partnership Project, Technical Specification Group Core Network, Universal Geographical Area Description (GAD), Release 1999, Technical Specification, 3G TS 23.032 V3.1.0 (2000-03) [2] Definition of a Mobile Location Query API, Contribution to Location Inter-operability Forum (LIF), API Specification, v. 0.5, 18 Oct 2000 [3] Lake, R., Cuthbert, A. (eds.), Geography Markup Language (GML) v1.0, OGC Document Number: 00-029, 12-May-2000, http://www.opengis.org/techno/specs/00-029.pdf [4] Sekiguchi, et al., NaVigation Markup Language (NVML), W3C Note 6 Aug 1999,http://www.w3.org/TR/NVML [5] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest eXchange Language Specification, W3C Note - 24 June 1999, http://www.w3.org/TR/poix [6] Daviel, A., Geographic registration of HTML documents, , April 2000, http://geotags.com/geo/draft-daviel-html-geo-tag-03.txt [7] Daviel, A., Geographic extensions for HTTP transactions, , April 2000, http://geotags.com/geo/draft-daviel-http-geo-header-02.txt [8] Bennett P., The NMEA FAQ, version 6.3, April 25, 2000, http://vancouver-webpages.com/pub/peter/nmeafaq.txt [9] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", September 18, 1996, http://www.imc.org/pdi/vcard-21.txt [10] Dawson, F., Howes, T. , vCard MIME Directory Profile, IETF RFC 2426, September 1998, http://www.imc.org/rfc2426 [11] Dawson, F., Stenerson, D., Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC 2445, November 1998, http://www.imc.org/rfc2445 [12] Davis, C., Vixie, P., Goodwin, T., Dickinson, I., A Means for Expressing Location Information in the Domain Name System, IETF RFC 1876, January 1996, ftp://ftp.funet.fi/pub/doc/rfc/rfc1876.txt [13] Mahy, R., A Simple Text Format for the Spatial Location Protocol (SLoP), Internet draft, July 2000, Work in progress, Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 12] Internet Draft A Common Spatial Location Data Set May 2001 http://search.ietf.org/internet-drafts/draft-mahy-spatial- simple-coord-00.txt [14] Wolf, M., Wicksteed, C., W3C note, Date and Time Formats, 15 September 1997, http://www.w3.org/TR/1998/NOTE-datetime- 19980827 [15] Kuhn, M., A Summary of the International Standard Date and Time Notation, http://www.cl.cam.ac.uk/~mgk25/iso-time.html [16] Fallside, D. (Ed.), XML Schema Part 0: Primer, W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-0/ [17] Korkea-aho, M., Tang, H., Spatial Location Payload, , Internet draft, May 2001, Work in progress 9. Author's Addresses Mari Korkea-aho Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: mari.korkea-aho@iki.fi Haitao Tang Nokia Research Center P.O. BOX 407 FIN-00045 Nokia Group Finland Email: haitao.tang@nokia.com David L Racz Nokia Research Center 5 Wayside Road Burlington, MA 01803 USA Email: david.racz@nokia.com James Polk Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 USA Phone: +1 972.813.5208 Email: jmpolk@cisco.com Kenji Takahashi Information Sharing Platform Laboratories Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 13] Internet Draft A Common Spatial Location Data Set May 2001 NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 6668 Email: kt@nttlabs.com Appendix A Formal Syntax of the Common Data Set The syntax is specified with ABNF grammar (IETF RFC2234). ----------------------------------------------------------------- SLO = Coordinate Delimiter [Location_Accuracy Delimiter] Time Delimiter [Speed Delimiter] [Direction Delimiter] [Course Delimiter] [Orientation Delimiter] Delimiter = ; Delimiter depending on the coding Coordinate = Latitude Delimiter Longitude [Delimiter (Altitude_WGS84 | Altitude_Sea)] Latitude = ( "N" | "S" ) Degree90 "." Minute "." Second "." Fraction Degree90 = Minute = "00" - "60" Second = "00" - "60" Fraction = *Digit Digit = "0" - "9" Longitude = ( "E" | "W" ) Degree180 "." Minute "." Second "." Fraction Degree180 = Altitude_WGS84 = ( [ "+" ] | "-" ) Meter "." Fraction ; height in meter from WGS-84 reference ellipsoid Meter = *Digit Fraction = *Digit Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 14] Internet Draft A Common Spatial Location Data Set May 2001 Altitude_Sea = ( [ "+" ] | "-" ) Meter "." Fraction ; height in meter from mean sea level Location_Accuracy = [ Horizontal_Accuracy Delimiter] [ Height_Accuracy ] Horizontal_Accuracy = [ "+" ] Meter "." Fraction Height_Accuracy = [ "+" ] Meter "." Fraction Time = YYYY "-" MM "-" DD "T" hh ":" mm ":" ss "." s TZD YYYY = 4*4Digit MM = "01" - "12" DD = "01" - "31" hh = "00" - "23" mm = "00" - "59" ss = "00" - "59" s = *Digit TZD = "Z" | (( "+" | "-" ) hh:mm ) ; where Z means zero meridian Speed = [ Ground_speed [Delimiter Speed unit] Delimiter] [ Vertical_speed [Delimiter Speed unit]] Ground_speed = [ "+" ] *Digit "." *Digit Speed unit = ("ms" | "kmh" | "mph" | "knot") ; default: ms Vertical_speed = [ "+" ] *Digit "." *Digit Direction = Magnetic_direction | True_direction Magnetic_direction = [ "M" ] Degree360 "." Fraction Degree360 = True_direction = "T" Degree360 "." Fraction Course = Magnetic_direction | True_direction Orientation = Horizontal_orientation | Vertical_orientation Horizontal_orientation = Magnetic_direction | True_direction Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 15] Internet Draft A Common Spatial Location Data Set May 2001 Vertical_orientation = ( [ "+" ] | "-" ) Degree180 "." Fraction ----------------------------------------------------------------- Appendix B Formatting Details for Common Spatial Data Set The table below shows the allowed prefixes for the different elements in the common spatial data set. The table shows also for which elements leading zeros are required. ------------------+--------------------+---------------- | Allowed prefixes | Leading Zero ------------------+--------------------+---------------- LAT degree | N|S | optional LONG degree | E|W | optional LAT/LONG minute | | required LAT/LONG second | | required ALT | [+]|- | optional ALT_MSL | [+]|- | optional H_ACC | [+] | optional V_ACC | [+] | optional G_SPEED | [+] | optional V_SPEED | [+] | optional DIR | M (default)|T | optional COURSE | M (default)|T | optional H_ORIENT | M (default)|T | optional V_ORIENT | [+]|- | optional ------------------+--------------------+---------------- ----------------------------------------------------------------- Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 16] Internet Draft A Common Spatial Location Data Set May 2001 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 17]