< draft-korkea-aho-spatial-dataset-00.txt   draft-korkea-aho-spatial-dataset-01.txt >
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 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 Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as 'work in progress.' or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This work proposes a common format and extensible framework of This work proposes a common data set of expressing spatial location
expressing location information in the Internet. The design aims at information in the Internet. The design aims at bridging various
bridging various existing/proposed data representation formats, as well existing/proposed data representation formats, as well as meeting the
as meeting the requirements of existing/proposed location-aware requirements of existing/proposed location-aware
applications/services. applications/services.
Contents Contents
1. Introduction 2 1. Introduction 2
2. Existing Spatial Location Expressions 2 2. Existing Spatial Location Expressions 2
3. Location Information Required by Services 3 3. Location Information Required by Services 3
4. Common Location Data Set 4 4. Common Location Data Set 4
4.1 Common Data Set 4 4.1 The Elements of the Data Set 4
4.2 Syntax of the Elements 5 4.2 Syntax of the Elements 6
4.3 Encoding of the Data Set 7 4.3 Encoding of the Elements 8
5. Extendible Framework 8 4.3.1 XML DTD for the Data Set 8
6. Security Considerations 9 4.3.2 XML Schema for the Data Set 8
7. Acknowledgements 10 4.4 An XML-encoded Location Example 10
8. Author's Addresses 10 5. Extendibility of the Data Set 11
9. References 10 6. Security Considerations 11
7. Acknowledgements 11
8. References 12
9. Author's Addresses 13
1. Introduction 1. Introduction
Currently many organizations are working on location-related Currently many organizations are working on location-related
technologies, and how to express and provide location information to technologies, and how to express and provide location information to
services and applications in the Internet. Such organizations are IETF, services and applications in the Internet. Such organizations are
OpenGIS, 3GPP, LIF, WAP Forum, W3C, etc. IETF, OpenGIS, 3GPP, LIF, WAP Forum, W3C, etc.
Each of them basically specifies its own way of providing and expressing Each of them basically specifies its own way of providing and
location information to services and applications. This raises a serious expressing location information to services and applications. This
problem - the various location information formats, services, and raises a serious problem - the various location information formats,
applications will not be interoperable in the Internet. Therefore, a services, and applications will not be interoperable in the Internet.
common extendible way of expressing and transferring location Therefore, a common way of expressing location information for
information for services and applications in the Internet is needed. services and applications in the Internet is needed.
This work thus proposes a common format and extensible framework of One way of reaching interoperability is to have a common data set to
expressing location information in the Internet. The design aims at express spatial location information with in the Internet. This draft
bridging various existing/proposed data representation formats, as well proposes such a set. The design aims at bridging various
as meeting the requirements of existing/proposed location-aware existing/proposed data representation formats, as well as meeting the
services. Security is one of the key issues to be considered with the requirements of existing/proposed location-aware services.
progress of the work.
A more general framework enabling interoperability is presented in
the draft "Spatial Location Payload" <draft-korkea-aho-spatial-
location-payload-00.txt>. 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 2. Existing Spatial Location Expressions
There are many existing or proposed location expressions from a number There are many existing or proposed location expressions from a
of organizations (e.g. IETF, OpenGIS, 3GPP, LIF, WAP Forum, and W3C). number of organizations (e.g. IETF, OpenGIS, 3GPP, LIF, WAP Forum,
Some of them are listed below: and W3C). Some of them are listed below:
- Expression standardized for GSM and UMTS to be used internally in the - Expression standardized for GSM and UMTS to be used internally in
mobile networks (called here "3GPP") [1] the mobile networks (called here "3GPP") [1]
- An interface towards mobile networks in consideration by LIF [2] - An interface towards mobile networks in consideration by LIF [2]
- The Geography Markup Language by the OpenGIS Consortium (GML) [3] - The Geography Markup Language by the OpenGIS Consortium (GML) [3]
- NaVigation Markup Language (NVML) [4] and Point Of Interest eXchange - NaVigation Markup Language (NVML) [4] and Point Of Interest
Language (POIX) [5] submitted to the W3C eXchange Language (POIX) [5] submitted to the W3C
- GeoTags for HTML resource discovery [6,7]
- National Marine Electronics Association (NMEA) interface and protocol - GeoTags for HTML resource discovery [6,7]
[8] often used by GPS receivers
- VCard and ICalendar [9, 10, 11] include elements to specify position - National Marine Electronics Association (NMEA) interface and
protocol [8] often used by GPS receivers
- A Means for Expressing Location Information in the Domain Name System - VCard and ICalendar [9, 10, 11] include elements to specify
(DNS-LOC) [12] position
- Proposed Simple Text Format for the Spatial Location Protocol (SLoP) - A Means for Expressing Location Information in the Domain Name
[13] System(DNS-LOC) [12]
In brief most of the formats express location with latitude, longitude, - Proposed Simple Text Format for the Spatial Location Protocol
using WGS84 as reference datum. GML, LIF, NAVML, and POIX also enable (SLoP) [13]
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 In brief most of the formats express location with latitude,
point object, whereas others include also the expression of object longitude, using WGS84 as reference datum. GML, LIF, NAVML, and POIX
shapes (3GPP, LIF, and GML). In DNS-LOC and NVML radial size of object also enable expressions using other coordinate systems and reference
can be defined. 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.
When the accuracy for estimating a location is defined, it is mostly Most of the formats focus on the specification of the location of a
expressed as horizontal and vertical error. Though, the 3GPP proposal point object, whereas others include also the expression of object
includes more complex accuracy descriptions. shapes (3GPP, LIF, and GML). In DNS-LOC and NVML radial size of
object can be defined.
LIF, POIX, NMEA, and 3GPP include also fields for velocity/speed. It is When the accuracy for estimating a location is defined, it is mostly
expressed as horizontal speed in all the cases except 3GPP. The 3GPP expressed as horizontal and vertical error. Though, the 3GPP proposal
proposal defines horizontal velocity (horizontal speed + bearing) and includes more complex accuracy descriptions.
vertical velocity (vertical speed + vertical direction).
Direction of movement is also included in LIF, POIX, and NMEA, using LIF, POIX, NMEA, and 3GPP include also fields for velocity/speed. It
true and/or magnetic North. POIX and NMEA include possibility to define is expressed as horizontal speed in all the cases except 3GPP. The
the course as well. 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 3. Location Information Required by Services
Many different types of location-aware services have been identified, Many different types of location-aware services have been identified,
e.g. information services (e.g. yellow pages, point-of-interest e.g. information services (e.g. yellow pages, point-of-interest
services), navigation & guidance, notifications (ads, traffic alerts, services), navigation & guidance, notifications (ads, traffic alerts,
weather services, etc.), information memorizing & association, tracking weather services, etc.), information memorizing & association,
& resource management, authorization, location specific resource tracking & resource management, authorization, location specific
management and discovery, location sensitive billing, network resource management and discovery, location sensitive billing,
management. network management.
It appears that most of the different services will primarily need It appears that most of the different services will primarily need
absolute spatial location information as input. This is also the format absolute spatial location information as input. This is also the
that most existing location measurement systems can provide. Some of the format that most existing location measurement systems can provide.
services also need descriptive location such as addresses, regions, etc. Some of the services also need descriptive location such as
This kind of information is generally created by manual input or via addresses, regions, etc. This kind of information is generally
transformation services. created by manual input or via transformation services.
Altitude and accuracy information will bring added value to 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 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 addition to location information it is important to attach the time
measurement to the location. This can be essential to the processing and of measurement to the location. This can be essential to the
management of location information. Other information that could bring processing and management of location information. Other information
added value to services include the orientation of the object, its that could bring added value to services include the orientation of
moving direction, intended course, and speed. the object, its moving direction, intended course, and speed.
What about the size and shape of the object? This information could 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 principally be used in two ways; firstly to describe the object which
positioned in order to determine what region it is covering (e.g. in is positioned in order to determine what region it is covering (e.g.
finding, guidance, notification, tracking, authorization, resource in finding, guidance, notification, tracking, authorization, resource
discovery, billing and management services), secondly to indicate the discovery, billing and management services), secondly to indicate the
region of interest or object to attach information to (finding region of interest or object to attach information to (finding
information and information memorizing & association). Since most of the information and information memorizing & association). Since most of
objects for positioning are of minor size (<10 m), the size and shape of the objects for positioning are of minor size (<10 m), the size and
an object usually do not have significance for the location of the shape of an object usually do not have significance for the location
object. It is also difficult to express shapes and sizes in an 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 interoperable way. In fact, size and shape can be understood and
specified as attributes associated to a location rather than location specified as attributes associated to a location rather than location
itself. itself.
4. Common Location Data Set 4. Common Location Data Set
4.1 Common 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.
Co-ordinates and Datum (mandatory) 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.
When reviewing the various existing interfaces and data representation Coordinates and Datum (mandatory)
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) 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 is the estimation/measurement error of a location. The Location Accuracy (optional)
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) 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 is the time of a measurement/fix of a location of an object. It is Time (mandatory)
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) 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 is indicated as horizontal ground and vertical speed. This Speed (optional)
expression is chosen because many systems are able to indicate
horizontal ground and vertical speed.
Direction (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 indicates the direction of movement. It is expressed in a 2- Direction (optional)
dimensional (horizontal) frame indicated by the magnetic (or true)
North.
Course (optional) Direction indicates the direction of movement. It is expressed in a
2-dimensional (horizontal) frame indicated by the magnetic (or true)
North.
Course indicates the direction from the current position to a defined Course (optional)
destination. It is expressed in a 2-dimensional (horizontal) frame
indicated by the magnetic (or true) North.
Orientation (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 describes the orientation of the positioned object. Orientation (optional)
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) Orientation describes the orientation of the positioned object.
Orientation is often given with a local coordinate system as
reference.
An un-specified element is incorporated into the common set to include Since this reference frame can be different for different objects, it
some application specific elements. The attributes should be relevant will be difficult to make a common expression based on this. One
for location payload and not conflict with defined/existing attributes. possibility would be to attach an object type indicating directly the
This field should be used with consideration. 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.
4.2 Syntax of the Elements 4.2 Syntax of the Elements
Some of the existing data formats allow different optional ways to Some of the existing data formats allow different optional ways to
express the data elements and include syntax information. However, in express the data elements and include syntax information. However, in
order to keep processing as simple as possible we prefer only one single order to keep processing as simple as possible we prefer only one
way of expression. Here is the syntax of the elements in the common data single way of expression. The syntax of the elements in the common
set: data set is as follows (For more details see ABNF notation in
Appendix A and formatting details in Appendix B).
Element Expression format Example Element Expression format Example
Coordinates Coordinates
-Latitude [N/S]degree.minute.second, N60.08.00.235556 -Latitude [N|S]degree.minute.second.f, N60.08.00.235556
(mandatory) range [0-90], decimal fraction (mandatory) degree range [0-90], decimal
in arbitrary length fraction f in arbitrary length
-Longitude [E/W]degree.minute.second, E25.00.00 -Longitude [E|W]degree.minute.second.f, E25.00.00
(mandatory) range [0-180], decimal fraction (mandatory) degree range [0-180], decimal
in arbitrary length fraction f in arbitrary length
-Altitude above meter from WGS-84 reference +12 -Altitude above [(+)|-]x.f meter from WGS-84 +12
datum ellipsoid, + above, - below, datum reference ellipsoid, + above,
(optional) decimal fraction in arbitrary (optional) - below, decimal fraction f
length in arbitrary length
-Altitude above in meter, + above, - below, +10 -Altitude above [(+)|-]x.f meter from mean sea, +10
mean sea level decimal fraction in arbitrary mean sea level level, + above, - below,
(optional) length optional) decimal fraction f in arbitrary
length
Location Accuracy Location Accuracy
-Horizontal by circle of radius from the 50.0 -Horizontal by circle of radius from the 50.0
accuracy positioned point in meter, accuracy positioned point in (+)x.f meter,
(optional) decimal fraction in arbitrary (optional) decimal fraction f in arbitrary
length length
-Altitude in meter, decimal fraction in 2.5 -Altitude in (+)x.f meter, decimal 2.5
accuracy arbitrary length accuracy fraction f in arbitrary length
(optional) (optional)
Time [14, 15] Real time of the measurement/fix Time [14, 15] Real time of the measurement/fix
(mandatory) 1999-08-15T11:16:31.0 +2:00 (mandatory) 1999-08-15T11:16:31.0+2:00
YYYY-MM-DDThh:mm:ss.sTZD, where YYYY-MM-DDThh:mm:ss.sTZD, where
YYYY = four-digit year YYYY = four-digit year
MM = two-digit month (01=January, etc.) MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01-31) DD = two-digit day of month (01-31)
hh = two digits of hour (00-23) hh = two digits of hour (00-23)
mm = two digits of minute (00-59) mm = two digits of minute (00-59)
ss = two digits of second (00-59) ss = two digits of second (00-59)
s = one or more digits representing a decimal s = one or more digits representing a
fraction of a second decimal fraction of a second
TZD = time zone designator (Z or +hh:mm or -hh:mm) TZD = time zone designator
(Z or +hh:mm or -hh:mm)
Speed Speed
- Ground speed x.f [m/s | km/h | mph | knot ], 2.0 m/s - Ground speed (+)x.f [ms|kmh|mph|knot], 2.0 ms
(optional) where default meter/second or m/s, (optional) where default meter/second (ms),
f arbitrary decimal fractions decimal fraction f in arbitrary
- Vertical speed x.f [m/s | km/h | mph | knot ], 1.0 m/s length
(optional) where f arbitrary decimal fractions
Direction magnetic/true direction, - Vertical speed (+)x.f [ms|kmh|mph|knot], 1.0 ms
(optional) 360 degrees from North clockwise (optional) where default meter/second (ms),
decimal fraction f in arbitrary
length
[M | T] x.f, degrees and fractional M240 Direction magnetic/true direction, M240
degrees in arbitrary length, M default (optional) 360 degrees from North clockwise
Course magnetic/true direction, M30 [M|T][0-360].f degrees, where
(optional) 360 degrees from North clockwise fractional degrees f in arbitrary
length, M default
[M | T] x.f, degrees and fractional Course magnetic/true direction, M30
degrees in arbitrary length, M default (optional) 360 degrees from North clockwise
Orientation [M|T][0-360].f degrees, where
fractional degrees f in arbitrary
length, M default
- Horizontal magnetic/true direction, Orientation
(optional) 360 degrees from North clockwise M240
[M | T] x.f, degrees and fractional - Horizontal magnetic/true direction,
degrees in arbitrary length, M default (optional) 360 degrees from North clockwise M240
- Vertical (pitch) [+|-] [0-180].f degrees, fractional 0 [M|T][0-360].f, degrees, where
(optional) degrees in arbitrary length fractional degrees f in arbitrary
length, M default
Un-specified attribute: value, [value] car_orientation: - Vertical (pitch) [(+)|-][0-180].f degrees, fractional 0
Attributes 360,40,20 (optional) degrees f in arbitrary length
(optional)
4.3 Encoding of the Data Set 4.3 Encoding of the Elements
The data elements can be encoded in many different ways, e.g., text 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 based attribute-value pairs, binary, MIME, XML, etc. In order to
interoperability, again, we need a common way of encoding the enable interoperability, again, we need a common way of encoding the
parameters. We propose XML. The advantages of XML are that the encoding parameters. We propose XML. The advantages of XML are that the
is easily understandable, human readable, and standard tools and parsers encoding is easily understandable, human readable, and standard tools
can be used. In addition to this, many of the other proposals make use and parsers can be used. In addition to this, many of the other
of XML. A possible disadvantage of using XML is that it is quite proposals make use of XML. A possible disadvantage of using XML is
verbose. that it is quite verbose.
The XML.dtd for the common expression is: 4.3.1 XML DTD for the Data Set
<!-- slo_default.dtd --> The XML DTD for the common data set is:
<!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)>
<!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: <!-- slo_default.dtd -->
<!ELEMENT SLO (POS, ALT?, ALT_MSL?, H_ACC?, V_ACC?, TIME, G_SPEED?,
V_SPEED?, DIR?, COURSE?, H_ORIENT?, V_ORIENT?)>
<!ELEMENT POS (LAT, LONG)>
<!ELEMENT LAT (#PCDATA)>
<!ELEMENT LONG (#PCDATA)>
<!-- Altitude -->
<!ELEMENT ALT (#PCDATA)>
<!ELEMENT ALT_MSL (#PCDATA)>
<!-- Location Accuracy -->
<!ELEMENT H_ACC (#PCDATA)>
<!ELEMENT V_ACC (#PCDATA)>
<!-- Time -->
<!ELEMENT TIME (#PCDATA)>
<!-- Speed -->
<!ELEMENT G_SPEED (#PCDATA)>
<!ATTLIST G_SPEED unit (ms|kmh|mph|knot) "ms">
<!ELEMENT V_SPEED (#PCDATA)>
<!ATTLIST V_SPEED unit (ms|kmh|mph|knot) "ms">
<!-- Direction -->
<!ELEMENT DIR (#PCDATA)>
<!-- Course -->
<!ELEMENT COURSE (#PCDATA)>
<!-- Orientation -->
<!ELEMENT H_ORIENT (#PCDATA)>
<!ELEMENT V_ORIENT (#PCDATA)>
<?xml version="1.0" encoding="UTF-8"?> 4.3.2 XML Schema for the Data Set
<!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 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.
A framework enables to express the same location in different ways, or <?xml version="1.0"?>
add extensions to a certain expression. That is, the location expression <xsd:schema targetNamespace="http://www-nrc.nokia.com/ietf-
can be gathered by combining different location information modules. We spatial/2001/05/08/location" xmlns:this="http:// www-
propose an XML-based framework. nrc.nokia.com/ietf-spatial/2001/05/08/location"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="SLO" type="this:LocationData"/>
<xsd:complexType name="LocationData">
<xsd:sequence>
<xsd:element name="POS" type="this:POSType"/>
<xsd:element name="ALT" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="ALT_MSL" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="H_ACC" type="this:NonNegativeDecimal"
minOccurs="0"/>
<xsd:element name="V_ACC" type="this:NonNegativeDecimal"
minOccurs="0"/>
<xsd:element name="TIME" type="xsd:dateTime"/>
<xsd:element name="G_SPEED" type="this:Speed" minOccurs="0"/>
<xsd:element name="V_SPEED" type="this:Speed" minOccurs="0"/>
<xsd:element name="DIR" type="this:DegreesFromNorth"
minOccurs="0"/>
<xsd:element name="COURSE" type="this:DegreesFromNorth"
minOccurs="0"/>
<xsd:element name="H_ORIENT" type="this:DegreesFromNorth"
minOccurs="0"/>
<xsd:element name="V_ORIENT" type="this:PlusMinus180Decimal"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="POSType">
<xsd:sequence>
<xsd:element name="LAT" type="this:LATType"/>
<xsd:element name="LONG" type="this:LONGType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="LATType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(N|S)((\d|[0-8]\d)\.([0-5]\d)\.[0-
5]\d(\.\d+)?)|90\.00\.00(\.0+)?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LONGType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(E|W)((\d|\d\d|[0-1][0-7]\d)\.([0-
5]\d)\.[0-5]\d(\.\d+)?)|180\.00\.00(\.0+)?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DegreesFromNorth">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(M?|T)((\d|\d\d|[0-3][0-
5]\d)(\.\d+)?)|(360(\.0+)?)"/>
</xsd:restriction>
Since we assume that the XML-parser performs validation, the framework </xsd:simpleType>
needs to include the references to the dtds of the data subsets of the <xsd:simpleType name="PlusMinus180Decimal">
framework. We assume that the receiving party has the required dtds, <xsd:restriction base="xsd:decimal">
otherwise a URL pointing to the dtd should be available. One way of <xsd:minInclusive value="-180"/>
creating the framework is to create a LOC_FRAME document that <xsd:maxInclusive value="180"/>
incorporates the dtds of the different location representation modules. </xsd:restriction>
Below is an example, where the framework incorporates two subsets, the </xsd:simpleType>
"slo_default" subset and "my_loc" subset: <xsd:simpleType name="NonNegativeDecimal">
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SpeedUnit">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ms"/>
<xsd:enumeration value="kmh"/>
<xsd:enumeration value="mph"/>
<xsd:enumeration value="knot"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="Speed">
<xsd:simpleContent>
<xsd:extension base="this:NonNegativeDecimal">
<xsd:attribute name="unit" type="this:SpeedUnit"
default="ms"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>
<?xml version="1.0" encoding="UTF-8"?> 4.4 An XML-encoded Location Example
<!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 Here is an example of a location described using the common location
identifier of the document, or the XML-root element), it will be easier data set and its XML Schema:
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 <?xml version = "1.0" encoding = "UTF-8"?>
an external dtd (e.g. SLO_MY_LOC.dtd) and then reference the dtd in the <loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-
location representation document, in a similar manner as proposed in the spatial/2001/05/08/location"
XHTML modularization [17]. If used in combination with namespaces this xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
approach would allow interleaving of elements from the different xsi:schemaLocation="http://www-nrc.nokia.com/ietf-
location representation data sets. spatial/2001/05/08/location http://www-nrc.nokia.com/ietf-
spatial/2001/05/08/location.xsd">
<POS>
<LAT>N60.08.00.235556</LAT>
<LONG>E025.00.00</LONG>
</POS>
<ALT>+12.99</ALT>
<ALT_MSL>010</ALT_MSL>
<H_ACC>50</H_ACC>
<V_ACC>2.5</V_ACC>
<TIME>2001-01-01T12:00:01+02:00</TIME>
<G_SPEED>2.0</G_SPEED>
<V_SPEED unit="knot">1</V_SPEED>
<DIR>M240</DIR>
<COURSE>M30</COURSE>
<H_ORIENT>T25</H_ORIENT>
<V_ORIENT>179</V_ORIENT>
</loc:SLO>
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 6. Security Considerations
Location information is potentially private or sensitive even though Location alone usually means nothing but a "point" somewhere.
some parties (such as shops) like to release their location information However, when associated with a meaningful target such as a person,
to the public. The authors believe that location information should be the location is potentially private or sensitive even though some
delivered based on the policy set to the location information. In parties may like to release their location information to the public.
addition, certain security mechanisms should be used to protect the
location information, if required (as most of the cases). This should be The authors believe that there must be security and policy mechanisms
looked into more detail when defining the complete payload for available to protect the information whenever needed. These issues
transferring the location data. 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 7. Acknowledgements
The authors would like to thank all those who have provided comments to The authors would like to thank all those who have provided comments
this document. to this document.
8. Author's Addresses 8. References
Mari Korkea-aho [1] 3rd Generation Partnership Project, Technical Specification
Nokia Research Center Group Core Network, Universal Geographical Area Description
P.O. Box 407 (GAD), Release 1999, Technical Specification, 3G TS 23.032
FIN-00045 Nokia Group V3.1.0 (2000-03)
Finland
Email: mari.korkea-aho@nokia.com
Haitao Tang [2] Definition of a Mobile Location Query API, Contribution to
Nokia Research Center Location Inter-operability Forum (LIF), API Specification, v.
P.O. BOX 407 0.5, 18 Oct 2000
FIN-00045 Nokia Group
Finland
Email: haitao.tang@nokia.com
James Polk [3] Lake, R., Cuthbert, A. (eds.), Geography Markup Language
Cisco Systems (GML) v1.0, OGC Document Number: 00-029, 12-May-2000,
18581 N. Dallas Parkway http://www.opengis.org/techno/specs/00-029.pdf
Dallas, Texas 75287
Phone: +1 972.813.5208
Email: jmpolk@cisco.com
Kenji Takahashi [4] Sekiguchi, et al., NaVigation Markup Language (NVML), W3C
Information Sharing Platform Laboratories Note 6 Aug 1999,http://www.w3.org/TR/NVML
NTT
3-9-11 Midoricho
Musashino, Tokyo 180-8585 Japan
Phone: +81 422 59 6668
Email: kt@nttlabs.com
9. References [5] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest
eXchange Language Specification, W3C Note - 24 June 1999,
http://www.w3.org/TR/poix
[1] 3rd Generation Partnership Project, Technical Specification [6] Daviel, A., Geographic registration of HTML documents,
Group Core Network, Universal Geographical Area Description <draft-daviel-html-geo-tag-03.txt>, April 2000,
(GAD), Release 1999, Technical Specification, 3G TS 23.032 http://geotags.com/geo/draft-daviel-html-geo-tag-03.txt
V3.1.0 (2000-03)
[2] Definition of a Mobile Location Query API, Contribution to [7] Daviel, A., Geographic extensions for HTTP transactions,
Location Inter-operability Forum (LIF), API Specification, v. <draft-daviel-http-geo-header-02.txt>, April 2000,
0.5, 18 Oct 2000 http://geotags.com/geo/draft-daviel-http-geo-header-02.txt
[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 [8] Bennett P., The NMEA FAQ, version 6.3, April 25, 2000,
6 Aug 1999,http://www.w3.org/TR/NVML http://vancouver-webpages.com/pub/peter/nmeafaq.txt
[5] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest [9] Internet Mail Consortium, "vCard - The Electronic Business
eXchange Language Specification, W3C Note - 24 June 1999, Card Version 2.1", September 18, 1996,
http://www.w3.org/TR/poix http://www.imc.org/pdi/vcard-21.txt
[6] Daviel, A., Geographic registration of HTML documents, <draft- [10] Dawson, F., Howes, T. , vCard MIME Directory Profile, IETF
daviel-html-geo-tag-03.txt>, April 2000, RFC 2426, September 1998, http://www.imc.org/rfc2426
http://geotags.com/geo/draft-daviel-html-geo-tag-03.txt
[7] Daviel, A., Geographic extensions for HTTP transactions, [11] Dawson, F., Stenerson, D., Internet Calendaring and
<draft-daviel-http-geo-header-02.txt>, April 2000, Scheduling Core Object Specification (iCalendar), RFC 2445,
http://geotags.com/geo/draft-daviel-http-geo-header-02.txt November 1998, http://www.imc.org/rfc2445
[8] Bennett P., The NMEA FAQ, version 6.3, April 25, 2000, [12] Davis, C., Vixie, P., Goodwin, T., Dickinson, I., A Means for
http://vancouver-webpages.com/pub/peter/nmeafaq.txt Expressing Location Information in the Domain Name System,
IETF RFC 1876, January 1996,
ftp://ftp.funet.fi/pub/doc/rfc/rfc1876.txt
[9] Internet Mail Consortium, "vCard - The Electronic Business Card [13] Mahy, R., A Simple Text Format for the Spatial Location
Version 2.1", Protocol (SLoP), Internet draft, July 2000, Work in progress,
September 18, 1996, http://www.imc.org/pdi/vcard-21.txt http://search.ietf.org/internet-drafts/draft-mahy-spatial-
simple-coord-00.txt
[10] Dawson, F., Howes, T. , vCard MIME Directory Profile, IETF RFC [14] Wolf, M., Wicksteed, C., W3C note, Date and Time Formats, 15
2426, September 1998, http://www.imc.org/rfc2426 September 1997, http://www.w3.org/TR/1998/NOTE-datetime-
19980827
[11] Dawson, F., Stenerson, D., Internet Calendaring and Scheduling [15] Kuhn, M., A Summary of the International Standard Date and
Core Object Specification (iCalendar), RFC 2445, November 1998, Time Notation, http://www.cl.cam.ac.uk/~mgk25/iso-time.html
http://www.imc.org/rfc2445
[12] Davis, C., Vixie, P., Goodwin, T., Dickinson, I., A Means for [16] Fallside, D. (Ed.), XML Schema Part 0: Primer, W3C
Expressing Location Information in the Domain Name System, IETF Recommendation, May 2001, http://www.w3.org/TR/xmlschema-0/
RFC 1876, January 1996,
ftp://ftp.funet.fi/pub/doc/rfc/rfc1876.txt
[13] Mahy, R., A Simple Text Format for the Spatial Location [17] Korkea-aho, M., Tang, H., Spatial Location Payload, <draft
Protocol (SLoP), Internet draft, July 2000, -korkea-aho-spatial-location-payload-00.txt>, Internet draft,
http://search.ietf.org/internet-drafts/draft-mahy-spatial- May 2001, Work in progress
simple-coord-00.txt
[14] Wolf, M., Wicksteed, C., W3C note, Date and Time Formats, 15 9. Author's Addresses
September 1997, http://www.w3.org/TR/1998/NOTE-datetime-
19980827
[15] Kuhn, M., A Summary of the International Standard Date and Time Mari Korkea-aho
Notation, http://www.cl.cam.ac.uk/~mgk25/iso-time.html Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: mari.korkea-aho@iki.fi
[16] Bray et al., Namespaces in XML, World Wide Web Consortium 14 Haitao Tang
January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 Nokia Research Center
[17] Adams, et al., Modularization of XHTML, 20 October 2000, P.O. BOX 407
http://www.w3.org/TR/2000/CR-xhtml-modularization-20001020/ FIN-00045 Nokia Group
xhtml-modularization-20001020.html Finland
Email: haitao.tang@nokia.com
Copyright Statement David L Racz
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
USA
Email: david.racz@nokia.com
Copyright (C) The Internet Society (2000). All Rights Reserved. James Polk
Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
USA
Phone: +1 972.813.5208
Email: jmpolk@cisco.com
This document and translations of it may be copied and furnished to Kenji Takahashi
others, and derivative works that comment on or otherwise explain it or Information Sharing Platform Laboratories
assist in its implementation may be prepared, copied, published and NTT
distributed, in whole or in part, without restriction of any kind, 3-9-11 Midoricho
provided that the above copyright notice and this paragraph are included Musashino, Tokyo 180-8585 Japan
on all such copies and derivative works. However, this document itself Phone: +81 422 59 6668
may not be modified in any way, such as by removing the copyright notice Email: kt@nttlabs.com
or references to the Internet Society or other Internet organizations, Appendix A Formal Syntax of the Common Data Set
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet The syntax is specified with ABNF grammar (IETF RFC2234).
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 SLO = Coordinate Delimiter
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE [Location_Accuracy Delimiter]
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR Time Delimiter
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE [Speed Delimiter]
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED [Direction Delimiter]
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." [Course Delimiter]
[Orientation Delimiter]
Delimiter = <any delimiter string>
; Delimiter depending on the coding
Coordinate = Latitude Delimiter Longitude [Delimiter
(Altitude_WGS84 | Altitude_Sea)]
Latitude = ( "N" | "S" ) Degree90 "." Minute "." Second "." Fraction
Degree90 = <an integer in [0, 90], leading zero allowed>
Minute = "00" - "60"
Second = "00" - "60"
Fraction = *Digit
Digit = "0" - "9"
Longitude = ( "E" | "W" ) Degree180 "." Minute "." Second "."
Fraction
Degree180 = <an integer in [0, 180], leading zeros allowed>
Altitude_WGS84 = ( [ "+" ] | "-" ) Meter "." Fraction
; height in meter from WGS-84 reference ellipsoid
Meter = *Digit
Fraction = *Digit
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 = <an integer in [0, 360], leading zeros allowed>
True_direction = "T" Degree360 "." Fraction
Course = Magnetic_direction | True_direction
Orientation = Horizontal_orientation | Vertical_orientation
Horizontal_orientation = Magnetic_direction | True_direction
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
"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."
 End of changes. 109 change blocks. 
435 lines changed or deleted 516 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/