Geopriv WG James M. Polk
Internet Draft Cisco Systems
Document:
draft-polk-geopriv-location-data-00.txt Jorge Cuellar
Siemens AG
Expires: October 2002 June 2003
GEOPRIV Location Data Considerations
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 document describes the Geopriv Location Data Fields of the
Location Object that MUST be present under what conditions, which
fields SHOULD be present, and which MAY be present. This document
does not address the privacy and security requirements of the
GEOPRIV Protocol or the privacy and security requirements of the
GEOPRIV LO Using Protocol.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Polk/Cuellar Expires - December 2003 [Page 1]
GEOPRIV Location Data Considerations June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Location Data Objective . . . . . . . . . . . . . . . . . . . 3
3. Location Data . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Coordinate Location Data Type . . . . . . . . . . . . . . . . 4
4.1 Coordinate Location - Latitude (Lat) . . . . . . . . . . 5
4.1.1 Coordinate Location - Latitude Resolution (LaRes). . . . 5
4.2 Coordinate Location - Longitude (Long) . . . . . . . . . 6
4.2.1 Coordinate Location - Longitude Resolution (LoRes) . . . 6
4.3 Coordinate Location - Altitude (Alt) . . . . . . . . . . 7
4.3.1 Coordinate Location - Altitude Resolution (AltRes) . . . 7
4.3.2 Coordinate Location - Altitude Measurement Unit (MU) . . 7
4.4 Coordinate Location - Datum (Datum) . . . . . . . . . . 7
5. Civil Location Data Type . . . . . . . . . . . . . . . . . . 8
6. Independent Location Data Fields . . . . . . . . . . . . . . 8
6.1 Distance Fields . . . . . . . . . . . . . . . . . . . . . 8
6.2 Direction Fields . . . . . . . . . . . . . . . . . . . . 9
6.3 Speed Fields . . . . . . . . . . . . . . . . . . . . . . 9
6.4 Angle or Position Fields . . . . . . . . . . . . . . . . 9
6.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12. Author Information . . . . . . . . . . . . . . . . . . . . . 12
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12
1. Introduction
This document describes the Geopriv Location Data Fields of the
Location Object that MUST be present under what conditions, which
fields SHOULD be present, and which MAY be present. This document
does not address the privacy and security requirements of the
GEOPRIV Protocol or the privacy and security requirements of the
GEOPRIV LO Using Protocol described in [3], which is out of scope
here. The presented set or list of Location Data Fields is not all-
inclusive, but fields that are relevant to the WG at this time.
Location Data is to be defined in several ways within Geopriv in
regards to a Location Target - and should always be understood in
the context of a Geopriv Target (the entity device whose location is
sought). The Target might be associated with a person (Joe), or it
might be associated with a building (a particular pizza restaurant).
First is the data contained within a single field (i.e. Latitude or
cube number or velocity of the target). These fields are defined
Polk/Cuellar Expires - December 2003 [Page 2]
GEOPRIV Location Data Considerations June 2003
within this document and are categorized as: MUST be present in a
Location Object (LO), SHOULD be present in the LO, or MAY be present
in the LO. These fields are also characterized as being
individually independent (meaning a particular field can be present
independently of any other field being present - such as velocity);
while other fields are characterized as being dependent on another
present field for relevance (such as a Latitude field requiring a
Datum field for exactness of the position of a target with respect
to a meridian).
1.1 Motivation
This document attempts to open up discussion on the location fields
that can be carried within the Geopriv Location Object.
1.2 Definitions
Here is listed the Geopriv components as well as other significant
terms that are not defined and scoped from the (section below that
this document is about).
Meridian - An imaginary great circle on the earth's surface passing
through both the North and South geographic poles. All points on
the same meridian have the same longitude
Other definitions may be found in [3].
2. Location Data Objective
The objective of Location Data is to convey the location of the
Geopriv Target to another entity. The Target might, through policy,
alter the precision of resolution of the data provided, but should
not lie. Various reasons might be valid to reveal more or less
precise resolution to a location request from another entity. Those
reasons for the level of precision conveyed are left to the Target,
or the domain the Target is within (i.e. a matter of policy - which
is out of scope for this document).
3. Location Data
<<Comments: One possible way to group these fields even further is
to identify or name a Location Data Type for what MUST be present
(much the same way as packages work in the MGCP and H.248 worlds),
while allowing for additional individual Data fields to also be
present. Two Data Types would seem to be obvious: Coordinate
Location and Civil Location, with everything else being optional and
Polk/Cuellar Expires - December 2003 [Page 3]
GEOPRIV Location Data Considerations June 2003
considered a MAY.
A slightly confusing piece to all this classification is that while
the Coordinate Data Type is fairly easily scoped in [4] as being 8
identifiable fields, the Civil Data Type isn't so "set" as the
number of fields that should be present is dependent on where the
target is. Reference [5] provides around 14 fields that might be
present, of which not all are expected for several reasons. For
example, at my house, I would not include a precinct (location
within a city) or cube/office number or maybe not a floor number.
Yet people living in London or NYC (2 cities I know) would include a
precinct or borough field (Manhattan vs. Queens for example).>>
4. Coordinate Location Data Type
This Geopriv Location Data Type (LDT) represents location
information involving coordinate mapping systems. Some mapping
systems focus on a 2-dimensional location (two intersecting lines),
and others focus on a 3-dimensional location (three intersection
lines). Typically the 2D mapping system provides coordinates in
Latitude and Longitude. While 3D mapping systems add altitude to
latitude and longitude. From this we can conclude that a 2D
Coordinate Data Type MUST include Latitude, Longitude; while a 3D
Coordinate Data Type MUST add Altitude.
All mapping systems must start at some point of reference, called
the meridian (what is " 0 " on a map). The most common meridian used
throughout the world is Greenwich. Datums define the meridian to be
used. Unless otherwise stated, for Coordinate Data Types, the
starting point is Greenwich for Longitude, the Equator for Latitude,
and mean-low-tide for Altitude.
The scope of each coordinate field is explained in the following
subsections. Also provided is the mandatory list of dependant fields
that also must be present per location field, and the fields that
are related/optional. An example of this is Latitude. By itself, it
only provides the location of a line (just a longitude does). But
when Longitude is included with latitude, a point on the earth is
described. So in this sense, the longitude field is dependant on
latitude field being present to provide meaningful location
information. The reverse is true as well.
A related field to Lat and Long is Altitude. Altitude is not
mandatory to determine a point on a 2D map (it is for a 3D map),
therefore it is considered related, or optional.
An example of unrelated or independent location fields is Latitude
and slope. However useful slope might be in describing the Target,
these two fields are not dependant on each other to make an
Polk/Cuellar Expires - December 2003 [Page 4]
GEOPRIV Location Data Considerations June 2003
otherwise partial location field complete in 2D or 3D.
4.1 Coordinate Location - Latitude (Lat)
Latitude is defined as the angular distance north or south of the
earth's equator, measured in degrees along a meridian, as on a map
or globe; +90 degrees representing the North Pole; -90 degrees
representing the South Pole. Each degree can be fractionalized
indefinitely, though this is impractical. [4] scopes a reasonable
minimum fraction of a degree of Latitude to within 3.11mm or
0.0000002 of a degree. Values can be in either decimal format,
binary format, or hexadecimal format - there MUST be an indication
of which numbering format is used within the Location Data Type (of
the Location Object). This numbering format MUST be consistent with
the one used for Longitude.
Latitude field dependencies:
- having the Longitude field also present to provide a 2D point on a
map
- If the location Data Type requires a 3D point, then the Altitude
field must also be present
Related fields:
- Altitude to provide a third axis point of location reference
- Latitude Resolution field would provide the exactness of the value
given
One possibility when the exactness of latitude is known by the
responding Location Server (provided the exactness isn't
unnecessarily small), is to provide 2 latitude fields to give a
upper and lower boundary of where the target is with respect to
Latitude.
4.1.1 Coordinate Location - Latitude Resolution (LaRes)
In [4], there is described a location field Latitude Resolution.
This is provided as an efficient means of placing boundaries on a
Latitude field value in binary (see appendix A and B of that
document for a 2 mathematical examples of how this LaRes field
refines or reduces the boundaries in which a target is within).
This is not a straightforward in decimal or hexadecimal formats.
This subsection, therefore, needs more work.
Polk/Cuellar Expires - December 2003 [Page 5]
GEOPRIV Location Data Considerations June 2003
4.2 Coordinate Location - Longitude (Long)
Longitude is defined as Angular distance on the earth's surface,
measured east or west from the prime meridian of a given datum, to
the meridian passing through a position, expressed in degrees (and
fractions of a degree); 0 degrees representing the meridian;
positive degrees as traveling East, negative degrees as traveling
West; can be represented by +/-180 degrees bisecting the earth in
either direction away from the datum meridian. Each degree can be
fractionalized infinitely, though this is impractical. [4] scopes a
reasonable minimum fraction of a degree of Longitude to within
2.42mm or 0.0000004 of a degree. Values can be in either decimal
format, binary format, or hexadecimal format - there MUST be an
indication of which numbering format is used within the Location
Data Type (of the Location Object). This numbering format MUST be
consistent with the one used for Latitude.
Longitude field dependencies:
- having the Latitude field also present to provide a 2D point on a
map
- If the location Data Type requires a 3D point, then the Altitude
field must also be present
Related fields:
- Altitude to provide a third axis point of location reference
- Longitude Resolution field would provide the exactness of the
value given
One possibility when the exactness of Longitude is known by the
responding Location Server (provided the exactness isn't one point),
is to provide 2 longitude fields to give a left and right (West and
East) boundary of where the target is with respect to Longitude.
4.2.1 Coordinate Location - Longitude Resolution (LoRes)
In [4], there is described a location field Longitude Resolution.
This is provided as an efficient means of placing boundaries on a
Longitude field value in binary (see appendix A and B of that
document for a 2 mathematical examples of how this LaRes field
refines or reduces the boundaries in which a target is within).
This is not a straightforward in decimal or hexadecimal formats.
This subsection, therefore, needs more work.
Polk/Cuellar Expires - December 2003 [Page 6]
GEOPRIV Location Data Considerations June 2003
4.3 Coordinate Location - Altitude (Alt)
Altitude is defined as the space extended upward above a reference
level, especially above sea level or above the earth's surface;
height; the perpendicular elevation of an object above a given
level, above the ground; as, the altitude of a mountain, or of a
building. The base Altitude is considered Mean Low Tide, unless
otherwise stated in the definition of the field (building floors
being an example of an exception).
Direct field dependencies are:
- the Measurement Unit field to provide the necessary unit of length
(meters, building floors, kilometers, etc) for this field value to
read properly
Related fields:
- having the Longitude field and Latitude fields to provide a three
axis point of location reference
4.3.1 Coordinate Location - Altitude Resolution (AltRes)
This subsection needs more work.
4.3.2 Coordinate Location - Altitude Measurement Unit (MU)
This field is a dependant field for the Altitude Field that gives
the Altitude field value a unit of measurement (i.e. meters). The
units of measure that MUST be supported are: meters, building floors
(include the definition of mezzanines and sub-basements) and what
represents the surface of the earth (i.e. the ground) outside of
any structures.
MU field dependencies are:
- This field need not be present if the Altitude field is not
present. It provides no useful information by itself.
Related fields:
- none at this time
4.4 Coordinate Location - Datum (Datum)
The Map Datum used for the coordinates given (DHCP Option [TBD]
specifies 4 for Geopriv currently):
Polk/Cuellar Expires - December 2003 [Page 7]
GEOPRIV Location Data Considerations June 2003
1: WGS84 (Geographical 3D) - World Geodesic System 1984, CRS
Code 4327, Prime Meridian Name: Greenwich
2: ED50 - European Datum 1950(77), CRS Code 4154, Prime Meridian
Name: Greenwich
3: ED87 - European Datum 1987, CRS Code 4231, Prime Meridian
Name: Greenwich
4: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich
5. Civil Location Data Type
In [5] a Civil Location format is described. At this time, there are
a number of suggestions within that document that will need to be
further examined for incorporation within this document. This is not
a meant as anything other than the two sets of authors for this
document and the document at [5] need to collaborate more.
6. Independent Location Data Fields
The following section describes the data fields that are optional;
meaning they can be included in any order and in any combination
with other optional location data fields, as well as with either
Location Data Type (Coordinate or Civil). <<Comment: These optional
fields could also become part of a "packages" ID or IDs so that this
core doc (and the Geopriv protocol) isn't burdened by having to
adhere to too much at once.>>
<<Editorial Comment - this section is only partially completed>>.
6.1 Distance Fields
The fields in this subsection relate to distance to or from the
Target and another location (i.e. how far is the Target from the
pizza restaurant?).
Distance is defined as the length or numerical value of a known
measurement unit of a straight line or curve between two objects or
places. Potential Geopriv fields related to a Target that could be
created have the following descriptions (this is not a complete list
of reasonable fields for Distance)
- Distance to/from a known physical Object (i.e. a place)
Polk/Cuellar Expires - December 2003 [Page 8]
GEOPRIV Location Data Considerations June 2003
- Distance to/from another Geopriv Entity
- Direction towards that other Geopriv Entity
- Distance from a line
- as in how far away from a certain Lat or Long value
6.2 Direction Fields
The fields in this subsection relate to the direction the Target is
facing, turning or moving towards. Potential Geopriv fields related
to a Target that could be created have the following descriptions
(this is not a complete list of reasonable fields for Direction)
- Direction (of the LT)
- unit of measurement of direction (degrees or NSEW)
- indicator whether this direction is changing, and which way
- vector (of the target)
- Nautical Dead Reckoning
6.3 Speed Fields
The fields in this subsection relate to the speed/velocity the
Target is traveling or turning in any one direction. Potential
Geopriv fields related to a Target that could be created have the
following descriptions (this is not a complete list of reasonable
fields for speed/velocity).
Speed is defined at distance traveled divided by the time of travel.
- Speed/velocity (of the LT)
- unit of measurement of speed (mph, nmph, kmph, fps, mps, etc)
- indicator whether this speed is changing, and which way
- The rate at which the target is turning
6.4 Angle or Position Fields
The fields in this subsection relate to the angle/position the
Target is in any one time (perhaps to include if these values are
individually changing). Potential Geopriv fields related to a Target
Polk/Cuellar Expires - December 2003 [Page 9]
GEOPRIV Location Data Considerations June 2003
that could be created have the following descriptions (this is not
a complete list of reasonable fields for angle/position).
- Pitch
- with 0 degrees as the forward facing horizon, positive (0 to
+180) degrees and negative (-1 to -180) degrees elevation are
given within this field.
- To oscillate about a lateral axis so that the nose lifts or
descends in relation to the tail. Used of an aircraft.
- To oscillate about a lateral axis that is both perpendicular
to the longitudinal axis and horizontal to the earth. Used
of a missile or spacecraft.
- tilt
- To oscillate about a longitudinal axis so that the nose moves
laterally (left or right) in relation to the tail. Used of
an aircraft.
- To oscillate about a longitudinal axis that is both
perpendicular to the lateral axis and horizontal to the
earth. Used of a missile or spacecraft.
- yaw
- To turn about the vertical axis. Used of an aircraft,
spacecraft, or projectile.
- a deviation from a straight course in steering
- an erratic deflection from an intended course
- deviate erratically form a set course, as of a ship
- become deflected
6.5. Miscellaneous
- Temperature (of LT)
o-indicate if temp is changing, and which way
Polk/Cuellar Expires - December 2003 [Page 10]
GEOPRIV Location Data Considerations June 2003
7. Open Issues
- Timestamps of when the target was observed at a particular
location
- Timestamp of when the LO was sent or delivered
8. Security Considerations
The Security Considerations for this Location Data will be solved
within another document detailing how privacy and confidentiality
will be accomplished for the Location Data of a Target...
9. IANA Considerations
None within this document
10. Acknowledgements
None at this time
11. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Cuellar, J.R., Morris, J.B., Mulligan, D., Peterson, J., Polk,
J., Geopriv Requirements, work in progress, March 2003
[4] Schnizlein, J., Polk, J., Linsner, M., DHC Location Object
within GEOPRIV, work in progress, Jan 2003
[5] Schulzrinne, H., DHCP Option for Civil Location, work in
progress, Feb 2003
Polk/Cuellar Expires - December 2003 [Page 11]
GEOPRIV Location Data Considerations June 2003
12. Author Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA Email: jmpolk@cisco.com
Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich Email: jorge.cuellar@siemens.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Polk/Cuellar Expires - December 2003 [Page 12]