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" <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
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:
<!-- 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)>
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
<?xml version="1.0"?>
<xsd:schema targetNamespace="http://www-nrc.nokia.com/ietf-
spatial/2001/05/08/location" xmlns:this="http:// www-
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>
Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 9]
Internet Draft A Common Spatial Location Data Set May 2001
</xsd:simpleType>
<xsd:simpleType name="PlusMinus180Decimal">
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="-180"/>
<xsd:maxInclusive value="180"/>
</xsd:restriction>
</xsd:simpleType>
<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>
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:
<?xml version = "1.0" encoding = "UTF-8"?>
<loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-
spatial/2001/05/08/location"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www-nrc.nokia.com/ietf-
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>
Korkea-aho, Tang, Racz, Polk, and Takahashi [Page 10]
Internet Draft A Common Spatial Location Data Set May 2001
<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
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,
<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, 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, <draft
-korkea-aho-spatial-location-payload-00.txt>, 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 = <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
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 = <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
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]