The Open GIS Consortium (OGC) has issued a public call for comment on a proposed OpenGIS Location Services (OpenLS) Implementation Specification. "The RFC defines XML for Location Services, which consists of interfaces for a variety of specific services. The primary objective of OpenLS is to define access to the Core Services and Abstract Data Types (ADT) that comprise the GeoMobility Server, an open location services platform. Abstract Data Type information (ADT) is the "basic information construct used by the GeoMobility Server and associated Core Services; it consists of well-known data types and structures for location information and is defined as application schemas that are encoded in XML for Location Services (XLS)." The OpenLS specification includes enhancements and fixes made by the work group following the OpenLS 1/1.1 testbed initiatives of October 2001 - October 2002; these testbed activities "attempted to define and build the core location application services and information framework necessary for interoperable use of mobile devices, services and location-related data." The release includes fifteen (15) supporting XML Schemas and prose specification in two parts. OpenLS: Core Services contains Parts 1-5. Core Services is also known as "the GeoMobility Server (GMS), an open platform for location-based application services. It also outlines the scope and relationship of OpenLS with respect to other specifications and standardization activities. Part 1 (Directory Service) is "a Yellow Pages used to find the nearest or a specific product or service; Part 2 (Gateway Service) fetches the position of a mobile device from the network; Part 3 (Location Utility Service) uses Geocoder/Reverse Geocoder, where Geocoder converts a location, such as a street address to a point with latitude/longitude and Reverse Geocoder transforms a given position into a description of a feature location, such as a street address; Part 4 (Presentation Service) implements map portrayal, and draws a map; Part 5 (Route Service) creates a travel route." OpenLS Part 6 Navigation Service was formerly the Full Profile of the Route Determination Service, which is part of the GeoMobility Server (GMS), an open location services platform. The Navigation Service is potentially not needed by all implementations. Annex A.1 of Core Services supplies a normative Schema (XML/S Profile), while Annex A.2 provides an informative SOAP Profile. The OpenLS implementation specification has been submitted to OGC by Autodesk, ESRI, Image Matters, Intergraph IntelliWhere, MapInfo, Navigation Technologies, Oracle, Sun Microsystems, and Webraska. Public comment is invited through May 19, 2003.

OpenLS Normative References and Relationship to Other Standards Activities

The OpenLS proposed specification references several other OGC and non-OGC specifications including: (1) OpenGIS Abstract Specification Topic 0: Overview; (2) Guidelines for Successful OGC Interface Specifications; (3) OpenGIS Geography Markup Language (GML), Version 3.0; (4) Recommended Definition Data for Coordinate Reference Systems and Coordinate Transformations; (5) OGC Units of Measure Use and Definition Recommendations; (6) OpenGIS Simple Features Specification for SQL, etc. "Other standards activities that were reviewed and considered under the OpenLS initiative include related standards initiatives at ISO, W3C, IETF, OMA/LIF, 3GPP, AMIC, MAGIC, WAP, JAIN and Parlay, as well as other emerging and adopted OGC specifications."

XLS Design Guidelines

XML for Location Services (XLS) "defines a method for encoding request/response messages and associated Abstract Data Types for the GeoMobility Server. The design guidelines considered for XLS are based on [WG] participants' experience in both the wireless community and with the OGC process. They constitute general design guidance toward achieving OpenLS objectives. The usage scenarios for XLS are captured in the use cases for the OpenLS Core Services (Section 3). Excerpts from the design guidelines:

• General Guidelines: (1) XLS should be simple and sufficient. This means that it should be able to adequately represent geographic objects for location services with minimum overhead and complexity (i.e., easy to encode and decode). As such, XLS must implement the Abstract Data Types for OpenLS. These types must be extensible. (2) XLS should have small footprint (compact for transmission to low powered mobile terminals with limited memory). (3) XLS should be developed such that it can be implemented in J2ME based platforms, and accessible by kDom and kXML APIs, with their current capabilities and maybe other wireless platforms that may emerge. (4) A single profile of XLS may be insufficient to deal with the variety of mobile devices. (For example, Mobile SVG will have two profiles: SVG-Basic and SVG-Tiny). Similarly, XLS may exist in two profiles that correspond to different classes of devices. In this case an appropriate capabilities discovery scheme should be devised to allow clients to discover which profiles are supported by the server. (5) Similar to GML, XLS should maintain the separation between location information content and presentation. XLS can be directly rendered on the mobile device or through a standard technology like Mobile SVG..."

• Compatible, Consistent and Extensible: "XLS should be scalable so that it can support a wide variety of devices, users, and applications; A simple data model should support XLS for all Abstract Data Types; this will minimize the overhead for feature (object) construction and deconstruction for OpenLS applications and services; XLS should be defined in XML schema (xsd); XLS types should be defined in a way that would give them enough flexibility to be used according to SOAP encoding rules; XLS specification activities should be harmonized with ISO 19133 (Navigation), ISO 19118 (XML Encoding rules) and GML; XLS should be designed so that XLS instances can be transformed (e.g., through an XSLT stylesheet) into GML..."

• Geometry Elements: "XLS must include point, line, line-string and polygon geometries, per OGC Simple Feature Model; XLS may include other geometries."

• XLS Feature Relationship Schema: "XLS may use Xlink to reference local resources or remote resources in the same document only, in an appropriate way that would work with the limited capabilities of available parsers; XLS must support simple relationships in which relationships do not carry properties."

• XLS Feature Schema: "XLS should support a simplified feature model that doesn't require multiple nesting levels; XLS must support the Abstract Data Types for OpenLS and related operations."

About the Open GIS Consortium (OGC)

The Open GIS Consortium (OGC) is an industry consortium whose members work in a collaborative, consensus process to enhance and enable interoperability for technologies involving spatial information and location. The OGC vision is a world in which everyone benefits from geographic information and services made available across any network, application, or platform. The OGC Mission is to deliver spatial interface and encoding specifications that are openly and publicly available for global use. In the OGC Specification Program, the OGC Technical Committee and OGC Planning Committee work in a formal consensus process to arrive at approved (or "adopted") OpenGIS Specifications. The OGC Interoperability Program is a series of hands-on engineering initiatives to accelerate the development and acceptance of OpenGIS Specifications..."

The OpenGIS Reference Model (ORM) provides an architecture framework for the ongoing work of the OpenGIS Consortium and its specifications and for implementing interoperable solutions and applications for geospatial services, data, and applications. Further, the ORM provides a framework for the OGC Technical Baseline. The OGC Technical Baseline consists of the currently approved OpenGIS Specifications as well as for a number of candidate specifications that are currently in progress. The ORM has the following purposes: (1) Provides a foundation for coordination and understanding (both internal and external to OGC) of ongoing OGC activities and the Technical Baseline; (2) Update/Replacement of parts of the 1998 OpenGIS Guide; (3) Describes the OGC requirements baseline for geospatial interoperability; (4) Describes the OGC architecture framework through a series of non-overlapping viewpoints: including existing and future elements; (5) Regularize the development of domain-specific interoperability architectures by providing examples..." [from the ORM document OGC 03-040 2003-03-04]