INTERNET-DRAFT Mari Korkea-aho Internet Engineering Task Force Haitao Tang Document: draft-korkea-aho-spatial-dataset-00.txt Nokia Expires: May 2001 James M. Polk Cisco Kenji Takahashi NTT Nov. 2000 A Common Spatial Location Dataset 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 format and extensible framework of expressing 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. Korkea-aho, Tang, Polk, and Takahashi [Page 1]
Internet Draft A Common Spatial Location Dataset Nov. 2000 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 Common Data Set 4 4.2 Syntax of the Elements 5 4.3 Encoding of the Data Set 7 5. Extendible Framework 8 6. Security Considerations 9 7. Acknowledgements 10 8. Author's Addresses 10 9. References 10 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 extendible way of expressing and transferring location information for services and applications in the Internet is needed. This work thus proposes a common format and extensible framework of expressing 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 services. Security is one of the key issues to be considered with the progress of the work. 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, Polk, and Takahashi [Page 2]
Internet Draft A Common Spatial Location Dataset Nov. 2000 - 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. 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 Korkea-aho, Tang, Polk, and Takahashi [Page 3]
Internet Draft A Common Spatial Location Dataset Nov. 2000 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 Common 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. Co-ordinates 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. 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. Korkea-aho, Tang, Polk, and Takahashi [Page 4]
Internet Draft A Common Spatial Location Dataset Nov. 2000 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. Un-specified Attributes (optional) An un-specified element is incorporated into the common set to include some application specific elements. The attributes should be relevant for location payload and not conflict with defined/existing attributes. This field should be used with consideration. 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. Here is the syntax of the elements in the common data set: Korkea-aho, Tang, Polk, and Takahashi [Page 5]
Internet Draft A Common Spatial Location Dataset Nov. 2000 Element Expression format Example Coordinates -Latitude [N/S]degree.minute.second, N60.08.00.235556 (mandatory) range [0-90], decimal fraction in arbitrary length -Longitude [E/W]degree.minute.second, E25.00.00 (mandatory) range [0-180], decimal fraction in arbitrary length -Altitude above meter from WGS-84 reference +12 datum ellipsoid, + above, - below, (optional) decimal fraction in arbitrary length -Altitude above in meter, + above, - below, +10 mean sea level decimal fraction in arbitrary (optional) length Location Accuracy -Horizontal by circle of radius from the 50.0 accuracy positioned point in meter, (optional) decimal fraction in arbitrary length -Altitude in meter, decimal fraction in 2.5 accuracy 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.) 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 [m/s | km/h | mph | knot ], 2.0 m/s (optional) where default meter/second or m/s, f arbitrary decimal fractions Korkea-aho, Tang, Polk, and Takahashi [Page 6]
Internet Draft A Common Spatial Location Dataset Nov. 2000 - Vertical speed x.f [m/s | km/h | mph | knot ], 1.0 m/s (optional) where f arbitrary decimal fractions Direction magnetic/true direction, (optional) 360 degrees from North clockwise [M | T] x.f, degrees and fractional M240 degrees in arbitrary length, M default Course magnetic/true direction, M30 (optional) 360 degrees from North clockwise [M | T] x.f, degrees and fractional degrees in arbitrary length, M default Orientation - Horizontal magnetic/true direction, (optional) 360 degrees from North clockwise M240 [M | T] x.f, degrees and fractional degrees in arbitrary length, M default - Vertical (pitch) [+|-] [0-180].f degrees, fractional 0 (optional) degrees in arbitrary length Un-specified attribute: value, [value] car_orientation: Attributes 360,40,20 (optional) 4.3 Encoding of the Data Set 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. The XML.dtd for the common expression is: <!-- slo_default.dtd --> <!ELEMENT SLO (POS, ALT, ALT_MSL, H_ACC, V_ACC, TIME, G_SPEED, V_SPEED, DIR, COURSE, H_ORIENT, V_ORIENT, X_ATTR)> <!ELEMENT POS (LAT, LONG)> <!ELEMENT LAT (#PCDATA)> <!ELEMENT LONG (#PCDATA)> <!ELEMENT ALT (#PCDATA)> <!ELEMENT ALT_MSL (#PCDATA)> Korkea-aho, Tang, Polk, and Takahashi [Page 7]
Internet Draft A Common Spatial Location Dataset Nov. 2000 <!ELEMENT H_ACC (#PCDATA)> <!ATTLIST H_ACC unit (ms|kmh|mph|knot) "ms"> <!ELEMENT V_ACC (#PCDATA)> <!ATTLIST V_ACC unit (ms|kmh|mph|knot) "ms"> <!ELEMENT TIME (#PCDATA)> <!ELEMENT G_SPEED (#PCDATA)> <!ELEMENT V_SPEED (#PCDATA)> <!ELEMENT DIR (#PCDATA)> <!ELEMENT COURSE (#PCDATA)> <!ELEMENT H_ORIENT (#PCDATA)> <!ELEMENT V_ORIENT (#PCDATA)> <!ELEMENT X_ATTR (PARAM)> <!ELEMENT PARAM (VALUE*)> <!ATTLIST PARAM name CDATA #REQUIRED> <!ELEMENT VALUE (#PCDATA)> An XML-encoded location example: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE IETF_SLO_Default PUBLIC "-//IETF//SLO default//EN" "slo_default.dtd"> <SLO> <POS> <LAT>N60.08.00.235556</LAT> <LONG> E025.00.00</LONG> </POS> <ALT>+12</ALT> <ALT_MSL>+10</ALT_MSL> <H_ACC>50.0</H_ACC> <V_ACC>2.5</V_ACC> <TIME>1999-08-15T11:16:31.0 +2:00</TIME> <G_SPEED unit=ms>2.0</G_SPEED> <V_SPEED unit=ms>1.0</V_SPEED> <DIR>M240</DIR> <COURSE>M30</COURSE> <H_ORIENT>M240</H_ORIENT> <V_ORIENT>0</V_ORIENT> <X_ATTR> <PARAM name="car_orientation"> <VALUE>360</VALUE> <VALUE>40</VALUE> <VALUE>20</VALUE> </PARAM> </X_ATTR> </SLO> 5. Extendible Framework A framework enables to express the same location in different ways, or add extensions to a certain expression. That is, the location expression can be gathered by combining different location information modules. We propose an XML-based framework. Korkea-aho, Tang, Polk, and Takahashi [Page 8]
Internet Draft A Common Spatial Location Dataset Nov. 2000 Since we assume that the XML-parser performs validation, the framework needs to include the references to the dtds of the data subsets of the framework. We assume that the receiving party has the required dtds, otherwise a URL pointing to the dtd should be available. One way of creating the framework is to create a LOC_FRAME document that incorporates the dtds of the different location representation modules. Below is an example, where the framework incorporates two subsets, the "slo_default" subset and "my_loc" subset: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE LOC_FRAME [ <!ENTITY % slo_default_dtd public PUBLIC "-//IETF//SLO_default//EN" "slo_default.dtd"> <!ENTITY % my_loc_dtd public PUBLIC "-//MY_LOC//My_Location//EN" "my_loc.dtd"> %slo_default_dtd; %my_loc_dtd; <!ELEMENT LOC_FRAME (SLO, MY_LOC)> ]> <LOC_FRAME> <SLO> ... </SLO> <MY_LOC> ... </MY_LOC> </LOC_FRAME> If each module is identified by an identifier (e.g. the system or public identifier of the document, or the XML-root element), it will be easier to identify the data set and to process and transform the data. In order to avoid conflicts in the structure document, the different data sets should include unique XML-elements. This could be achieved by using XML- namespaces [16]. Another option to be further studied is to include the different dtds in an external dtd (e.g. SLO_MY_LOC.dtd) and then reference the dtd in the location representation document, in a similar manner as proposed in the XHTML modularization [17]. If used in combination with namespaces this approach would allow interleaving of elements from the different location representation data sets. 6. Security Considerations Location information is potentially private or sensitive even though some parties (such as shops) like to release their location information to the public. The authors believe that location information should be delivered based on the policy set to the location information. In addition, certain security mechanisms should be used to protect the location information, if required (as most of the cases). This should be Korkea-aho, Tang, Polk, and Takahashi [Page 9]
Internet Draft A Common Spatial Location Dataset Nov. 2000 looked into more detail when defining the complete payload for transferring the location data. 7. Acknowledgements The authors would like to thank all those who have provided comments to this document. 8. Author's Addresses Mari Korkea-aho Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: mari.korkea-aho@nokia.com Haitao Tang Nokia Research Center P.O. BOX 407 FIN-00045 Nokia Group Finland Email: haitao.tang@nokia.com James Polk Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 Phone: +1 972.813.5208 Email: jmpolk@cisco.com Kenji Takahashi Information Sharing Platform Laboratories NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 6668 Email: kt@nttlabs.com 9. 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 Korkea-aho, Tang, Polk, and Takahashi [Page 10]
Internet Draft A Common Spatial Location Dataset Nov. 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, <draft- daviel-html-geo-tag-03.txt>, April 2000, http://geotags.com/geo/draft-daviel-html-geo-tag-03.txt [7] Daviel, A., Geographic extensions for HTTP transactions, <draft-daviel-http-geo-header-02.txt>, 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, 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] Bray et al., Namespaces in XML, World Wide Web Consortium 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 Korkea-aho, Tang, Polk, and Takahashi [Page 11]
Internet Draft A Common Spatial Location Dataset Nov. 2000 [17] Adams, et al., Modularization of XHTML, 20 October 2000, http://www.w3.org/TR/2000/CR-xhtml-modularization-20001020/ xhtml-modularization-20001020.html 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 "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, Polk, and Takahashi [Page 12]