one of Vienna's popular sights is the Karlskirche. Resolution of the URI returns the following information: o The 'crs' is given in the URI and sets the CRS used in the URI to WGS-84 explicitly. o The URI does omit , is hence 2-dimensional, and therefore uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier. o The value (latitude in WGS-84) is set to '48.198634' decimal degrees. o The value (longitude in WGS-84) is set to '16.371648' decimal degrees. o The (altitude) value is undefined; therefore, the client MAY assume the identified location to be on Earth's physical surface. o The 'u' parameter is included in the URI, setting uncertainty to 40 meters. A web browser could use this information from the HTML snippet, and offer the user various options (based on configuration, context), for example: Mayrhofer & Spanring Standards Track [Page 14] RFC 5870 'geo' URI Scheme June 2010 o Display a small map thumbnail when the mouse pointer hovers over the link. o Switch to a mapping service of the user's choice once the link is selected. o Locate nearby resources, for example by comparing the 'geo' URI with locations extracted from GeoRSS feeds to which the user has subscribed. o Convert the coordinates to a format suitable for uploading to a navigation device. Note that the URI in this example also makes use of the explicit specification of the CRS by using the 'crs' parameter. 6.3. 'geo' URI in 2-Dimensional Barcode Due to it's short length, a 'geo' URI could easily be encoded in 2-dimensional barcodes. Such barcodes could be printed on business cards, flyers, and paper maps, and subsequently used by mobile devices, for example as follows: 1. User identifies such a barcode on a flyer and uses the camera on his mobile phone to photograph and decode the barcode. 2. The mobile phone dereferences the 'geo' URI, and offers the user the ability to calculate a navigation route to the identified location. 3. Using the builtin GPS receiver, the user follows the navigation instructions to reach the location. 6.4. Comparison Examples This section provides examples of URI comparison. Note that the unknown parameters 'foo' and 'bar' and unregistered 'crs' values in this section are used for illustrative purposes only, and their inclusion in the examples below does not constitute any formal parameter definition or registration request. o The two URIs and are equal, because both use the same CRS, and even though the longitude values are different, both reflect a location on the north pole (special "poles" rule for WGS-84 applies - longitude is to be ignored). Note that the 'crs' parameter values are case insensitive. Mayrhofer & Spanring Standards Track [Page 15] RFC 5870 'geo' URI Scheme June 2010 o The URIs and are equal, because their coordinate components are mathematically identical. o The set of and are identical, because the value of the unknown parameter 'foo' is bitwise identical after percent- decoding; parameter names are case insensitive, and coordinates and uncertainty are mathematically identical. o The comparison operation on and in a legacy implementation is undefined, because the normalization rules for 'foo' are not known, and hence the implementation cannot identify whether or not '1.00' is identical to '1' for the 'foo' parameter. o Comparing and returns true, because parameter order is insignificant in comparison operations. o The comparison operation on and is undefined, because even though parameter names are case insensitive, this is not necessarily the case for the values of the unknown 'bar' parameter. 7. GML Mappings The Geographic Markup Language (GML) by the Open Geospatial Consortium (OGC) is a set of XML schemas that represent geographical features. Since GML is widely accepted, this document includes instructions on how to transform 'geo' URIs from and to GML fragments. The instructions in this section are not normative. For the following sections, "%lat%", "%lon%", "%alt%", and "%unc%" are placeholders for latitude, longitude, altitude, and uncertainty values, respectively. The mappings use WGS-84 and are defined in the following sections. Note: GML fragments in other reference systems could be used as well if a transformation into "urn:ogc:def:crs:EPSG::4979" or "urn:ogc:def:crs:EPSG::4326" is defined and applied before the mapping step. Such transformations are typically not lossless. GML uses the 'double' type from XML schema, and the mapping examples assume that numbers in the form of "3.32435e2" in GML are properly converted to fixed point when placed into the 'geo' URI. Mayrhofer & Spanring Standards Track [Page 16] RFC 5870 'geo' URI Scheme June 2010 7.1. 2D GML 'Point' A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has two coordinates and an uncertainty ('u') parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter. 'geo' URI: geo:%lat%,%lon% GML fragment: %lat% %lon% Note that a 'geo' URI with an uncertainty value of zero is converted to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' URI with zero uncertainty. 7.2. 3D GML 'Point' A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter. 'geo' URI: geo:%lat%,%lon%,%alt% GML fragment: %lat% %lon% %alt% 7.3. GML 'Circle' A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non- zero. Mayrhofer & Spanring Standards Track [Page 17] RFC 5870 'geo' URI Scheme June 2010 'geo' URI: geo:%lat%,%lon%;u=%unc% GML fragment: %lat% %lon% %unc% 7.4. GML 'Sphere' A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero. 'geo' URI: geo:%lat%,%lon%,%alt%;u=%unc% GML fragment: %lat% %lon% %alt% %unc% 8. IANA Considerations 8.1. 'geo' URI Scheme This document creates the 'geo' URI scheme in the IETF part of the URI scheme tree, according to the guidelines in BCP 115 (RFC 4395) [RFC4395]. The definitions required for the assignment are contained in Section 3. Mayrhofer & Spanring Standards Track [Page 18] RFC 5870 'geo' URI Scheme June 2010 8.2. URI Parameter Registry This document creates a new IANA Registry named "'geo' URI Parameters", according to the information in Section 4 and the definition in this section. 8.2.1. Registry Contents When registering a new 'geo' URI Parameter, the following information MUST be provided: o Name of the Parameter. o Whether the Parameter accepts no value ("No value"), values from a predefined set ("Predefined"), or values constrained by a syntax only ("Constrained"). o Reference to the RFC or other permanent and readily available public specification defining the parameters and the new values. Unless specific instructions exist for a Parameter (like the definition of a Sub-registry), the following information MUST be provided when registering new values for existing "Predefined" 'geo' URI Parameters: o Name of the Parameter. o Reference to the RFC or other permanent and readily available public specification defining the new values. The following table provides the initial values for this registry: Parameter Name Value Restriction Reference(s) ---------------------------------------------------------- crs Predefined [RFC5870] u Constrained [RFC5870] 8.2.2. Registration Policy The Registration Policy for 'geo' URI Parameters and their value definitions is "Specification Required" (which implies "Designated Expert"), as defined in [RFC5226]. Mayrhofer & Spanring Standards Track [Page 19] RFC 5870 'geo' URI Scheme June 2010 8.3. Sub-Registry for 'crs' Parameter This document creates a new IANA Sub-registry named "'geo' URI 'crs' Parameter Values", based on the Registry specified in Section 8.2 and the information in this section and Section 4. The syntax of the 'crs' parameter is constrained by the ABNF given in Section 3.3. 8.3.1. Registry Contents When registering a new value for the 'crs' parameter, the following information MUST be provided: o Value of the parameter. o Reference to the RFC or other permanent and readily available public specification defining the use of the CRS in the scope of the 'geo' URI. The specification should contain information that is similar to the WGS-84-specific text given in this document. o Reference to the definition document of the CRS. If a URN is assigned to the CRS, the use of such URN as reference is preferred. Note that different URNs may exist for the 2-dimensional and 3-dimensional case. The following table provides the initial values for this registry: crs Value CRS definition(s) Reference(s) ----------------------------------------------------------- wgs84 urn:ogc:def:crs:EPSG::4326 [RFC5870] urn:ogc:def:crs:EPSG::4979 [RFC5870] 8.3.2. Registration Policy The registration policy for the "'geo' URI 'crs' Parameter Values" Registry shall require both "Specification Required" and "IESG Approval", as defined in [RFC5226]. Section 1 contains some text about the motivation for when to introduce new 'crs' values. 9. Security Considerations Because the 'geo' URI is not tied to any specific protocol and identifies a physical location rather than a network resource, most of the general security considerations on URIs (Section 7 of RFC 3986) do not apply. However, the following (additional) issues apply: Mayrhofer & Spanring Standards Track [Page 20] RFC 5870 'geo' URI Scheme June 2010 9.1. Invalid Locations The URI syntax (Section 3.3) makes it possible to construct 'geo' URIs that don't identify a valid location. Applications MUST NOT use URIs with such values and SHOULD warn the user when such URIs are encountered. An example of such a URI referring to an invalid location would be (latitude "beyond" north pole). 9.2. Location Privacy A 'geo' URI by itself is just an opaque reference to a physical location, expressed by a set of spatial coordinates. This does not fit the "Location Information" definition according to Section 5.2 of GEOPRIV Requirements [RFC3693], because there is not necessarily a "Device" involved. Because there is also no way to specify the identity of a "Target" within the confines of a 'geo' URI, it also does not fit the specification of a "Location Object" (Section 5.2 of RFC 3693). However, if a 'geo' URI is used in a context where it identifies the location of a Target, it becomes part of a Location Object and is therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met. 10. Acknowledgements Martin Thomson has provided significant text around the definition of the "uncertainty" parameter and the GML mappings. The authors further wish to acknowledge the helpful contributions from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjoern Hoehrmann, Alissa Cooper, and Ivan Shmakov. Alfred Hoenes has provided an extremely helpful in-depth review of the document. Mayrhofer & Spanring Standards Track [Page 21] RFC 5870 'geo' URI Scheme June 2010 11. References 11.1. Normative References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. 11.2. Informative References [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [WGS84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Third Edition", NIMA TR8350.2, January 2000. [ISO.6709.2008] International Organization for Standardization, "Standard representation of geographic point location by coordinates", ISO Standard 6709, 2008. Mayrhofer & Spanring Standards Track [Page 22] RFC 5870 'geo' URI Scheme June 2010 Authors' Addresses Alexander Mayrhofer IPCom GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 34 Email: alexander.mayrhofer@ipcom.at URI: http://www.ipcom.at/ Christian Spanring 73 Josephine Ave Somerville 02144 Email: christian@spanring.eu URI: http://www.spanring.eu/ Mayrhofer & Spanring Standards Track [Page 23]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4