The geo-location object defined in this document and YANG module has been designed to be usable in a very broad set of applications. This includes the ability to locate things on astronomical bodies other than Earth, and to utilize entirely different coordinate systems and realities.
In order to verify portability while developing this module, the following standards and standard APIs were considered.
[
RFC 5870] defines a standard URI value for geographic location data. It includes the ability to specify the '
geodetic-value' (it calls this '
crs') with the default being '
wgs-84' [
WGS84]. For the location data, it allows two to three coordinates defined by the '
crs' value. For accuracy, it has a single '
u' parameter for specifying uncertainty. The '
u' value is in fractions of meters and applies to all the location values. As the URI is a string, all values are specified as strings and so are capable of as much precision as required.
URI values can be mapped to and from the YANG grouping with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than strings.
W3C defines a geolocation API in [
W3CGEO]. We show a snippet of code below that defines the geolocation data for this API. This is used by many applications (e.g., Google Maps API).
interface GeolocationPosition {
readonly attribute GeolocationCoordinates coords;
readonly attribute DOMTimeStamp timestamp;
};
interface GeolocationCoordinates {
readonly attribute double latitude;
readonly attribute double longitude;
readonly attribute double? altitude;
readonly attribute double accuracy;
readonly attribute double? altitudeAccuracy;
readonly attribute double? heading;
readonly attribute double? speed;
};
Field |
Type |
YANG |
Type |
accuracy |
double |
coord-accuracy |
dec64 fr 6 |
altitude |
double |
height |
dec64 fr 6 |
altitudeAccuracy |
double |
height-accuracy |
dec64 fr 6 |
heading |
double |
v-north, v-east |
dec64 fr 12 |
latitude |
double |
latitude |
dec64 fr 16 |
longitude |
double |
longitude |
dec64 fr 16 |
speed |
double |
v-north, v-east |
dec64 fr 12 |
timestamp |
DOMTimeStamp |
timestamp |
string |
Table 2
-
accuracy (double):
-
Accuracy of 'latitude' and 'longitude' values in meters.
-
altitude (double):
-
Optional height in meters above the [WGS84] ellipsoid.
-
altitudeAccuracy (double):
-
Optional accuracy of 'altitude' value in meters.
-
heading (double):
-
Optional direction in decimal degrees from true north increasing clockwise.
-
latitude, longitude (double):
-
Standard latitude/longitude values in decimal degrees.
-
speed (double):
-
Speed along the heading in meters per second.
-
timestamp (DOMTimeStamp):
-
Specifies milliseconds since the UNIX Epoch in a 64-bit unsigned integer. The YANG data model defines the timestamp with arbitrarily large precision by using a string that encompasses all representable values of this timestamp value.
W3C API values can be mapped to the YANG grouping with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than doubles.
Conversely, only YANG values for Earth using the default '
wgs-84' [
WGS84] as the '
geodetic-datum' can be directly mapped to the W3C values as W3C does not provide the extra features necessary to map the broader set of values supported by the YANG grouping.
ISO adopted the Geography Markup Language (GML) defined by OGC 07-036 [
OGC] as [
ISO.19136.2007]. GML defines, among many other things, a position type '
gml:pos', which is a sequence of '
double' values. This sequence of values represents coordinates in a given CRS. The CRS is either inherited from containing elements or directly specified as attributes '
srsName' and optionally '
srsDimension' on the '
gml:pos'.
GML defines an Abstract CRS type from which Concrete CRS types are derived. This allows for many types of CRS definitions. We are concerned with the Geodetic CRS type, which can have either ellipsoidal or Cartesian coordinates. We believe that other non-Earth-based CRSs as well as virtual CRSs should also be representable by the GML CRS types.
Thus, GML '
gml:pos' values can be mapped directly to the YANG grouping with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than doubles.
Conversely, mapping YANG grouping values to GML is fully supported for Earth-based geodetic systems.
GML also defines an observation value in '
gml:Observation', which includes a timestamp value '
gml:validTime' in addition to other components such as '
gml:using', '
gml:target', and '
gml:resultOf'. Only the timestamp is mappable to and from the YANG grouping. Furthermore, '
gml:validTime' can either be an instantaneous measure ('
gml:TimeInstant') or a time period ('
gml:TimePeriod'). The instantaneous '
gml:TimeInstant' is mappable to and from the YANG grouping '
timestamp' value, and values down to the resolution of seconds for '
gml:TimePeriod' can be mapped using the '
valid-until' node of the YANG grouping.
KML 2.2 [
KML22] (formerly Keyhole Markup Language) was submitted by Google to the
Open Geospatial Consortium and was adopted. The latest version as of this writing is KML 2.3 [
KML23]. This schema includes geographic location data in some of its objects (e.g., '
kml:Point' or '
kml:Camera' objects). This data is provided in string format and corresponds to the values specified in [
W3CGEO]. The timestamp value is also specified as a string as in our YANG grouping.
KML has some special handling for the height value that is useful for visualization software, '
kml:altitudeMode'. The values for '
kml:altitudeMode' include '
clampToGround', which indicates the height is ignored; '
relativeToGround', which indicates the height value is relative to the location's ground level; or '
absolute', which indicates the height value is an absolute value within the geodetic datum. The YANG grouping can directly map the ignored and absolute cases but not the relative-to-ground case.
In addition to the '
kml:altitudeMode', KML also defines two seafloor height values using '
kml:seaFloorAltitudeMode'. One value is to ignore the height value ('
clampToSeaFloor') and the other is relative ('
relativeToSeaFloor'). As with the '
kml:altitudeMode' value, the YANG grouping supports the ignore case but not the relative case.
The KML location values use a geodetic datum defined in Annex A of [
ISO.19136.2007] with identifier '
LonLat84_5773'. The altitude value for KML absolute height mode is measured from the vertical datum specified by [
WGS84].
Thus, the YANG grouping and KML values can be directly mapped in both directions (when using a supported altitude mode) with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than strings. For the relative height cases, the application doing the transformation is expected to have the data available to transform the relative height into an absolute height, which can then be expressed using the YANG grouping.