| RFC 9179 | A YANG Grouping for Geographic Locations | February 2022 |
| Hopps | Standards Track | [Page] |
This document defines a generic geographical location YANG grouping.The geographical location grouping is intended to be used in YANGdata models for specifying a location on or in reference to Earth or anyother astronomical object.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9179.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In many applications, we would like to specify the location of somethinggeographically. Some examples of locations in networking might be the locationof data centers, a rack in an Internet exchange point, a router, a firewall, aport on some device, or it could be the endpoints of a fiber, or perhaps thefailure point along a fiber.¶
Additionally, while this location is typically relative to Earth,it does not need to be. Indeed, it is easy to imagine a network ordevice located on the Moon, on Mars, on Enceladus (the moon ofSaturn), or even on a comet (e.g., 67p/churyumov-gerasimenko).¶
Finally, one can imagine defining locations using different framesof reference or even alternate systems (e.g., simulations orvirtual realities).¶
This document defines a 'geo-location' YANG grouping that allows forall the above data to be captured.¶
This specification conforms to[ISO.6709.2008].¶
The YANG data model described in this document conforms to theNetwork Management Datastore Architecture (NMDA) defined in[RFC8342].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The frame of reference ('reference-frame') defines what thelocation values refer to and their meaning. The referred-toobject can be any astronomical body. It could be a planet such asEarth or Mars, a moon such as Enceladus, an asteroid such asCeres, or even a comet such as 1P/Halley. This value is specifiedin 'astronomical-body' and is defined by theInternationalAstronomical Union. The default 'astronomical-body' value is'earth'.¶
In addition to identifying the astronomical body, we also need to definethe meaning of the coordinates (e.g., latitude and longitude) and thedefinition of 0-height. This is done with a 'geodetic-datum' value. Thedefault value for 'geodetic-datum' is 'wgs-84' (i.e., the WorldGeodetic System[WGS84]), which is used by the GlobalPositioning System (GPS) among many others. We define an IANA registry forspecifying standard values for the 'geodetic-datum'.¶
In addition to the 'geodetic-datum' value, we allow overriding thecoordinate and height accuracy using 'coord-accuracy' and'height-accuracy', respectively. When specified, these valuesoverride the defaults implied by the 'geodetic-datum' value.¶
Finally, we define an optional feature that allows for changing the systemfor which the above values are defined. This optional feature adds an'alternate-system' value to the reference frame. This value isnormally not present, which implies the natural universe is the system. The useof this value is intended to allow for creating virtual realities or perhapsalternate coordinate systems. The definition of alternate systems is outsidethe scope of this document.¶
This is the location on, or relative to, the astronomical object. It isspecified using two or three coordinate values. These values are given either as'latitude', 'longitude', and an optional 'height', or asCartesian coordinates of 'x', 'y', and 'z'. For thestandard location choice, 'latitude' and 'longitude' arespecified as decimal degrees, and the 'height' value is in fractions ofmeters. For the Cartesian choice, 'x', 'y', and 'z' arein fractions of meters. In both choices, the exact meanings of all the valuesare defined by the 'geodetic-datum' value inSection 2.1.¶
Support is added for objects in relatively stable motion. For objects inrelatively stable motion, the grouping provides a three-dimensional vectorvalue. The components of the vector are 'v-north', 'v-east', and'v-up', which are all given in fractional meters per second. The values'v-north' and 'v-east' are relative to true north as defined bythe reference frame for the astronomical body; 'v-up' is perpendicularto the plane defined by 'v-north' and 'v-east', and is pointedaway from the center of mass.¶
To derive the two-dimensional heading and speed, one would use thefollowing formulas:¶
,------------------------------ speed = V v_{north}^{2} + v_{east}^{2} heading = arctan(v_{east} / v_{north})¶For some applications that demand high accuracy and where the data isinfrequently updated, this velocity vector can track very slow movement suchas continental drift.¶
Tracking more complex forms of motion is outside the scope ofthis work. The intent of the grouping being defined here is toidentify where something is located, and generally this isexpected to be somewhere on, or relative to, Earth (or anotherastronomical body).At least two options are available to YANG data models that wish to use thisgrouping with objects that are changing location frequently in non-simpleways. A data model can either add additional motion data to its modeldirectly, or if the application allows, it can require more frequent queriesto keep the location data current.¶
When locations are nested (e.g., a building may have a location that housesrouters that also have locations), the module using this grouping is free toindicate in its definition that the 'reference-frame' is inherited fromthe containing object so that the 'reference-frame' need not berepeated in every instance of location data.¶
During the development of this module, the question of whether itwould support data such as orientation arose. These types ofattributes are outside the scope of this grouping because they donot deal with a location but rather describe something more aboutthe object that is at the location. Module authors are free toadd these non-location attributes along with their use of thislocation grouping.¶
The following is the YANG tree diagram[RFC8340] for thegeo-location grouping.¶
module: ietf-geo-location grouping geo-location: +-- geo-location +-- reference-frame | +-- alternate-system? string {alternate-systems}? | +-- astronomical-body? string | +-- geodetic-system | +-- geodetic-datum? string | +-- coord-accuracy? decimal64 | +-- height-accuracy? decimal64 +-- (location)? | +--:(ellipsoid) | | +-- latitude? decimal64 | | +-- longitude? decimal64 | | +-- height? decimal64 | +--:(cartesian) | +-- x? decimal64 | +-- y? decimal64 | +-- z? decimal64 +-- velocity | +-- v-north? decimal64 | +-- v-east? decimal64 | +-- v-up? decimal64 +-- timestamp? yang:date-and-time +-- valid-until? yang:date-and-time¶This model imports Common YANG Data Types[RFC6991]. It uses YANGversion 1.1[RFC7950].¶
<CODE BEGINS> file "ietf-geo-location@2022-02-11.yang"module ietf-geo-location { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-geo-location"; prefix geo; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } organization "IETF NETMOD Working Group (NETMOD)"; contact "WG Web: <https://datatracker.ietf.org/wg/netmod/> WG List: <mailto:netmod@ietf.org> Editor: Christian Hopps <mailto:chopps@chopps.org>"; description "This module defines a grouping of a container object for specifying a location on or around an astronomical object (e.g., 'earth'). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 9179 (https://www.rfc-editor.org/info/rfc9179); see the RFC itself for full legal notices."; revision 2022-02-11 { description "Initial Revision"; reference "RFC 9179: A YANG Grouping for Geographic Locations"; } feature alternate-systems { description "This feature means the device supports specifying locations using alternate systems for reference frames."; } grouping geo-location { description "Grouping to identify a location on an astronomical object."; container geo-location { description "A location on an astronomical body (e.g., 'earth') somewhere in a universe."; container reference-frame { description "The Frame of Reference for the location values."; leaf alternate-system { if-feature "alternate-systems"; type string; description "The system in which the astronomical body and geodetic-datum is defined. Normally, this value is not present and the system is the natural universe; however, when present, this value allows for specifying alternate systems (e.g., virtual realities). An alternate-system modifies the definition (but not the type) of the other values in the reference frame."; } leaf astronomical-body { type string { pattern '[ -@\[-\^_-~]*'; } default "earth"; description "An astronomical body as named by the International Astronomical Union (IAU) or according to the alternate system if specified. Examples include 'sun' (our star), 'earth' (our planet), 'moon' (our moon), 'enceladus' (a moon of Saturn), 'ceres' (an asteroid), and '67p/churyumov-gerasimenko (a comet). The ASCII value SHOULD have uppercase converted to lowercase and not include control characters (i.e., values 32..64, and 91..126). Any preceding 'the' in the name SHOULD NOT be included."; reference "https://www.iau.org/"; } container geodetic-system { description "The geodetic system of the location data."; leaf geodetic-datum { type string { pattern '[ -@\[-\^_-~]*'; } description "A geodetic-datum defining the meaning of latitude, longitude, and height. The default when the astronomical body is 'earth' is 'wgs-84', which is used by the Global Positioning System (GPS). The ASCII value SHOULD have uppercase converted to lowercase and not include control characters (i.e., values 32..64, and 91..126). The IANA registry further restricts the value by converting all spaces (' ') to dashes ('-'). The specification for the geodetic-datum indicates how accurately it models the astronomical body in question, both for the 'horizontal' latitude/longitude coordinates and for height coordinates."; reference "RFC 9179: A YANG Grouping for Geographic Locations, Section 6.1"; } leaf coord-accuracy { type decimal64 { fraction-digits 6; } description "The accuracy of the latitude/longitude pair for ellipsoidal coordinates, or the X, Y, and Z components for Cartesian coordinates. When coord-accuracy is specified, it indicates how precisely the coordinates in the associated list of locations have been determined with respect to the coordinate system defined by the geodetic-datum. For example, there might be uncertainty due to measurement error if an experimental measurement was made to determine each location."; } leaf height-accuracy { type decimal64 { fraction-digits 6; } units "meters"; description "The accuracy of the height value for ellipsoidal coordinates; this value is not used with Cartesian coordinates. When height-accuracy is specified, it indicates how precisely the heights in the associated list of locations have been determined with respect to the coordinate system defined by the geodetic-datum. For example, there might be uncertainty due to measurement error if an experimental measurement was made to determine each location."; } } } choice location { description "The location data either in latitude/longitude or Cartesian values"; case ellipsoid { leaf latitude { type decimal64 { fraction-digits 16; } units "decimal degrees"; description "The latitude value on the astronomical body. The definition and precision of this measurement is indicated by the reference-frame."; } leaf longitude { type decimal64 { fraction-digits 16; } units "decimal degrees"; description "The longitude value on the astronomical body. The definition and precision of this measurement is indicated by the reference-frame."; } leaf height { type decimal64 { fraction-digits 6; } units "meters"; description "Height from a reference 0 value. The precision and '0' value is defined by the reference-frame."; } } case cartesian { leaf x { type decimal64 { fraction-digits 6; } units "meters"; description "The X value as defined by the reference-frame."; } leaf y { type decimal64 { fraction-digits 6; } units "meters"; description "The Y value as defined by the reference-frame."; } leaf z { type decimal64 { fraction-digits 6; } units "meters"; description "The Z value as defined by the reference-frame."; } } } container velocity { description "If the object is in motion, the velocity vector describes this motion at the time given by the timestamp. For a formula to convert these values to speed and heading, see RFC 9179."; reference "RFC 9179: A YANG Grouping for Geographic Locations"; leaf v-north { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-north is the rate of change (i.e., speed) towards true north as defined by the geodetic-system."; } leaf v-east { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-east is the rate of change (i.e., speed) perpendicular to the right of true north as defined by the geodetic-system."; } leaf v-up { type decimal64 { fraction-digits 12; } units "meters per second"; description "v-up is the rate of change (i.e., speed) away from the center of mass."; } } leaf timestamp { type yang:date-and-time; description "Reference time when location was recorded."; } leaf valid-until { type yang:date-and-time; description "The timestamp for which this geo-location is valid until. If unspecified, the geo-location has no specific expiration time."; } } }}<CODE ENDS>¶[ISO.6709.2008] provides an appendix with a set of tests forconformance to the standard. The tests and results are given in thefollowing table along with an explanation of inapplicable tests.¶
| Test | Description | Pass Explanation |
|---|---|---|
| A.1.2.1 | elements required for a geographic point location | CRS is always indicated |
| A.1.2.2 | description of a CRS from a register | CRS register is defined |
| A.1.2.3 | definition of CRS | N/A - Don't define CRS |
| A.1.2.4 | representation of horizontal position | latitude/longitude values conform |
| A.1.2.5 | representation of vertical position | height value conforms |
| A.1.2.6 | text string representation | N/A - No string format |
For test 'A.1.2.1', the YANG geo-location object either includes aCoordinate Reference System (CRS) ('reference-frame') or has adefault defined[WGS84].¶
For 'A.1.2.3', we do not define our own CRS, and doing so is notrequired for conformance.¶
For 'A.1.2.6', we do not define a text string representation, which isalso not required for conformance.¶
The geo-location object defined in this document and YANG module hasbeen designed to be usable in a very broad set of applications.This includes the ability to locate things on astronomical bodiesother than Earth, and to utilize entirely different coordinatesystems and realities.¶
In order to verify portability while developing this module, thefollowing standards and standard APIs were considered.¶
[RFC5870] defines a standard URI value for geographiclocation 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 definedby the 'crs' value. For accuracy, it has a single 'u' parameterfor specifying uncertainty. The 'u' value is in fractions of meters andapplies to all the location values. As the URI is a string, all values arespecified as strings and so are capable of as much precision as required.¶
URI values can be mapped to and from the YANG grouping with thecaveat that some loss of precision (in the extremes) may occur due tothe YANG grouping using decimal64 values rather than strings.¶
W3C defines a geolocation API in[W3CGEO]. We show a snippet ofcode below that defines the geolocation data for this API. This isused 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 |
Accuracy of 'latitude' and'longitude' values in meters.¶
Optional accuracy of 'altitude' valuein meters.¶
Optional direction in decimal degrees from truenorth increasing clockwise.¶
Standard latitude/longitude values in decimal degrees.¶
Speed along the heading in meters per second.¶
Specifies milliseconds since the UNIXEpoch in a 64-bit unsigned integer. The YANG data model defines thetimestamp with arbitrarily large precision by using a stringthat encompasses all representable values of this timestampvalue.¶
W3C API values can be mapped to the YANG grouping with the caveatthat some loss of precision (in the extremes) may occur due to theYANG 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 mappedto the W3C values as W3C does not provide the extra features necessary to mapthe 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 positiontype 'gml:pos', which is a sequence of 'double' values. This sequenceof values represents coordinates in a given CRS. The CRS is eitherinherited from containing elements or directly specified asattributes '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 concernedwith the Geodetic CRS type, which can have either ellipsoidal orCartesian coordinates. We believe that other non-Earth-based CRSs aswell as virtual CRSs should also be representable by the GML CRS types.¶
Thus, GML 'gml:pos' values can be mapped directly to the YANGgrouping with the caveat that some loss of precision (in theextremes) may occur due to the YANG grouping using decimal64 valuesrather than doubles.¶
Conversely, mapping YANG grouping values to GML is fully supported forEarth-based geodetic systems.¶
GML also defines an observation value in 'gml:Observation', whichincludes a timestamp value 'gml:validTime' in addition to othercomponents such as 'gml:using', 'gml:target', and'gml:resultOf'. Only the timestamp is mappable to and from the YANGgrouping. Furthermore, 'gml:validTime' can either be an instantaneousmeasure ('gml:TimeInstant') or a time period('gml:TimePeriod'). The instantaneous 'gml:TimeInstant' ismappable to and from the YANG grouping 'timestamp' value, and valuesdown to the resolution of seconds for 'gml:TimePeriod' can be mappedusing the 'valid-until' node of the YANG grouping.¶
KML 2.2[KML22] (formerly Keyhole Markup Language) wassubmitted by Google to theOpenGeospatial Consortium and was adopted. The latest version as of thiswriting is KML 2.3[KML23]. This schema includes geographiclocation data in some of its objects (e.g., 'kml:Point' or'kml:Camera' objects). This data is provided in string format andcorresponds to the values specified in[W3CGEO]. The timestamp value is alsospecified as a string as in our YANG grouping.¶
KML has some special handling for the height value that is useful forvisualization software, 'kml:altitudeMode'.The values for 'kml:altitudeMode' include 'clampToGround', whichindicates the height is ignored; 'relativeToGround', which indicates theheight value is relative to the location's ground level; or 'absolute', whichindicates the height value is an absolute value within the geodetic datum.The YANG grouping can directly map the ignored andabsolute cases but not the relative-to-ground case.¶
In addition to the 'kml:altitudeMode', KML also defines two seafloorheight values using 'kml:seaFloorAltitudeMode'. One value is toignore the height value ('clampToSeaFloor') and the other is relative('relativeToSeaFloor'). As with the 'kml:altitudeMode' value, theYANG 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 heightmode is measured from the vertical datum specified by[WGS84].¶
Thus, the YANG grouping and KML values can be directly mapped in bothdirections (when using a supported altitude mode) with the caveatthat some loss of precision (in the extremes) may occur due to theYANG grouping using decimal64 values rather than strings. For therelative height cases, the application doing the transformation isexpected to have the data available to transform the relative heightinto an absolute height, which can then be expressed using the YANGgrouping.¶
IANA has created the "Geodetic System Values" registry underthe "YANG Geographic Location Parameters" registry.¶
This registry allocates names for standard geodetic systems. Often, thesevalues are referred to using multiple names (e.g., full names or multipleacronyms). The intent of this registry is to provide a single standard valuefor any given geodetic system.¶
The valuesSHOULD use an acronym when available, theyMUST be converted to lowercase, and spacesMUSTbe changed to dashes "-".¶
Each entry should be sufficient to define the two coordinate values and todefine height if height is required. So, for example, the 'wgs-84' isdefined as WGS-84 with the geoid updated by at least[EGM96]for height values. Specific entries for[EGM96] and[EGM08] are present if a more precise definition of the data isrequired.¶
It should be noted that[RFC5870] also created a registryfor geodetic systems (the "'geo' URI 'crs' Parameter Values" registry); however, this registry has a very strictmodification policy. The authors of[RFC5870] have the statedgoal of making CRS registration hard to avoid proliferation of CRS values. Asour module defines alternate systems and has a broader scope (i.e., beyond Earth),the registry defined below is meant to be more easily modified.¶
The allocation policy for this registry is First Come First Served[RFC8126], as the intent is simply to avoid duplicate values.¶
The Reference value can either be a document or a contact person asdefined in[RFC8126]. The Change Controller (i.e., Owner) is also definedby[RFC8126].¶
The initial values for this registry are as follows. They include thenon-Earth-based geodetic-datum value for the Moon based on[MEAN-EARTH].¶
| Name | Description | Reference | Change Controller |
|---|---|---|---|
| me | Mean Earth/Polar Axis (Moon) | RFC 9179 | IETF |
| wgs-84-96 | World Geodetic System 1984 | RFC 9179 | IETF |
| wgs-84-08 | World Geodetic System 1984 | RFC 9179 | IETF |
| wgs-84 | World Geodetic System 1984 | RFC 9179 | IETF |
This document registers a URI in the "IETF XML Registry"[RFC3688].Following the format in[RFC3688], the following registration has beenmade:¶
This document registers one YANG module in the "YANG Module Names"registry[RFC6020]. Following the format in[RFC6020], the followingregistration has been made:¶
The YANG module specified in this document defines a schema for data thatis designed to be accessed via network management protocols such as theNetwork Configuration Protocol (NETCONF)[RFC6241] or RESTCONF[RFC8040]. The lowest NETCONF layer is the secure transportlayer, and the mandatory-to-implement secure transport is Secure Shell (SSH)[RFC6242]. The lowest RESTCONF layer is HTTPS, and themandatory-to-implement secure transport is TLS[RFC8446].¶
The NETCONF access control model[RFC8341] provides the means torestrict access for particular NETCONF or RESTCONF users to apreconfigured subset of all available NETCONF or RESTCONF protocoloperations and content.¶
Since the modules defined in this document only define groupings,these considerations are primarily for the designers of other modulesthat use these groupings.¶
All the data nodes defined in this YANG module arewritable/creatable/deletable (i.e., "config true", which is thedefault).¶
None of the writable/creatable/deletable data nodes in the YANGmodule defined in this document are by themselves considered moresensitive or vulnerable than standard configuration.¶
Some of the readable data nodes in this YANG module may be consideredsensitive or vulnerable in some network environments. It is thusimportant to control read access (e.g., via get, get-config, ornotification) to these data nodes.¶
Since the grouping defined in this module identifies locations,authors using this groupingSHOULD consider any privacy issuesthat may arise when the data is readable (e.g., customer devicelocations, etc).¶
Below is a fictitious module that uses the geo-location grouping.¶
module example-uses-geo-location { namespace "urn:example:example-uses-geo-location"; prefix ugeo; import ietf-geo-location { prefix geo; } organization "Empty Org"; contact "Example Author <eauthor@example.com>"; description "Example use of geo-location"; revision 2022-02-11 { reference "None"; } container locatable-items { description "The container of locatable items"; list locatable-item { key name; description "A locatable item"; leaf name { type string; description "The name of locatable item"; } uses geo:geo-location; } }}Below is the YANG tree for the fictitious module that uses thegeo-location grouping.¶
module: example-uses-geo-location +--rw locatable-items +--rw locatable-item* [name] +--rw name string +--rw geo-location +--rw reference-frame | +--rw alternate-system? string | | {alternate-systems}? | +--rw astronomical-body? string | +--rw geodetic-system | +--rw geodetic-datum? string | +--rw coord-accuracy? decimal64 | +--rw height-accuracy? decimal64 +--rw (location)? | +--:(ellipsoid) | | +--rw latitude? decimal64 | | +--rw longitude? decimal64 | | +--rw height? decimal64 | +--:(cartesian) | +--rw x? decimal64 | +--rw y? decimal64 | +--rw z? decimal64 +--rw velocity | +--rw v-north? decimal64 | +--rw v-east? decimal64 | +--rw v-up? decimal64 +--rw timestamp? yang:date-and-time +--rw valid-until? yang:date-and-timeBelow is some example YANG XML data for the fictitious module thatuses the geo-location grouping.¶
<locatable-items xmlns="urn:example:example-uses-geo-location"> <locatable-item> <name>Gaetana's</name> <geo-location> <latitude>40.73297</latitude> <longitude>-74.007696</longitude> </geo-location> </locatable-item> <locatable-item> <name>Pont des Arts</name> <geo-location> <timestamp>2012-03-31T16:00:00Z</timestamp> <latitude>48.8583424</latitude> <longitude>2.3375084</longitude> <height>35</height> </geo-location> </locatable-item> <locatable-item> <name>Saint Louis Cathedral</name> <geo-location> <timestamp>2013-10-12T15:00:00-06:00</timestamp> <latitude>29.9579735</latitude> <longitude>-90.0637281</longitude> </geo-location> </locatable-item> <locatable-item> <name>Apollo 11 Landing Site</name> <geo-location> <timestamp>1969-07-21T02:56:15Z</timestamp> <reference-frame> <astronomical-body>moon</astronomical-body> <geodetic-system> <geodetic-datum>me</geodetic-datum> </geodetic-system> </reference-frame> <latitude>0.67409</latitude> <longitude>23.47298</longitude> </geo-location> </locatable-item> <locatable-item> <name>Reference Frame Only</name> <geo-location> <reference-frame> <astronomical-body>moon</astronomical-body> <geodetic-system> <geodetic-datum>me</geodetic-datum> </geodetic-system> </reference-frame> </geo-location> </locatable-item></locatable-items>
We would like to thankJim Biard andBen Koziol for their reviews and suggested improvements. We wouldalso like to thankPeter Lothberg for the motivation aswell as help in defining a broadly useful geographic location object as wellasAcee Lindem andQin Wu fortheir work on a geographic location object that led to this document'screation. We would also like to thank the Document ShepherdKent Watsen.¶