Conceptio › Archive › Open Geospatial Consortium (OGC)

Open Geospatial Consortium (OGC)open access

OpenGIS Location Service (OpenLS) Implementation Specification: Core Services (version 1.2.0) — OGC 07-074

Open Geospatial Consortium · Open Geospatial Consortium (OGC)

Open Geospatial Consortium (OGC) · Standards · License: Open Access

core geospatial implementation location ogc ogc07 opengeospatialconsortium opengis

ogc, geospatial, standard, open geospatial consortium, ols, ogc ols, 07-074, ogc 07-074, 1.2.0, opengis, location, service, openls, implementation, specification, core, services

Open Geospatial Consortium Inc. Date: 9 September 2008 Reference number of this OpenGIS® Project Document: OGC 07-074 Version: 1.2 Category: OpenGIS® Interface Standard Editor: Marwa Mabrouk, ESRI Contributors: Tom Bychowski, NavTeq Jonathan Williams, Hutchison 3G Harry Niedzwiadek, Image Matters Yaser Bishr, Image Matters Jean-Francois Gaillet, Webraska Neil Crisp, Intergraph Will Wilbrink, MapInfo Mike Horhammer, Oracle Greg Roy, Autodesk Serge Margoulies, Ionic Gil Fuchs, Tele Atlas Geoffery Hendrey, Telcontar

OpenGIS Location Services (OpenLS): Core Services [Part 1-Directory Service, Part 2-Gateway Service, Part 3-Location Utility Service (Geocoder/Reverse Geocoder), Part 4-Presentation Service, Part 5-Route Service] Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning This document is an OGC Standard. The authors welcome feedback. This document represents an official position of the OGC and of the OGC Technical Committee. It is subject to change without notice and may be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type: Document subtype: Document stage: Document language:

OpenGIS Implementation Standard Interface Approved English

OpenLS 1.2

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, Inc. ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement. 1 2 3

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR. THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY. This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party. Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it. None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents 1

Scope ....................................................................................................................... 1

Conformance ........................................................................................................... 1

Normative references .............................................................................................. 1

Relationship to Other Standards Activities ............................................................. 2

Terms and definitions ............................................................................................. 3

Symbols (and abbreviated terms)............................................................................ 5

Top-Level Architecture ........................................................................................... 5

8 8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.2 8.2.1 8.2.2 8.2.3 8.3 8.3.1 8.3.2 8.4 8.4.2 8.4.3 8.4.4 8.5

OpenLS Core Services ............................................................................................ 6 Part 1: Directory Service ......................................................................................... 7 Pinpoint Directory Service ...................................................................................... 8 Proximity Directory Service ................................................................................... 8 Use Cases ................................................................................................................ 8 Request and Response Parameters for Directory Service ....................................... 9 Part 2: Gateway Service ........................................................................................ 13 Use cases ............................................................................................................... 13 A Location Request Use Case............................................................................... 14 Request Parameters ............................................................................................... 14 Part 3: Location Utility Service (Geocode/ Reverse Geocode) ............................ 19 Use Cases .............................................................................................................. 19 Request and Response Parameters ........................................................................ 20 Part 4: Presentation Service .................................................................................. 23 Use Cases .............................................................................................................. 26 Request and Response Parameters ........................................................................ 26 Request and Response Pairs for Use Cases .......................................................... 32 Part 5: Route Service ............................................................................................ 36

8.5.2

Use Cases .............................................................................................................. 36

8.5.3

Request and Response Parameters ........................................................................ 37

OpenLS Information Model .................................................................................. 43

General Use Cases ................................................................................................ 44

Architecture Details .............................................................................................. 45

General Features ................................................................................................... 46

Conformance Requirements and Procedures ........................................................ 46

14 14.1 14.2 14.3

Future Work .......................................................................................................... 47 OpenLS 1.0 ........................................................................................................... 47 OpenLS 1.1 ........................................................................................................... 47 OpenLS 1.2……………………………………………………………………...47

iii

OpenLS 1.2



Annex A.1: OpenGIS Location Services (OpenLS) Core Services Schema, XML/S Profile (Normative) .................................................................................. 49 

Annex A.2: OpenGIS Location Services (OpenLS) Requirements (Informative) ...... 134 1 Requirements ............................................................................................................... 134 1.1 Terminology .............................................................................................................. 134 1.2 General Requirements ......................................................................................... 134 1.2.1 Usage Scenarios .................................................................................................. 135 1.2.2 Design Guidelines ............................................................................................... 135 1.2.3 Detailed Requirements ........................................................................................ 136 1.3 Interface Envelop and Encoding Requirements .................................................. 138 1.3.1 Key Concepts ...................................................................................................... 138 1.3.2 General Usage Pattern......................................................................................... 138 1.3.3 Assumptions ........................................................................................................ 139 1.3.4 General Requirements ......................................................................................... 139 1.3.5 Encoding Requirements ...................................................................................... 140 1.3.6 Request Requirements ........................................................................................ 142 1.3.7 Response Requirements ...................................................................................... 143 1.3.8 HTTP Transaction Protocol Requirements ......................................................... 144 1.4 Abstract Data Type Requirements ...................................................................... 145 1.4.1 Address ADT ...................................................................................................... 146 1.4.2 Area of Interest (AOI) ADT ............................................................................... 146 1.4.3 Location ADT ..................................................................................................... 146 1.4.4 Map ADT ............................................................................................................ 146 1.4.5 Point of Interest (POI) ADT ............................................................................... 146 1.4.6 Position ADT ...................................................................................................... 146 1.4.7 Route Instructions List ADT ............................................................................... 147 1.4.8 Route ADT .......................................................................................................... 147 1.5 Service Requirements ......................................................................................... 147 1.5.1 Directory Service requirements .......................................................................... 147 1.5.2 Gateway service requirements ............................................................................ 149 1.5.3 Location Utility service requirements ................................................................ 149 1.5.3.1 Geocode Service ................................................................................................ 149 1.5.3.2 Reverse Geocode Service .................................................................................. 150 1.5.4 Presentation Service ........................................................................................... 150 1.5.5 Route Service Requirements .............................................................................. 151 

Annex A.3: OpenGIS Location Services (OpenLS) Schema, OpenLS 1.1 Changes (Informative) ....................................................................................................... 152 1. Add geometry to route instruction element. .............................................................. 152 2. Explain usage of “lang” attribute on XLS element. ............................................ 152 3. Allow more than two street intersections............................................................ 153 4. Directory Request – SortCriteria / POI properties. ............................................. 153 5. Editorial changes ................................................................................................. 155 6. Add expectedEndTime to route. ......................................................................... 155 7. Change projections of returned content .............................................................. 155 Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

8. 9. 10. 11. 12. 13. 14. 15.

Specify preferred distance units in directory responses ...................................... 156 Schema validation fix ......................................................................................... 157 Clarify street encodings ...................................................................................... 157 Documentation change to clarify Street Attributes ............................................. 158 Correlate a route map with a route instruction.................................................... 158 Remove SearchArea from ReverseGeocodeRequest .......................................... 162 Remove devType from RequestHeader .............................................................. 162 Correct/update document submitters .................................................................. 162 

Annex A.4: OpenGIS Location Services (OpenLS) Schema, SOAP Profile (Informative) ....................................................................................................... 163  Annex A.5: OpenGIS Location Services (OpenLS) Schema, OpenLS 1.2 Changes (Informative)………………………………………………………………………... 15266

OpenLS 1.2

Preface This OpenGIS Interface Standard defines OpenGIS Location Services (OpenLS): Core Services, Parts 1-5, which consists of the composite set of basic services comprising the OpenLS Platform. This platform is also referred to as the GeoMobility Server (GMS), an open location services platform. The first version of this standard was produced immediately following the OpenLS 1/1.1 testbed initiatives, October 2001 – October 2002, and reflects lessons learned and the results of these efforts. It also includes enhancements and fixes made subsequent to the testbed efforts by an ad hoc work group consisting of the sponsors of this standard.

ii.

Submitting organizations This Standard was submitted to OGC by the following organizations: Autodesk, Canada ESRI, USA Image Matters, USA Intergraph IntelliWhere, Australia MapInfo, USA Navigation Technologies, USA Oracle, USA Sun Microsystems, USA Webraska, France Tele Atlas, USA Telcontar, USA

iii.

Document Contributor Contact Points All questions regarding this submission should be directed to the editors. CONTACT Yaser Bishr (Co-Author)

COMPANY OGC IP Team

ADDRESS 105 S. King Street

Leesburg, VA 20175 Tom Bychowski (CoAuthor)

Navigation Technologies

222 Merchandise Mart Plaza Suite 200 Chicago, IL. 60654 USA

Neil Crisp (Co-Author)

IntelliWhere Division, Intergraph Corporation.

Floor 3, 299 Coronation Drive, Milton Queensland 4064. Australia.

Jean-François Gaillet (CoAuthor)

Webraska

22 Avenue Guynemer BP 107 Maisons-Laffitte Cedex France

iv.

Marwa Mabrouk (Editor, Co-Author)

ESRI Inc.

380 New York st. Redlands CA 92373, USA

Harry Niedzwiadek (CoAuthor)

Image Matters

105 S. King Street

Jonathan Williams (CoAuthor)

Hutchison3G, UK Limited

Will Wilbrink (Co-Author)

MapInfo

Leesburg, VA 20175 Star House, 20 Grenfell Road, Maidenhead, SL6 1EH, United Kingdom MapInfo Corp 26 Wellington St East Suite 500 Toronto, Ontario M5E1S2

Revision history Date

Release

Oct. 2001 – various Oct. 2002

Author various

Paragraph modified N/A

Description Most of the content for this specification came from the final specifications developed under the OpenLS 1/1.1 initiatives, namely: OpenLS Reference Architecture: Draft Implementation Specification, Version 0.2.0, November 2002, OpenGIS Discussion Paper 02-089. OpenLS Route Determination Service: Draft Implementation Specification, Version 0.8.0, November 2002, OpenGIS Discussion Paper 02-090. OpenLS Presentation Service: Draft Implementation Specification, Version 0.1.8, November 2002, OpenGIS Discussion Paper 02-091. OpenLS Location Utility Services (Geocoder and Reverse Geocoder):

vii

OpenLS 1.2

Draft Implementation Specification, Version 0.6.0, November 2002, OpenGIS Discussion Paper 02-092. OpenLS Gateway Service: Draft Implementation Specification, Version 0.2.0, November 2002, OpenGIS Discussion Paper 02-093. OpenLS Directory Service: Draft Implementation Specification, Version 0.8.0, November 2002, OpenGIS Discussion Paper 02-094. This document supersedes these specifications.

Dec. 11 & 16, 2002

0.2

Marwa Mabrouk & HAN

Significant contributions throughout

All specs were combined into one document. The schemas were simplified. The full profile of the Route Determination Service becomes the new Navigation Service. The basic profile of the former Route Determination Service becomes the new Route Service. Abstract types are removed from the new Route Service and Navigation Service to be consistent with other OpenLS Core Services. Issues were added.

Dec 19, 2002

0.2 (retained version number)

HAN

Various.

At the request of the TC: 1) Added outstanding issues inline, and 2) Added notation to title page to reflect draft state of the document.

April 18, 2003

0.3, 0.4, 0.5 MM, HAN, WW, PD, GR, OR

Various

Schemas updated to GML 3.0 geometry. Schemas updated to OMA MLP 3.0. Numerous inconsistencies were fixed, clarifications were added and schema bugs fixed on the basis of comments from MapInfo and Autodesk.

December 22, 2004

1.1

Various

As specified in Annex 3

Changes to the OpenGIS Abstract Specification The OpenGIS© Abstract Specification does not require changes to accommodate the technical contents of this document.

viii

Foreword The information in this document was substantially derived from the OpenLS 1/1.1 testbed initiatives, public comment, and implementation experience. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

OpenGIS Location Services (OpenLS): Core Services [Part 1-Directory Service, Part 2-Gateway Service, Part 3Location Utility Service (Geocoder/Reverse Geocoder), Part 4Presentation Service, Part 5-Route Service] 8

Scope

This OpenGIS Interface Standard describes OpenGIS Location Services (OpernLS): Core Services, Parts 1-5, 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. 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. 9

Conformance

The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance, are specified in ISO 19105: Geographic information — Conformance and Testing. See section 20 concerning the requirements and procedures for OpenLS Conformance. 10 Normative references The following normative documents contain provisions, which through reference in this document constitute provisions of this architecture. For dated references, subsequent amendments to these publications or revisions of any of these publications do not apply. However, parties to agreements based on this document are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the documents applies. Abstract Specification Topic 0: Overview, OpenGIS document 04-084. Available [Online] :< http://portal.opengeospatial.org/files/?artifact_id=7560> Guidelines for Successful OGC Interface Specifications, OpenGIS document 00-014r1.

OpenLS 1.2

OpenGIS® Geography Markup Language (GML), Version 3.1.1, OpenGIS Encoding Standard. Available [Online]: < http://portal.opengeospatial.org/files/?artifact_id=4700>. OpenGIS® Location Services (OpenLS): Part 6: Navigation Service, Version 0.5, April 18, 2003, OpenGIS RFC 08-028r7. Available [Online]: < http://portal.opengeospatial.org/files/?artifact_id=28493>. Common Coordinate Reference Systems and Coordinate Transformations. OGC Project Document 05-095r1 and 05-094r1. Available [Online]: < http://portal.opengeospatial.org/files/?artifact_id=13204>. OGC Units of Measure Use and Definition Recommendations. OGC Recommendation Paper. OGC Project Document 02-007r4. Available [Online]: <http://portal.opengeospatial.org/files/?artifact_id=11498>. OpenGIS® Simple Features Specification for SQL 1.2. OGC Interface and Encoding Standard. Available [Online]: < http://portal.opengeospatial.org/files/?artifact_id=18241>. XML Linking Language (XLink) Version 1.0. W3C Recommendation (27 June 2001). Available [Online]: <http://www.w3.org/TR/xlink/> Namespaces in XML. W3C Recommendation (14 January 1999). Available [Online]: <http://www.w3.org/TR/1999/REC-xml-names-19990114/> XML Schema Part 1: Structures. W3C Recommendation (2 May 2001). Available [Online]: <http://www.w3.org/TR/xmlschema-1/> XML Schema Part 2: Datatypes. W3C Recommendation (2 May 2001). Available [Online]: <http://www.w3.org/TR/xmlschema-2/> 11 Relationship to Other Standards Activities Other standards activities that were reviewed and considered under the OpenLS initiative include related standards initiatives at ISO, W3C, IETF, LIF/OMA, 3GPP, AMIC, MAGIC, WAP, JAIN and Parlay, as well as other emerging and adopted OGC specifications.

Standards Framework Defines communication protocols

UMTS, GPRS, 3GPP, TIA, ETSI, etc.

Defines interfaces to bridge between third party apps and next generation communications services

Mobility services

Defines interfaces & content model for Open Location Services Platform.

JCP (JAIN)

Java implementation of next generation communication services

IETF

Internet protocols & services

W3C

Web protocols & services

OMA/WAP

Application protocols for wireless internet.

Other Specs: Magic,…

Navigation & locationbased information delivery services.

ParlayParlay-X/OSA

OMA/LIF

OGC (OpenLS)

Figure 1. Standards Framework

12 Terms and definitions For the purposes of this document, the following terms and definitions apply. 5.1 Abstract Data Type (ADT) The basic information construct used by the GeoMobility Server and associated Core Services. Consists of well-known data types and structures for location information. Defined as application schemas that are encoded in XML for Location Services (XLS). 5.2 Area of Interest (AOI) A user defined area (represented by a bounding box, circle or polygon). Often used as a filter in a query. 5.3 (OpenLS) Core Services The basic services that comprise the open service platform (GeoMobility Server) defined under OpenLS. 5.4 Directory Service A network-accessible service that provides access to an online directory (e.g. Yellow Pages) to find the location of a specific or nearest place, product or service.

OpenLS 1.2

5.5 Gateway Service A network-accessible service that fetches the position of a known mobile terminal from the network. This interface is modeled after the Mobile Location Protocol (MLP), Standard Location Immediate Service, specified in OMA 3.0 (see Open Mobile Alliance). 5.6 Geocoder Service A network-accessible service that transforms a description of a location, such as a place name, street address or postal code, into a normalized description of the location with a Point geometry (see OGC GML Encoding Standard for OGC geometry). 5.7 GeoMobility Server The open service platform comprising the Core Services developed under the OGC OpenLS initiatives. 5.8 Location-Based Service (LBS) A wireless-IP service that uses geographic information to serve a mobile user. Any application service that exploits the position of a mobile terminal. 5.9 Navigation Service An enhanced version of the Route Service, which is a network-accessible service that determines travel routes and navigation information between two or more points. (This service is documented under separate cover, see section 10.) 5.10 Point of Interest (POI) A location (with a fixed position) where one can find a place, product or service, typically identified by name rather than by address and characterized by type, which may be used as a reference point or a target in a location based service request, e.g., as the destination of a route. 5.11 Presentation (Map Portrayal) Service A network-accessible service that portrays a map made up of a base map derived from any geospatial data and a set of ADT’s as overlays. 5.12 Reverse Geocoder Service A network-accessible service that transforms a given position into a normalized description of a feature location (Address with Point), where the address may be defined as a street address, intersection address, place name or postal code. 5.13 Route Service A network-accessible service that determines travel routes and navigation information between two or more points. 5.14 XML for Location Services (XLS) The method for encoding request/response messages and associated Abstract Data Types for the GeoMobility Server.

13 Symbols (and abbreviated terms) The following symbols and abbreviated terms are used in this document. ADT

Abstract Data Type

API

Application Program Interface

GMLC

Gateway Mobile Location Center

GMS

GeoMobility Server

LBS

Location Based Service

LIF

Location Interoperability Forum

MLP

Mobile Location Protocol

MPC

Mobile Positioning Center

OGC

Open Geospatial Consortium

OMA

Open Mobile Alliance

OSA

Open Service Architecture

XLS

XML for Location Services

XML

eXtended Markup Language

14 Top-Level Architecture Figure 2 shows how the concept GeoMobility Server relates to the other elements of an LBS architecture. The GeoMobility server is an element offering basic functions on which location-based applications are built (the OpenLS Core Services). This server uses open interfaces to access network location capacity (provided through a GMLC, for instance) and provides a set of interfaces allowing applications hosted on this server, or on another server, to access the OpenLS Core Services (see definition of Core Services in section 15). The GeoMobility Server also provides content such as maps, routes, addresses, points of interest, traffic, etc. It can also access other local content databases via the Internet. In summary, the GeoMobility Server contains: §

The Core Services and their OpenLS interfaces;

OpenLS 1.2

§

The OpenLS Information Model, consisting of ADTs;

§

Possibly, a set of local applications build upon the Core Services and accessing them through OpenLS interfaces;

§

Content such as map data, points of interest, routes, and so on used by the Core Services. This content can also be hosted on other servers and accessed through the Internet; and

§

Possibly other supporting functions for personalization, context management, billing, logging, etc.

Figure 2. Role of the GeoMobility Server

15 OpenLS Core Services The Core Services are location-based application services that form the Services Framework for the GeoMobility Server. See the associated specifications for these services for details about each of these services (these references are listed in section 3).

The GeoMobility Server Core Network

Service Provider

GeoMobility Server OpenLS-based Applications

OpenLS

Personal Navigator, Concierge, Tracker…

OpenLS Core Services LIF

• Route • Gate way (LIF) • Presentation • Directory –Route Display –Map Display –Route Directions Display • Geocode / Reverse Geocode

Location Content • Road Net works • Navigation Info • Maps

OpenLS

Position Determination Equipment (GMLC/MPC)

Portal / Service Platform (Authentication, Billing, etc.)

OpenLS

Applications Residing on Mobile Terminals & Desktops

• Directories • Addresses • Traffic Info

Figure 3. The GeoMobility Server

Note: It is not necessary to specify a Coordinate Reference System for Point geometries that are used by these services because the default for all coordinates used by the GeoMobility Server is WGS 84. The coordinate conventions are as follows: - Default Coordinate Reference System - WGS 84 (srsName=EPSG4326); - Coordinate Order - Latitude, Longitude; - Value Type - Decimal Degrees; - Latitude Sign is +90 at North Pole to -90 at South Pole; - Longitude Sign is -180 west from Greenwich at the International Dateline to +180 east from Greenwich at the International Dateline.

15.1 Part 1: Directory Service

This service provides subscribers with access to an online directory to find the nearest or a specific place, product or service. Through a suitably equipped OpenLS application, the subscriber starts to formulate the search parameters in the service request, identifying the place, product or service that they seek by entering the name, type, category, keyword, phone number, or some other ‘user-friendly’ identifier. A position must also be employed Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

in the request when the subscriber is seeking the nearest place, product or service, or if they desire a place, product or service at a specific location or within a specific area. The position may be the current Mobile Terminal position, as determined through the Gateway Service, or a remote position determined in some other manner. The directory type may also be specified (e.g. yellow pages, restaurant guide, etc). Given the formulated request, the Directory Service searches the appropriate online directory to fulfill the request, finding the nearest or specific place, product or service, depending on the search criteria. The service returns one or more responses to the query (with locations and complete descriptions of the place, product, or service, depending upon directory content), where the responses are in ranked order based upon the search criteria. 15.1.1 Pinpoint Directory Service

Provides subscribers with access to an online directory to find the location of a specific place, product or service. This service is independent of subscriber location (e.g., the subscriber may wish to ‘pinpoint’ a place in a distant country). 15.1.2 Proximity Directory Service

Provides subscribers with access to an online directory to find the nearest place, product or service. From the Usage Scenarios below, it seems unnecessary to separate these usages into two services, when they are simply special cases of the same underlying Directory Service request. The examples below will illustrate that there are two simple cases for finding a particular point of interest that roughly correspond to the Pinpoint and Proximity requests: 1. By some property of the Point of Interest (e.g., unique identifier, name, description, phone number, absolute location) 2. By its location relative to some other point of interest (e.g., Nearest to me, within some distance of a specified entity, within some defined boundary). Any of these or combinations of these may be made using the combined Directory Services request which is specified below. 15.1.3 Use Cases

The user of the Directory Service wishes to locate a particular Place, Product or Service. The user may constrain the request by specifying parameters that filter out candidate places/products/services according to some identifier, attribute, or location. Example usage scenarios for Directory Service are captured below.

15.1.3.1

Use Case 1

Constraining the request by identifier amounts to a Pinpoint White Pages query: “Where is the Red Dragon Chinese Restaurant?” 15.1.3.2

Use Case 2

Constraining the request just by attribute amounts to a normal Yellow Pages query: “Where are the Chinese Restaurants?” 15.1.3.3

Use Case 3

Constraining the request by location relative to a given location amounts to a Proximity query: “Where is the nearest Chinese Restaurant to my hotel?” 15.1.3.4

Use Case 4

Constraining the request by location within a boundary amounts to a different Proximity query: “Which Chinese Restaurants are within 500m of my hotel?” Any of these requests could result in a response consisting of a text address list, a location map, or, if a source location is provided with the request, a route map and a list of directions. 15.1.4 Request and Response Parameters for Directory Service

This section specifies the request and response parameters for the Directory Service. Note that it not required to specify a Spatial Reference System as all co-ordinates will be referenced to WGS 84 (latitude, longitude). 15.1.4.1

Directory Request Parameters

A collection of one or more of the parameters below Name

Mandatory?

Data Type

Description

POI Location

Location ADT

Start point for proximity searches (may be a POI). *Mandatory if proximity type set to Linear distance. Subtypes are: Address, Nearest and WithinDistance. Nearest

OpenLS 1.2

and WithinDistance also have an Address subtype. Address

Address ADT

Address for this POI

Nearest

Integer

Searching for closest services

Within Distance

WithinDistanceType

Searching for services no further than this distance.

MaximumDistance

Decimal

The maximum distance for the search

MinimumDistance

Decimal

The minimum distance for the search

WithinBoundary

AOI ADT

Polygon to search within.

POIProperties

POIPropertiesType

Container for the list of properties that will be used to do the search

directoryType

String

One of the following: White Pages, Yellow Pages, Green Pages, and Blue Pages. This is not an exhaustive list of directories, and there is no requirement that one vendor should implement all of them.

POIProperty

POIPropertyType

The property used to search for a POI, a property would contain a name and value. Because the directory service doesn’t implement a capabilities request that describes the structure of the data, a generic enumeration has been devised to allow for generic searches, without having to know the data structure

Name

POIPropertyNameT ype

Values allowed for this attribute are: ID POIName PhoneNumber Keyword (a generic parameter) NAICS_type NAICS_subtype NAICS_category SIC_type SIC_subtype SIC_category SIC_code Other (custom values)

value

String

The value of this property

SortCriteria

String

Attribute to be used for sorting the results. It may take on the well-known values of “Name” and “Distance” as well as any other POI property names.

SortDirection

Boolean

Ascending/Descending

distanceUnit

DistanceUnitType (ADT)

Specifies the unit for measuring distance. Default = “M”

15.1.4.1.1

Example Directory Requests

a. Use Case 1 – “Where is the Red Dragon Chinese Restaurant?” <DirectoryRequest> <POIProperties directoryType="White Pages"> <POIProperty name="POIName" value="Red Dragon Chinese Restaurant"/> </POIProperties> </DirectoryRequest> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

b. Use Case 2 – “Where are the Chinese Restaurants?” <DirectoryRequest> <POIProperties directoryType="Yellow Pages"> <POIProperty name="NAICS_type" value="Restaurant"/> <POIProperty name="NAICS_subType" value="Chinese"/> </POIProperties> </DirectoryRequest>

Use Case 3 – “Where is the nearest Chinese Restaurant to my hotel?”

d. Use Case 4 – “Which Chinese Restaurants are within 500m of my hotel?” <DirectoryRequest> <POILocation> <WithinDistance> <POI ID="1"> <POIAttributeList> <POIInfoList> <POIInfo name="POI Name" value="My Hotel"/> </POIInfoList> </POIAttributeList> </POI> <MaximumDistance value="500"/> </WithinDistance> </POILocation> <POIProperties directoryType="Yellow Pages"> <POIProperty name="NAICS_type" value="Restaurant"/> <POIProperty name="NAICS_subType" value="Chinese"/> </POIProperties> </DirectoryRequest>

15.1.4.2

Directory Response Parameters

Response Parameters

A collection of one or more of the parameters below. Name

Mandatory?

Data Type

POIContext

POIWithDistanceType A list of one or more POIs and there distance from the request location.

Points of Interest / Distance pairs

List of POI and Distance (Integer) pairs

15.1.4.3

Description

List of all Point of Interest records satisfying the request and the distance from the source location. Distance will be zero for WithinBoundary request.

Notes:

a. Depending on the nature of the query, some terms within the query may be mandatory or not. b. The proximity query performs a spatial filter on a list of Points of Interest. These POIs may be listed explicitly by a unique identifier (ID, Name, Coordinate, Coordinate List, Address) or derived from categories, formal categories or keywords within a Directory Type.

15.2 Part 2: Gateway Service

This is the interface between the GeoMobility Server and Location Server that resides in the GMLC or MPC through which OpenLS services obtain position data for Mobile Terminals. This interface is modeled after the MLP specified in OMA 3.0 for Standard Location Immediate Service. 15.2.1 Use cases

These use cases have been grouped into 3 priority categories, with priority 1 having the highest priority and the only case for mandatory support. The Gateway Service should support the following:

OpenLS 1.2

Use Case

Priority

Client requests a single mobile terminal’s immediate location.

Client requests single mobile terminal’s periodic location

Client requests multiple mobiles’ immediate location

Client requests single mobile terminal’s triggered location

Client request multiple mobiles’ periodic location

Client requests multiple mobiles’ triggered location

15.2.2 A Location Request Use Case

A subscriber wants to use a Location-Based Service. The Gateway Service is employed to obtain the position of the subscriber’s mobile terminal from the network. A Location Service Client sends the request to determine a position to the Gateway. The Gateway calculates the position of the subscriber’s mobile terminal and forwards to the Location Service Client, which may store it for as long as needed.

15.2.3 Request Parameters

This section specifies the request parameters for the Gateway Service. Name

Mandatory?

Data Type

Description

SLIR

SLIRType

The request.

responseType

optional

Enumeration

Two values, default is PERSISTENT. - PUSH - PERSISTENT

InputGatewayParame ters

InputGatewayParam etersType

Details for the input request. This is required to support other Location Requests defined in OMA.

locationType

Optional

Enumeration

To specify one of three values, default is CURRENT - CURRENT - LAST - CURRENT_OR_LAST

requestedcrsName

Optional

string

The requested Spatial Reference system.

priority

Optional

Enumeration

Priority of the request is one of two values, default is HIGH. - NORMAL - HIGH

RequestedQoP

Optional

QualityOfPositionT ype

The quality of the position is specified through the vertical and horizontal accuracy.

responseReq

Optional

Enumeration

Three possible values, default is Delay_Tol. Corresponds to ResponseReq in OMA MLP - No_Delay - Low_Delay - Delay_Tol

responseTimer

Optional

string

HorVerAcc

Group:HorVerAcc

HorizontalAcc

HorAccType

Corresponds to the OMA element called “resp_timer” in the MLP_QOP DTD.

Horizontal accuracy is defined through the distance and the angle 15

OpenLS 1.2

Distance

DistanceType

Distance contains three attributes, value, accuracy and uom

value

Decimal

Distance value

accuracy

optional

Decimal

Distance accuracy (standard error)

uom

optional

DistanceUnitType

Distance units of measure

Angle

Xls:angleType

Angle contains three attributes, value, accuracy and uom

value

Decimal

Angle value

accuracy

Optional

Decimal

Angle accuracy (standard error)

uom

Optional

string

Angle units of measure

VerticalAcc

VerAccType

Vertical accuracy is defined through the distance

InputMSID

InputMSIDType

Identifies the mobile subscriber.

session

Optional

string

Corresponds to the “sessionid” element in the OMA MLP_CTXT DTD.

InputMSInformatio nType

Identifies the mobile subscriber

InputMSInformaiton Y

msIDType

Enumeration

Eight values, default is MSISDN. MSISDN MIN IMSI IMEI MDN EME_MSID IPV4 IPV6

msIDValue

String

The value based on the type specified

Encryption

Optional

enumeration

Three possible values, default value is ASC.

15.2.3.1

ASC

B64

CRP

Example Directory Requests

a. Use Case 1 <SLIR> <InputGatewayParameters priority="HIGH" locationType="CURRENT_OR_LAST" requestedsrsName="WGS84"> <InputMSID> <InputMSInformation msIDType="IPV4" msIDValue="461018765728"></MSInformation> </ InputMSID > <RequestedQoP responseReq="No_Delay" responseTimer="20"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

8.2.4 Response Parameters

SLIA

SLIAType

The response.

requestID

optional

string

Corresponds to the “req_id" element in the OMA MLP_SLIA DTD.

OutputGatewayPra maters

OutputGatewayPr amatersType

Wrapper to hold response

OutputMSID

OutputMSIDType

Identifies the mobile subscriber

OutputMSInformati on

OutputMSInformati Contains the position ADT onType

8.2.4.1 Example Directory response

a. Use Case 1 <SLIA requestID=”1”> <OutputGatewayParameters> <OutputMSID> <OutputMSInformation msIdType="msisdn" msIDValue=” +12066741000”> <Position> <gml:Point> <gml:pos>47.611197 -122.347565</gml:pos> </gml:Point>

</Position> </OutputMSInformation> </OutputMSID> </OutputGatewayParameters> </SLIA>

15.3 Part 3: Location Utility Service (Geocode/ Reverse Geocode)

This service performs as a Geocode by determining a geographic position, given a place name, street address or postal code. It also returns a complete, normalized description of the place (which is useful, say, when only partial information is known). The service also performs as a reverse Geocode by determining a complete, normalized place name/street address/postal code, given a geographic position. Both the Geocode and reverse Geocode may return zero, one, or more responses to a service request, depending on subscriber request information, the algorithm being employed, and the match criteria. 15.3.1 Use Cases 15.3.1.1

Geocode Service

Once a Geocode Service determines a position from a partial or complete address, then the pertaining information element becomes a location-based resource that can be readily exploited by another service, like Directory or Route. 15.3.1.1.1

Use Case 1 – Given an Address, Find a Position

A company has a database with a list of its customers and addresses. They want to geocode their database and have a geometry (Point) attached to the addresses. This will then be used to display the locations of customers on a mobile device. 15.3.1.1.2

Use Case 2 – Drive to an Address (Position)

A motorist wishes to drive from home to an address in Regent Street, London. The address is geocoded and its location used as a destination within in a route planning application. 15.3.1.1.3

Use Case 3 – Given a Place/ Street Name, Find its Position and Display it on a Map

Elvis Presley wants a map to his new dwelling place. He only knows part of the address: “Heartbreak Hotel”, ”Lonely Street”.

OpenLS 1.2

The partial address is fed into a Geocode Service that determines the complete normalized address and position of Elvis’ dwelling. This in turn is fed into a Route Service that calculates the route from Elvis’ current position (as determined for his cell phone) to the dwelling. The result is a map.

15.3.1.2 15.3.1.2.1

Reverse Geocode Service Use Case 1 – Given a Position, Find an Address

The Reverse Geocoding Service is normally requested by an application that merely needs to determine the address for a given position. The application sends a Position ADT to the Reverse Geocode, which returns the Address of the position. 15.3.1.2.2

Use Case 2 – Where am I?

A mobile phone user is walking down a road and wants to know the address of the building that she is standing outside. The returned address information returned may be displayed for the subscriber, used to generate a voice command or otherwise used by the OpenLS applications. 15.3.1.2.3

Use Case 3 – Provide Location Context

How “Get Location Service” is provided by the Reverse Geocode Service: A user needs an answer to the question “Where Am I?” based on their current location. They desire expanded “location context”, e.g., street, place, jurisdiction. The application sends the Position ADT to the Reverse Geocode Service, which returns the expanded location information for that position. The application can then extract the location information corresponding to the required context “street address”, “place” etc. 15.3.2 Request and Response Parameters

This section specifies the primary request and response parameters for the Geocode and Reverse Geocode Services. 15.3.2.1

Geocode Service

Primary GeocodeRequest Parameters

A collection of one or more of the parameters below. Name

Mandatory?

Data Type

Description

Address

Address ADTs

List of 1 Addresses. May be unstructured free form address, partial or complete addresses.

Primary GeocodeResponse Parameters

For each Address request, the response (GeocodeResponseList) will contain a collection of the following parameters: Name

Mandatory?

numberOfAddresses Y (attribute of GeocodeResponseList)

Data Type

Description

Integer (nonnegative)

Number of valid responses (GeocodedAddress) found by the Geocoder Service for a given Address request; may be zero.

List of 1 GeocodedAddress(es) sorted by the Accuracy of the match, with highest accuracy first, each with the following parameters: Point

Point (Geometry)

The position of the GeocodedAddress response resulting from the geocoding operation.

Address

Address ADT

The actual Address for the GeocodedAddress response. These are normalised addresses.

GeocodeMatchCode

GeocodingQOSType The QoS information for the GeocodedAddress response. Provides information on the quality of the match. These results consist of an Accuracy (float value within the range 0.0 – 1.0) and a MatchCode (MatchType)

OpenLS 1.2

15.3.2.2

Reverse Geocode Service

Primary ReverseGeocodeRequest Parameters

Name

Mandatory?

Data Type

Description

Position

Position ADT

The starting position (lat,long) for Reverse Geocoder.

ReverseGeocodePref erenceType

Describes the preference for the response from the Reverse Geocoder Service: StreetAddress, IntersectionAddress, or PositionOfInterest (Place and/or PostalCode). If not specified, then the service will return the nearest StreetAddress.

ReverseGeocodePrefe N rence

Primary ReverseGeocodeResponse Parameters

Name

Mandatory?

Data Type

Description

List of 0 ReverseGeocodedLocation(s) sorted by the SearchCentreDistance (the distance between the starting Position in the request and each Point-Address response), in order (with shortest distance first), where each ReverseGeocodedLocation has the following parameters: Address

Address ADT

The actual Address for the ReverseGeocodedLocation response. These are normalised addresses.

Point

Point (geometry)

The position (lat, long) of the ReverseGeocodedLocation response.

SearchCentreDistance N

Float (decimal metres)

Distance of Point from starting Position.

Notes: 1. SearchArea must contain starting Position; therefore the service must be capable of validating this. 2. All response lists are sorted in order of shortest to longest SearchCentreDistance (default in metres). 3. If SearchArea is not specified, only the nearest valid response is returned. 15.4 Part 4: Presentation Service

This service renders geographic information for display on a Mobile Terminal. Any OpenLS Application may call upon this service to obtain a map of a desired area, with or without map overlays that depict one or more OpenLS ADTs, such as Route Geometry, Point of Interest, Area of Interest, Location, Position and/or Address. The service may also be employed to render route directions from Route Maneuver List ADT and/or Route Instructions List ADT. 15.4.1.1

Output Parameters

Defines what the size and encoding of the portrayed map should be using the following criteria: Width – The width of the map in pixels. Height – The height of the map in pixels. Format – Parameter that specifies what the encoding of the map should be. This is specified as a mime-type. The mime-types supported are left up to the implementation. Transparency - Boolean that defines the opacity of the background of the map. Background Color – Defines the background color of a map if it is opaque. Content – Specifies what type of content would be returned, whether the URL or the data as base64

OpenLS 1.2

The default behavior of the map is to return the exact image size as specified in the request. The Harmonization group is working on harmonizing the different OGC Standards such as WMS and OpenLS, to have consistent behavior where both specs are concerned. 15.4.1.2 Context

Defines what area of the world the map is portraying. This can be defined in the following ways: Bounding Box- Two-point box in a specific SRS that defines the extents of the map (WGS 84 is the default). This is the same bounding box used in WMS and is present for compatibility with it. Center Point and Scale - The center point defines the center of your map at a particular scale and projection. o Center Point – The center point of the map. This point is specified in WGS 84 as a latitude/longitude in decimal format. o Scale – The ratio between device units and world units. Specified as the number of world units per device units. Thus 1:50000 would be expressed as a scale of 50000. o Azimuth – The orientation of the map. This is expressed in clockwise degrees from north. o DPI – Dots per inch of the device. o SRS – Spatial Reference System. Provides what projection should be used when creating the map. o DisplayScale - A ratio of distance. For example 1:5000 would be expressed as 5000, it's always expressed per 1 pixel of the display. If context is not specified the implementation must derive it from the ADTs. 15.4.1.3

Overlays

Defines a list of ADTs for portrayal on the map. ADT (Abstract Data Type) – ADTs are usually obtained as outputs from other core services. To date we have Position ADT, Route ADT, POI ADT and Map ADT. Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

o Z Order – The order in which the ADTs are laid on top of each other over the base map. Custom Style – This is either a named-style or a user-defined style. This standard does not define a specific format for style description. This is a placeholder for custom extensions to use. Also, a placeholder for future versions to define. If a style is not specified it is up to the implementation to use a default.

15.4.1.4

Base Map

Provides a backdrop for the ADTs and is made up of a set of layers. The user determines the layers that are to be included or excluded from the base map in their request. The implementation must create and support its own list of layers for the user to choose from. Layers – The list of layers of interest o Filter – Determines if the layers are included or excluded. “Give me only the following layers” or “Give me all layers but the following”. The default behavior is to include all the layers. But when filters need to be applied that’s when they would need to be defined. Custom Style – This is either a named-style or a user-defined style. This standard does not define a specific format for style description. This is a placeholder for custom extensions to use. Also, a placeholder for future versions to define. If a style is not specified it is up to the Implementation to use a default.

15.4.1.5

Style

Defines how the ADTs should look. The implementation should create and support their own list of styles for the consumer to choose from. Named Style – A string that is provided by the implementation. User Defined Style – The consumer defines the content of the style. This standard does not define a specific format for style description. This is a placeholder for custom extensions to use. Also, a placeholder for future versions to define.

OpenLS 1.2

15.4.1.6

Get Capabilities

Provides the user with the list of capabilities that the implementation provides. Consists of the following: Layers - Layers provided by the implementation. Style – Styles provided by the implementation. Format – Mime-types supported by the implementation. SRS – Spatial Reference Systems supported, in EPSG:XXXX format. 15.4.2 Use Cases 15.4.2.1

Use Case 1

Joe User wants to see where his house is located on a map. To satisfy this use case the presentation service needs to show a base map with the position of Joe’s house overlaid onto it. For an example see section 15.4.4.1. 15.4.2.2

Use Case 2

Planning a family road trip, Joe User wants to see how get from his house in Calgary, Alberta, to the hotel he has booked in San Diego, California. To satisfy this use case the presentation service needs to show map(s) with the route and the two points of interest overlaid onto it. For an example see section 15.4.4.2. 15.4.3 Request and Response Parameters

This section specifies the request and response parameters for the Presentation Service. 15.4.3.1

Request Parameters

REQUEST PARAMETER

REQUIRED

Output Parameters



Width



DATA TYPE

DATA DESCRIPTION List of Outputs (1 to unbounded)

Integer

Number of pixels

Height



Integer

Number of pixels

Format



String

Mime-type

Transparent

Boolean

Defaults to true if not specified

BGcolor

String

RGB Hex Format Defaults to “#FFFFFF” (white)

Content

URL Data

Bounding Box Context

Center Context

Azimuth

Specifies the type of output the map is returned in whether URL or data for base 64, default value is URL

XLS Box

2 point box in a specified SRS

Integer

Orientation. Specified in clockwise degrees from north

SRS



String

EPSG:XXXX format

Center Point

XLS Point

latitude/longitude WGS84

DisplayScale

Integer

Ratio of world units to a device unit. For example 1:50000 would be specified as 50000

DPI

Integer

Dots per inch of the device

Radius

Integer

Defines area required

OpenLS 1.2

to be displayed Overlay

List of overlays (0 – unbounded)

ADT



Style

XLS ADT

Currently PositionADT, RouteADT, POI ADT & MapADT Either a Named Style or a User Defined Style Implementation uses a default if neither is specified

Zorder

The order in which the overlay’s are laid on top of each other over the base map

BaseMap

Layer

String

The list of layers that will be filtered to make up the base map

Style

String

Custom styles are used. This is a placeholder for custom styles or future additions to the spec

Filter



String

Either “include” or “exclude”

Get Capabilities

Has no data. Simply allows one to request capabilities.

Notes: 2. Either a Bounding Box Context or a Center Context can be specified (not both). If neither is specified, the implementation must derive it from the ADTs. 3. If an implementation provides Get Capabilities, the request can be either a “Portray” request or a “Get Capabilities” request (not both). 15.4.3.2

Response Parameters

RESPONSE PARAMETER

REQUIRED

DATA TYPE

DATA DESCRIPTION



XLS MapADT

Available Layers



String

A list of strings

Available Formats



String

A list MIME-type strings

Available SRS’s



String

A list of EPSG:XXXX strings

Available Styles



String

A list of strings

Map ADT

Contains the encoded map, Can have multiple maps if the request have specified multiple ones

Get Capabilities Response

Notes: 1. Either a “PortrayResponse” or a “Get Capabilities Response” can be returned (not both).

OpenLS 1.2

Figure 4 GetPortrayMapCapilities Response

Figure 5 PortrayMap Request

OpenLS 1.2

Figure 6 PortrayMap Response 15.4.4 Request and Response Pairs for Use Cases

The following are examples of one way to solve the use cases defined in Section 8; they are not the only solutions. 15.4.4.1

Use Case 1 Example

In order to satisfy Use Case 1, the application must acquire a Position ADT for where Joe’s home is located. One way to do this is to have the Geocoder Service geocode his address, thus determining a Position ADT. In this example we are asking for: 640x480 image in PNG format At a scale of 1:20000 In WGS 84 / UTM zone 11N (EPSG:32611) projection With a north orientation

Centered on Joe’s house Base map will consist of all layers (using default style) made available by the implementation The location of Joe’s home will be shown using the default style provided by the implementation Request: <?xml version="1.0" encoding="UTF-8"?> <PortrayMapRequest> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope>

<gml:pos>-114.342 50.234</gml:pos> <gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope > </Output> <!—Ask the impl to exclude no layers (thus, create the base map with all your layers) --> <Basemap filter="Exclude" /> <Overlay> <Position>  </Position> </Overlay> </ PortrayMapRequest >

Response: <?xml version="1.0" encoding="UTF-8"?> <PortrayMapResponse>  <Map> <Content width="640" height="480" format="image/png"> <URL> http://www.mapseter.com/lbs/maps/hgtr837468.png </URL> </Content> <gml:Envelope>

<gml:pos>-114.342 50.234</gml:pos> <gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope > </Map> </PortrayMapResponse>

OpenLS 1.2

15.4.4.2

Use Case 2 Example

A prerequisite for this use case are Position ADTs for Joe’s home and the Hotel. We also need the Route ADT, which shows the route from the home to the hotel. The Route ADT may be obtained from the Route Service. Because the route is very large and we want to see it at a detailed scale we will be asking for multiple maps. We are asking for: (N) maps centered on different points of the route 640x480 image in PNG format At a scale of 1:80000 In UTM projection With a north orientation Base map will consist of only the road network and landmarks The base map and the ADTs will be displayed using the “post-modernistic” style The position of Joe’s House and the Hotel will be drawn on top of the route Request: <PortrayMapRequest> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope>

<gml:pos>-114.342 50.234</gml:pos> <gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope > </Output> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope> <gml:pos>> -120.312 48.823 </gml:pos>

<gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope > </Output> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope> <gml:pos>> -120.312 48.823 </gml:pos> <gml:pos>-125.235 46.284</gml:pos> </ gml:Envelope > </Output>  Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<Basemap filter="Include"> <Layer name=”Road Network”> <Style> <Name>post-modernistic</Name> </Style> </Layer> <Layer name=” Landmarks”> <Style> <Name>post-modernistic</Name> </Style> </Layer> </Basemap> <Overlay zorder="0"> <RouteGeometry>  </RouteGeometry> <Style> <Name>post-modernistic</Name> </Style> </Overlay> <Overlay zorder="1"> <Position>  </Position> <Style> <Name>post-modernistic</Name> </Style> </Overlay> <Overlay zorder="1"> <Position>  </Position> <Style> <Name>post-modernistic</Name> </Style> </Overlay> </ PortrayMapRequest >

Response: <PortrayMapResponse>  <Map> <Content width="640" height="480" format="image/png"> <URL> http://www.mapseter.com/lbs/maps/hgtr837468.png </URL> </Content> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope>

<gml:pos>-114.342 50.234</gml:pos> <gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope >

OpenLS 1.2

</Output> </Map> <Map> <Content width="640" height="480" format="image/png"> <URL> http://www.mapseter.com/lbs/maps/hgtr83567.png </URL> </Content> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope> <gml:pos>> -120.312 48.823 </gml:pos>

<gml:pos>-114.123 50.031 </gml:pos> </ gml:Envelope > </Output> </Map> <Map> <Content width="640" height="480" format="image/png"> <URL> http://www.mapseter.com/lbs/maps/hgtr83324.png </URL> </Content> <Output width=”640” height=”480” format=”image/png”> <gml:Envelope> <gml:pos>> -120.312 48.823 </gml:pos> <gml:pos>-125.235 46.284</gml:pos> </ gml:Envelope > </Output> </Map> </PortrayMapResponse>

15.5 Part 5: Route Service

This service determines a route for a subscriber. The subscriber must use a navigation application to set up the use of the service. They must indicate the start point (usually the position acquired through the Gateway Service, but this could be a planned trip from a specified location, say, from their home), and the endpoint (any location, like a place for which they only have the phone number or an address, or a place acquired through a search to a Directory Service). The subscriber may optionally specify waypoints, in some manner, the route preference (fastest, shortest, least traffic, most scenic, etc.), and the preferred mode of transport. The subscriber may optionally store a route for as long as needed, thus requiring the means to also fetch a stored route. An enhanced version of this service, the Navigation Service, is described under separate cover (see Normative References, section 10). The Navigation Service supports the same parameters as the Route Service, plus additional parameters for navigation purposes. 9.5.2 Use Cases Use Case 1: The user wants to know: Which route should I take? The user has specified the endpoints, and optionally some waypoints, in some manner, or these points have been specified for the user. The starting point is either defined from a GPS or cellular network measurement or entered manually by the user. This information is then fed to a service Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

that determines the route. Optionally, the user may specify route determination criteria. These criteria might be: fastest, shortest, least traffic, most scenic, etc. and can also specify the preferred mode of transport of the user. The routing algorithm might default to a single criterion, such as fastest. The route can also be optionally stored on the terminal or application server. The user may store it for as long as needed, thus requiring the means to also fetch a stored route. 9.5.3 Request and Response Parameters 9.5.3.1 Route Service Request Parameters Request Parameters

A collection of one or more of the parameters below Name

Mandatory

Data Type

Description

RoutePlan

RoutePlanType

Specifies the criteria upon which a new route is determined.

RouteHandle

RouteInstructionsRe quest

RouteHandleType Reference to a previously (ADT) determined route. Used to request additional information about the route, or to request an alternate route. N

RouteInstructions RequestType

Requests the return of turnby-turn route instructions and travel advisories in a text, voice, or other presentation format.

RouteGeometryRequ N est

RouteGeometryR equestType

Requests the return of the route geometry.

RouteMapRequest

RouteMapReques tType

Requests the return of one or more maps of the route.

provideRouteHandle

Boolean

Requests the return of a route handle. Default = “false”

OpenLS 1.2

distanceUnit

DistanceUnitType Specifies the unit for (ADT) measuring distance. Default = “M”

RoutePlanType: Defines the criteria upon which a route is determined.

Name

Mandatory

Data Type

Description

RoutePreference

Enumeration

Routing preference to be taken into consideration when determining the route: “Fastest” – Minimize the travel time. “Shortest” – Minimize the travel distance. “Pedestrian” – Best route by foot.

WayPointList

WayPointListTy pe (ADT)

List of waypoints along the route.

AvoidList

AvoidListType

List of areas, locations, and features in which the route should avoid passing through.

useRealTimeTraffic

Boolean

Specifies whether to use real time traffic information when determining the best route. Default is “false”

expectedStartTime

DateTime

Specifies the date and time at which travel is expected to begin. The format follows the W3C defintion for DateTime. Reference URL: http://www.w3.org/TR/xmlsch ema-2/#dateTime

AvoidListType: Defines the list of areas, locations, and features in which the route should avoid passing through.

Name

Mandatory

Data Type

Description

AOI

AreaOfInterest (ADT)

Specifies the geographic areas to avoid.

Address

Address (ADT)

Specifies the address for the point to avoid

POI

POI (ADT)

Specifies a POI to avoid

Position

Position (ADT)

Specifies the locations to avoid.

AvoidFeature

List of Enumeration

Specifies the types of features to avoid when determining the route: “Highway” – Minimize the use of highways. “Tollway” – Minimize the use of tollways.

RouteInstructionsRequestType: Defines the request parameters for turn-by-turn route instructions and travel advisories formatted for presentation.

Name

Mandatory

Data Type

Description

format

String

The preferred format of the route instructions, specified as a mime type. Defaults to text/plain.

provideGeometry

boolean

Default is false

provideBoundingBox

boolean

Default is false

OpenLS 1.2

RouteGeometryRequestType: Defines the request parameters for route geometry.

Name

Mandatory

Data Type

Description

BoundingBox

Gml: EnvelopeType

Rectangular geographic area of route for which the geometry is requested. If not specified, defaults to full route.

scale

Positive Integer

Maximum scale at which the route will be displayed. Expressed as a ratio of world units to a device unit. For example 1:50000 would be specified as 50000. Default = 1

provideStartingPortio n

Boolean

If true, return the geometry of the starting portion of the route contained within the specified bounding area, up to the specified maximum number of points. If false, return the geometry of the complete route contained within the specified area, reducing the accuracy of the geometry as necessary to not exceed the specified maximum number of points. Default = false

maxPoints

Positive Integer

Specifies the maximum number of geometric points to be returned. Default = 100

RouteMapRequestType: Defines the request parameters for route maps.

Name

Mandatory?

Data Type

Description

Output

RouteMapOutpu tType

Specifies the output of the map(s) to be generated. This is a subset of the map output parameters defined by the Presentation Service.

RouteMapOutputType: Defines the rendered route map output parameters. This is a subset of the map output parameters defined by the Presentation Service. A collection of one or more of the parameters below. Name

Mandatory

Data Type

Description

BBoxContent

Gml:EnvelopeTy Rectangular area to be pe displayed in the rendered map. If not specified, defaults to a rectangular area bounding the full route.

width

Non-negative Integer

Pixel width of the resulting map.

height

Non-negative Integer

Pixel height of the resulting map.

format

String

Mime type describing the encoding.

BGcolor

String

The background color of the map

transparent

boolean

The opacity of the map. If set true, the map background is transparent. If set false, the map background

OpenLS 1.2

is opaque.

9.5.3.2 Route Service Response Parameters Response Parameters

A collection of one or more of the parameters below. Name

Mandatory

Data Type

Description

RouteHandle

RouteHandleType Contains a reference to the (ADT) route stored at the Route Determination Service server. Can be used in subsequent requests to the Route Service to request additional information about the route, or to request an alternate route.

RouteSummary

RouteSummaryT ype (ADT)

Describes the overall characteristics of the route.

RouteGeometry

RouteGeometryT ype (ADT)

Contains the route geometry.

RouteInstructionsList

RouteInstructions ListType (ADT)

Contains a list of turn-by-turn route instructions and advisories, formatted for presentation. May contain the geometry and bounding box if specified in the request. May contain description. For example this can be used to connect the instruction with a map.

RouteMap

RouteMapType

Contains a list of route maps. Can be used to specify which

type of map to be generated whether an overview or maneuver. May contain description. For example this can be used to connect the instruction with a map.

16 OpenLS Information Model The OpenLS Core Services exchange content in the form of well-known OpenLS Abstract Data Types (ADTs). Collectively these ADTs comprise the OpenLS Information Model (Figure 7). The OpenLS Information Model

Position ADT

Point location in well-known coordinate system

Address ADT

Street address or intersection

Point of Interest (POI) ADT

The location where someone can find place, product or service

Area of Interest (AOI) ADT

A polygon, bounding box or circle used as a search template

Location ADT

A location (Position, Address or POI)

Map ADT

The portrayal of maps and feature overlays (routes & POI)

Route Summary ADT

Metadata pertaining to a route

Route Geometry ADT

Geometry data for a route

Route Maneuvers ADT

Navigation maneuver data for a route

Route Directions ADT

Turn-by-turn navigation instructions for a route

Reverse Geocode

Address ADT AOI ADT

Directory POI

Directories

ADT LIF MLP Address ADT

Gateway Geocode

Presentation

Position ADT Position ADT

Location ADT

Route

Maps Routes Route Instructions POIs

Route Summary ADT Route Geometry ADT Route Maneuvers ADT Route Directions ADT

Route Data

Map data

Figure 7. OpenLS Information Model

OpenLS 1.2

17 General Use Cases Use Case I. A subscriber wants to access a list of restaurants nearby its location. He/she does not have any positioning capabilities on his/her device. The position of the subscriber is provided by network elements (GMLC/MPC). The following sequence of events take place: A subscriber accesses the telecom operator portal via the wireless network; The portal identifies the service requested by the subscriber and directs the request to a ‘Restaurant Guide’ application running on the GeoMobility Server; this application can also be hosted on a 3rd party server; The requested service sends a request to a GMLC to get the position of the subscriber’s Mobile Terminal; The GMLC provides an estimation of the Mobile Terminal position; Knowing the subscriber position, the ‘Restaurant Guide’ application sends a request, including the returned Mobile Terminal position in the form of a Position ADT, to a Directory Service that returns a list of restaurants within a certain radius around the estimated subscriber position; The list of restaurants is sent back to the subscriber; An application running on the Mobile Terminal allows the subscriber to view and interact with the list. [The next actions the subscriber is likely to take are to select a restaurant from the list and then ask for the directions and route map to assist them in driving from where they are to the chosen restaurant.] An example of sequence for a service request is illustrated in the following figure.

Figure 8. A Typical Service Request/Response

The MLP defined by OMA (formerly LIF) is used to access GMLC/MPC positioning information. GMS resources are accessed through OpenLS APIs. 18 Architecture Details The Operator’s Portal likely hosts the following functions: 1. Front-end functions to support session management, authentication of the subscribers, requests handling, etc. This box can also be a simple relay, transferring requests for services from subscribers to 3rd party applications. 2. LBS support functions for billing, privacy management and roaming. 3. A Service Platform hosting different applications (including proxies to OpenLS Applications that run on the GMS) and various supporting functions to support personalization, context management, etc. The service platform may also access a Location Server through the Gateway Service (based upon OMA 3.0). 4. Optionally, the Service Platform may host OpenLS Applications like ‘Personal Navigator’ and ‘Concierge’. The GMS hosts the following functions:

OpenLS 1.2

1. Possibly, OpenLS Applications, like ‘Personal Navigator’ and ‘Concierge’. These applications access OpenLS Core Services through their APIs. They are the consumers of OpenLS ADTs. 2. OpenLS Core Services (Route, Location Utility, Directory, Presentation, and Gateway). These services are accessible through OpenLS APIs, as defined in the specifications. They in turn access the location content needed to perform their functions. 3. Location Content Databases. Contain any map data, route networks, address data navigation support data, and directories with any place, product or service information. Accessed through OGC Interfaces (Web Feature Server, Web Map Server, Web Coverage Server) or other interfaces, depending on implementation requirements. [More standards work is planned here in future test beds.] 4. OpenLS Applications and Core Services can also access other GMSs and location content databases hosted by 3rd parties. The following figure highlights the functional roles of the Portal, Service Platform, GMS, GMLC/MPC, and 3rd party platforms.

19 General Features The “lang” attribute of the XLS element may be used to specify a preferred language for formatting responses. For example, this attribute may be used to request that route instructions be returned in alternate languages from the Route Service. Valid values for the xls:lang attribute are defined in XML 1.0 ( which references IETF RFC 1766, which inturn are constructed from two-letter language code defined by ISO 639 and from two-letter country codes as defined by ISO 3166). For example: en-GB, en-US, fr srsName attribute of the XLS element may be used to specify the preferred coordinate system to process the request, and return the response in, if supported by the server.

20 Conformance Requirements and Procedures Conformance and Testing for this Implementation Standard must be based upon the normative schema in Annex A. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance, are specified in ISO 19105: Geographic information — Conformance and Testing.

The sponsors of this standard have devised a conformance test requirements and procedures to be defined in a separate document

21 Future Work 21.1 OpenLS 1.0

This specification is the result of nearly two years of effort and implementation testing. Considerable effort has been invested in harmonizing this specification suite with other OGC standards, particularly GML 3.2, and OMA specifications, particularly OMA 3.0. It is the view of the submitters that the results of these harmonization efforts are adequate and sufficient, based upon the requirements defined in this document and the results of implementation and test activities. The submitters recognize that this harmonization process must continue so that every attempt is made to satisfy the needs of the market, to address the feedback received from implementers and other OGC members, and to remain consistent with evolving OGC and OMA specifications. 21.2 OpenLS 1.1

The release of OpenLS 1.1 was meant to offer some fixes to the service schema. No major changes were intended. Changes that might affect the way the services work, will be addressed for a release of OpenLS 2.0. Also, the group has invested considerable time to address the need for a conformance test and work on providing it soon.

14.3 OpenLS 1.2

The release of OpenLS 1.2 was meant to address two specific issues related to the Address ADT and error codes used in this standard. Also, the Geocode request will contain a property that allows the service to return a free-form address vs a strcutred address.

Portal

OpenLS Architecture Detail Front-end Functions

Response Request

-session management -Load balancing -Authentication -Requests routing

Requests passing to 3rd parties

-…

Location-Based Services Realm

LBS Support Functions - Billing, roaming, privacy

Parlay / OSA

Parlay / OSA Service Platform Service suites Service 1 Service 2 Service 3

OpenLS-2 Service mgmnt functions - Provisioning - Personalization - Authentication - Context mgmnt

G M L C / M P C

3rd-Party Content & GMSs

OpenLS Interfaces (w/ Clients on MT)

LIF API

GeoMobility Server (GMS) Position Request

Location content

Position

OpenLS Applications

Requests for 3rd-party content

OpenLS Interfaces

OpenLS

OpenLS Core Services

Requests for 3rd-party GMS Services

OGC Interfaces

Interfaces

Annex A.1: OpenGIS Location Services (OpenLS) Core Services Schema, XML/S Profile (Normative) The OpenLS schema, XML/S Profile, is presented below. ADT.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" xmlns:xls="http://www.opengis.net/xls" elementFormDefault="qualified" version=”1.1”>  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> <include schemaLocation="geometry.xsd"/>  <!-================================================================ ============= Root ADT XML schema types - XLS, ADT and Location ============================================================== ================== --> <attribute name="lang" type="language"/> <element name="_ADT" type="xls:AbstractDataType" abstract="true"> <annotation> <documentation>This is the abstract type that all other abstract types will extend</documentation> </annotation> </element> <complexType name="AbstractDataType"/> <element name="_Location" type="xls:AbstractLocationType" abstract="true" substitutionGroup="xls:_ADT"/> <complexType name="AbstractLocationType" abstract="true"> <annotation> <documentation>Location can be one of four things: Position, POI, Address or Point. Each of those types has been defined in the XLS namespace with this in condiseration. </documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<complexContent> <extension base="xls:AbstractDataType"/> </complexContent> </complexType> <!-================================================================ == Position ADT ============================================================== ======= --> <complexType name="AbstractPositionType" abstract="true"> <complexContent> <extension base="xls:AbstractLocationType"/> </complexContent> </complexType> <element name="_Position" type="xls:AbstractPositionType" abstract="true" substitutionGroup="xls:_Location"/> <complexType name="PositionType"> <complexContent> <extension base="xls:AbstractPositionType"> <sequence> <element ref="gml:Point"/> <choice minOccurs="0"> <element ref="xls:Ellipse"/> <element ref="gml:CircleByCenterPoint"/> <element ref="xls:CircularArc"/> <element ref="gml:Polygon"/> <element ref="gml:MultiPolygon"/> </choice> <element name="QoP" type="xls:QualityOfPositionType" minOccurs="0"> <annotation> <documentation>QoP as defined by LIF.</documentation> </annotation> </element> <element ref="xls:Time" minOccurs="0"/> <element name="Speed" type="xls:SpeedType" minOccurs="0"/> <element name="Direction" type="xls:AngleType" minOccurs="0"/> </sequence> <attribute name="levelOfConf" type="string" use="optional"/> </extension> </complexContent> </complexType> <element name="Position" type="xls:PositionType" substitutionGroup="xls:_Position"> <annotation> <documentation>The Position ADT. Normally used to represent an observation/calculated position for a mobile terminal, but can be any position used Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

by the platform. Contains Point with optional Shape, QoP, Speed, Direction and Time. Also has levelOfConfidence attribute.</documentation> </annotation> </element> <complexType name="QualityOfPositionType"> <sequence> <element name="HorizontalAcc" type="xls:HorAccType"/> <element name="VerticalAcc" type="xls:VerAccType"/> </sequence> <attribute name="responseReq" use="optional" default="Delay_Tol"> <simpleType> <restriction base="string"> <enumeration value="No_Delay"/> <enumeration value="Low_Delay"/> <enumeration value="Delay_Tol"/> </restriction> </simpleType> </attribute> <attribute name="responseTimer" type="string" use="optional"/> </complexType> <complexType name="HorAccType"> <choice> <element ref="xls:Distance"/> <element ref="xls:Angle"/>  </choice> </complexType> <complexType name="VerAccType"> <sequence> <element ref="xls:Distance"/> </sequence> </complexType>  <complexType name="AbstractPOIType" abstract="true"> <complexContent> <extension base="xls:AbstractLocationType"/> </complexContent> </complexType> <element name="_POI" type="xls:AbstractPOIType" substitutionGroup="xls:_Location"> <annotation> <documentation>Point of Interest is a place, product or service with a fixed position, typically identified by name rather than by address and characterized by Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

type, that may be used as a reference point or a target in a location based service request.</documentation> </annotation> </element> <complexType name="PointOfInterestType"> <complexContent> <extension base="xls:AbstractPOIType"> <sequence> <annotation> <documentation> We need to look more closely at this choice block (it's too restrictive). Since we don't have a getCapabilities, there is really no way that a client can discover the information a Directory Service could possibly return. Also, clients have no way to specify which of these information types they want returned (ReferenceSystem, POIInfoList, Point, and/or Address), like we do for GeoCode. Plus, when a Directory Service has two or more of these types, with the choice block there is no way for the a client to receive the full information set. Do we want to change this to a sequence block and/or change POIAttributeList and/or Point to optional? Also, we need to examine the role of POI in this form since it may not return a Point or Address and therefore may not have sufficient info to be used in location services that require a position of some sort. [MM] 17/3/03. Made the change from a choice block to a sequence block. Made the elements optional inside the sequence block </documentation> </annotation> <element ref="xls:POIAttributeList" minOccurs="0"/> <element ref="gml:Point" minOccurs="0"/> <element ref="xls:Address" minOccurs="0"/>  </sequence> <attribute name="ID" type="string" use="required"/> <attribute name="POIName" type="string" use="optional"/> <attribute name="phoneNumber" type="string" use="optional"/> <attribute name="description" type="string" use="optional"/> </extension> </complexContent> </complexType> <element name="POI" type="xls:PointOfInterestType" substitutionGroup="xls:_POI"> <annotation> <documentation>The POI ADT. Primarily generated in the responses from Directory Services. Can also be used as a filter in the request to a Directory Service for nearest/within distance conditions. </documentation> </annotation> </element> <element name="POIAttributeList" type="xls:POIAttributeListType"> <annotation> <documentation>One or more formal name classifications and/or one or more name/value pairs.</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> </element> <complexType name="POIAttributeListType"> <sequence> <element ref="xls:ReferenceSystem" minOccurs="0"/> <element ref="xls:POIInfoList" minOccurs="0"/> </sequence> </complexType> <complexType name="POIInfoListType"> <sequence> <element ref="xls:POIInfo" maxOccurs="unbounded"/> </sequence> </complexType> <element name="POIInfoList" type="xls:POIInfoListType"> <annotation> <documentation>List of other information available about the POI in name/value pairs.</documentation> </annotation> </element> <complexType name="POIInfoType"> <attribute name="name" type="string" use="required"/> <attribute name="value" type="string" use="required"/> </complexType> <element name="POIInfo" type="xls:POIInfoType"> <annotation> <documentation>POI Information defined as a Name/Value pair</documentation> </annotation> </element> <complexType name="ReferenceSystemType"> <sequence> <element ref="xls:_NamedReferenceSystem" maxOccurs="unbounded"/> </sequence> </complexType> <element name="ReferenceSystem" type="xls:ReferenceSystemType"> <annotation> <documentation>Formal name reference system. Three are defined here (NACE, NAICS and SIC), but any others may be defined and added to this schema.</documentation> </annotation> </element> <complexType name="AbstractNamedReferenceSystem" abstract="true"/> <element name="_NamedReferenceSystem" type="xls:AbstractNamedReferenceSystem" abstract="true"/> <complexType name="NAICSType"> <complexContent> <extension base="xls:AbstractNamedReferenceSystem"> <attribute name="type" type="string" use="optional"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<attribute name="subType" type="string" use="optional"/> <attribute name="category" type="string" use="optional"/> </extension> </complexContent> </complexType> <element name="NAICS" type="xls:NAICSType" substitutionGroup="xls:_NamedReferenceSystem"/> <complexType name="SICType"> <complexContent> <extension base="xls:AbstractNamedReferenceSystem"> <attribute name="type" type="string" use="optional"/> <attribute name="subType" type="string" use="optional"/> <attribute name="category" type="string" use="optional"/> <attribute name="code" type="string" use="optional"/> </extension> </complexContent> </complexType> <element name="SIC" type="xls:SICType" substitutionGroup="xls:_NamedReferenceSystem"/> <complexType name="NACEType"> <complexContent> <extension base="xls:AbstractNamedReferenceSystem"> <attribute name="division" type="string" use="optional"/> <attribute name="group" type="string" use="optional"/> <attribute name="class" type="string" use="optional"/> <attribute name="description" type="string" use="optional"/> </extension> </complexContent> </complexType> <element name="NACE" type="xls:NACEType" substitutionGroup="xls:_NamedReferenceSystem"/> <!-================================================================ ============ --> <element name="AOI" type="xls:AreaOfInterestType" substitutionGroup="xls:_ADT"> <annotation> <documentation>The Area of Interest (AOI) ADT. Can be a Circle, Polygon or Point.</documentation> </annotation> </element> <complexType name="AreaOfInterestType"> <complexContent> <extension base="xls:AbstractDataType"> <choice> <element ref="gml:CircleByCenterPoint"/> <element ref="gml:Polygon"/> <element ref="gml:Envelope"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</choice> </extension> </complexContent> </complexType> <!-================================================================ ============= Address ADT definitions ============================================================== ================== --> <complexType name="AbstractAddressType" abstract="true"> <annotation> <documentation> The AddressType is the Address_ADT for OpenLS and it supports the concepts of the OGC Geocoder document 01-026r1 with some modifications which resulted in both simplifications and improved handling capability. The definition is also broad enough to handle some of the more obscure occurrences of street addressing as well as handling the case of when all you have is an un-parsed string representing the complete address. We could generalize this even further to handle non-street addressing schemes found in other industries, such as the Municipal Survey Addressing schemes that are used by Municipalities to address the lots on which a building may be placed but that is probably a future requirement outside the scope of OLS1. </documentation> </annotation>

<complexContent> <extension base="xls:AbstractLocationType"> <attribute name="addressee" type="string" use="optional"/> <attribute name="countryCode" type="xls:CountryCodeType" use="required"/> <attribute name="language" type="language" use="optional"> <annotation> <documentation>the language of the address to be specified. For example, in Canada, this can be used to specify "FR" (French) as the language. By supporting both country code and language, we allow the "locale" of the address to be fully specified, which assists in parsing of freeform addresses. ISO 639 2-Letter code is expected here.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<simpleType name="CountryCodeType"> <annotation> <documentation xml:lang="en"> 3166 Alpha-2 Country Codes </documentation> </annotation> <restriction base="string"> <minLength value="2"/> <maxLength value="3"/> </restriction> </simpleType> <complexType name="StreetAddressType"> <annotation> <documentation>A set of precise and complete data elements that cannot be subdivided and that describe the physical location of a place.</documentation> </annotation> <sequence> <element ref="xls:_StreetLocation" minOccurs="0"/> <element ref="xls:Street" maxOccurs="unbounded"/> </sequence> <attribute name="locator"> <annotation> <documentation>typically used for the street number (e.g. 23) .accommodate a number, or any other building locator. “windmill house”, “24E” and “323” are acceptable uses of the locator.will adopt the following conventions for representing address ranges in the locator attribute:.range example: “1-9” means 1,3,5,7,9.discontinous ranges: “1-9,2-10” implies 1,3,5,7,9 on one side of block and 2,4,6,8,10 on other side of block.range: “1…10” means 1,2,3,4,5,6,7,8,9,10 </documentation> </annotation> </attribute> </complexType> <element name="StreetAddress" type="xls:StreetAddressType"> <annotation> <documentation>Structured street address.</documentation> </annotation> </element> <element name="_StreetLocation" type="xls:AbstractStreetLocatorType"> <annotation> <documentation>The location on a street.</documentation> </annotation> </element> <complexType name="AbstractStreetLocatorType" abstract="true"> <annotation> <documentation>

The AbstractStreetLocatorType is an abstract type for describing the location on a street within an AddressType. We do this because the components of a location on a street vary greatly throughout the world. So that the schema can accommodate this variation we create derived types such as the BuildingLocatorType which has the components for an apartment or suite or floor within a building. </documentation> </annotation> </complexType> <element name="Building" type="xls:BuildingLocatorType" substitutionGroup="xls:_StreetLocation"> <annotation> <documentation>An addressable place; normally a location on a street: number, subdivision name and/or building name.</documentation> </annotation> </element> <complexType name="BuildingLocatorType"> <annotation> <documentation>A type of AbstractStreetLocatorType</documentation> </annotation> <complexContent> <extension base="xls:AbstractStreetLocatorType"> <attribute name="number" type="string" use="optional"/> <attribute name="subdivision" type="string" use="optional"/> <attribute name="buildingName" type="string" use="optional"/> </extension> </complexContent> </complexType> <complexType name="StreetNameType"> <annotation> <documentation>The data elements that make up the name of a street. There are two valid methods for encoding this information: 1). Use the structured elements and attributes. 2). The element value may contain a simplified string (e.g. West 83rd. Street). An example: <Street directionalPrefix="W" officialName="83RD" typeSuffix="ST"/> </documentation> </annotation> <simpleContent> <extension base="string"> <attribute name="directionalPrefix" type="string" use="optional"> <annotation> <documentation>The direction for a street (e.g., North), placed before the official name.</documentation> </annotation> </attribute> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<attribute name="typePrefix" type="string" use="optional"> <annotation> <documentation>The street type (e.g., Rd or Ave) specified before the official name </documentation> </annotation> </attribute> <attribute name="officialName" type="string" use="optional"> <annotation> <documentation> The name for a street (e.g., Main). </documentation> </annotation> </attribute> <attribute name="typeSuffix" type="string" use="optional"> <annotation> <documentation>The street type (e.g., Rd or Ave) specified after the official name</documentation> </annotation> </attribute> <attribute name="directionalSuffix" type="string" use="optional"> <annotation> <documentation>The direction for a street (e.g., North), placed after the official name.</documentation> </annotation> </attribute> <attribute name="muniOctant" type="gml:CompassPointEnumeration" use="optional"/> </extension> </simpleContent> </complexType> <element name="Street" type="xls:StreetNameType"> <annotation> <documentation>Structured Street Name.</documentation> </annotation> </element> <element name="Address" type="xls:AddressType" substitutionGroup="xls:_Location"> <annotation> <documentation>The Address ADT. An address that is either a “Free Form Address” or a “Street Address” or an “Intersection Address”, with 0 or more “place” elements and an optional “postalCode” element. It also has two optional attributes, the “addressee” and the “phone number”, and one required attribute, the “country”.</documentation> </annotation> </element> <complexType name="AddressType"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<documentation>Defines an address</documentation> </annotation> <complexContent> <extension base="xls:AbstractAddressType"> <choice> <element name="freeFormAddress" type="string"> <annotation> <documentation>An unstructured free form address.</documentation> </annotation> </element> <sequence> <element ref="xls:StreetAddress"/> <element ref="xls:Place" minOccurs="0" maxOccurs="unbounded"/> <element ref="xls:PostalCode" minOccurs="0"/> </sequence> </choice> </extension> </complexContent> </complexType> <simpleType name="NamedPlaceClassification"> <annotation> <documentation>The classification for the hierarchy a level of which is defined to be one of five different types: CountrySubDivision, CountrySecondarySubdivision, Municipality, or MunicipalitySubdivision.</documentation> </annotation> <restriction base="string"> <enumeration value="CountrySubdivision"/> <enumeration value="CountrySecondarySubdivision"/> <enumeration value="Municipality"/> <enumeration value="MunicipalitySubdivision"/> <enumeration value="choume-banchi-go"/> </restriction> </simpleType> <element name="Place" type="xls:NamedPlaceType"> <annotation> <documentation>Place represents a hierarchical set of geographic regions/placenames: country subdivision, country secondary subdivision, municipality, and municipality subdivision.</documentation> </annotation> </element> <complexType name="NamedPlaceType"> <annotation> <documentation> The NamedPlaceType defines a named place within an AddressType. Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

A named place has a classification (such as country, country subdivision, or municipality). </documentation> </annotation> <simpleContent> <extension base="string"> <attribute name="type" type="xls:NamedPlaceClassification" use="required"/> </extension> </simpleContent> </complexType> <element name="PostalCode" type="xls:PostalCodeType"> <annotation> <documentation>A zipcode or international postal code as defined by the governing postal authority.</documentation> </annotation> </element> <simpleType name="PostalCodeType"> <annotation> <documentation> The AbstractPostalCodeType is an abstract type for postal code within an AddressType. We do this because the components of a postal code vary greatly throughout the world. So that the schema can accommodate this variation we create derived types such as the USZipCodeType which has the components for a US zipcode </documentation> </annotation> <restriction base="string"/> </simpleType>  <annotation> <documentation>These types don't fit well with ADTs, rather with Location Utility. Should move them. Also, GeocodingQOSType should be renamed GeocodeMatchCodeType, for consistency, or the element GeocodeMatchCode should be renamed GeocodingQOS.</documentation> </annotation> <element name="GeocodeMatchCode" type="xls:GeocodingQOSType"> <annotation> <documentation>Provides information on the quality of the match operation (accuracy and match code).</documentation> </annotation> </element> <complexType name="GeocodingQOSType"> <annotation> <documentation>Quality of service type</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> <attribute name="accuracy" type="float" use="optional"> <annotation> <documentation>This is the score (probability) assocaited with the match function</documentation> </annotation> </attribute> <attribute name="matchType" type="string" use="optional"> <annotation> <documentation>Describes the type of match made by the function, example zip+4</documentation> </annotation> </attribute> </complexType>  <element name="Map" type="xls:MapType" substitutionGroup="xls:_ADT"/> <complexType name="MapType"> <complexContent> <extension base="xls:AbstractDataType"> <sequence minOccurs="0"> <element name="Content" type="xls:ContentType"/> <choice> <element name="BBoxContext" type="gml:EnvelopeType"/> <element name="CenterContext" type="xls:CenterContextType"/>  </choice> </sequence> </extension> </complexContent> </complexType> <complexType name="ContentType"> <choice> <element name="Data" type="string"> <annotation> <documentation>Map data embeded into the xml (if map data is binary then it is base64 encoded) </documentation> </annotation> </element> <element name="URL" type="string"> <annotation> <documentation>The Data can be found at this URL</documentation> </annotation> </element> </choice> <attribute name="format" type="string" use="required"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<attribute name="width" type="integer" use="required"/> <attribute name="height" type="integer" use="required"/> </complexType> <complexType name="CenterContextType"> <sequence> <element name="CenterPoint" type="gml:PointType"> <annotation> <documentation>lat/long WGS84 point to center the map on</documentation> </annotation>  </element> <choice> <sequence> <element name="DisplayScale" type="integer"> <annotation> <documentation>A ratio of distance. For example 1:5000 would be expressed as 5000, it's always expressed per 1 pixel of the display</documentation> </annotation> </element> <element name="DPI" type="integer"> <annotation> <documentation>Dots per Inch of the display device.</documentation> </annotation> </element> </sequence> <sequence> <element name="Radius" type="xls:RadiusType"> <annotation> <documentation>This defines the area that will be required to be displayed</documentation> </annotation> </element> </sequence> </choice> </sequence> <attribute name="azimuth" type="integer" use="optional"> <annotation> <documentation>The orientation of the map, clockwise degrees from north.</documentation> </annotation> </attribute> <attribute name="SRS" type="string" use="required"> <annotation>

<documentation>The Spatial Reference System that the data with be projected to in EPSG:XXXX format (getCapabilites provides the list of SRS's supported).</documentation> </annotation> </attribute> </complexType> <complexType name="RadiusType"> <simpleContent> <extension base="decimal"> <attribute name="unit" type="xls:DistanceUnitType" use="required"/> </extension> </simpleContent> </complexType> <!-============================================================== ================= Route Abstract Types ============================================================== ====================== --> <complexType name="AbstractRouteSummaryType" abstract="true"> <annotation> <documentation>Abstract type which specifies a route's overall characteristics.</documentation> </annotation> <complexContent> <extension base="xls:AbstractDataType"> <sequence> <element name="TotalTime" type="duration"> <annotation> <documentation>Estimated time to travel the complete route. Expressed as a duration as defined by W3C. reference URL: http://www.w3c.org/TR/xmlschema-2/</documentation> </annotation> </element> <element name="TotalDistance" type="xls:DistanceType"> <annotation> <documentation>Total distance covered by the route.</documentation> </annotation> </element> <element ref="xls:BoundingBox"> <annotation> <documentation>Rectangular area bounding the complete route.</documentation> </annotation> </element> </sequence> </extension> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

</complexContent> </complexType> <element name="_RouteSummary" type="xls:AbstractRouteSummaryType" abstract="true" substitutionGroup="xls:_ADT"> <annotation> <documentation>Base element which represents a route's overall characteristics.</documentation> </annotation> </element> <complexType name="AbstractRouteSegmentType" abstract="true"> <annotation> <documentation>Defines the characteristics of a segment along a route.</documentation> </annotation> <sequence> <element ref="xls:Distance"> <annotation> <documentation>Distance along the segment.</documentation> </annotation> </element> <element name="TravelTime" type="duration"> <annotation> <documentation>Estimated time to travel the complete route, Expressed as a duration as defined by W3C. reference URL: http://www.w3c.org/TR/xmlschema-2</documentation> </annotation> </element> <element ref="xls:BoundingBox"> <annotation> <documentation>Rectangular area bounding the segment.</documentation> </annotation> </element> </sequence> <attribute name="name" type="string" use="optional"> <annotation> <documentation>Name of segment, e.g.: street name, or the name of the public transit line. When the name is unknown, this should be an empty string. When not specified, the name is assumed to be the same as the previous segment.</documentation> </annotation> </attribute> </complexType> <element name="_NextSegment" type="xls:AbstractRouteSegmentType" abstract="true"> <annotation> <documentation>Base element which represents the information about the segment of the route between the current maneuver and the next.</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> </element> <complexType name="AbstractWayPointType" abstract="true"> <annotation> <documentation>Abstract type representing a location to be visited along a route.</documentation> </annotation> </complexType> <element name="_WayPoint" type="xls:AbstractWayPointType" abstract="true"> <annotation> <documentation>A location to be visited along a route.</documentation> </annotation> </element> <!-============================================================== ================= Route ADT ============================================================== ====================== --> <complexType name="RouteSummaryType"> <annotation> <documentation>Specifies a route's overall characteristics.</documentation> </annotation> <complexContent> <extension base="xls:AbstractRouteSummaryType"/> </complexContent> </complexType> <element name="RouteSummary" type="xls:RouteSummaryType" substitutionGroup="xls:_RouteSummary"> <annotation> <documentation>A route's overall characteristics.</documentation> </annotation> </element> <element name="BoundingBox" type="gml:EnvelopeType"> <annotation> <documentation>Rectangular bounding area.</documentation> </annotation>  </element> <complexType name="RouteSegmentType"> <annotation> <documentation>Defines the characteristics of a segment along a route.</documentation> </annotation> <complexContent> <extension base="xls:AbstractRouteSegmentType"/> </complexContent> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

</complexType> <element name="NextSegment" type="xls:RouteSegmentType" substitutionGroup="xls:_NextSegment"> <annotation> <documentation>Information about the segment of the route between this maneuver and the next.</documentation> </annotation> </element> <complexType name="WayPointType"> <annotation> <documentation>Defines a location to be visited along a route.</documentation> </annotation> <complexContent> <extension base="xls:AbstractWayPointType"> <sequence> <element ref="xls:_Location"/> <element ref="xls:GeocodeMatchCode" minOccurs="0"/> </sequence> <attribute name="stop" type="boolean" use="optional" default="true"> <annotation> <documentation>Specifies whether the traveler plans to stop at the waypoint, or simply pass through it. </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="StartPoint" type="xls:WayPointType" substitutionGroup="xls:_WayPoint"> <annotation> <documentation>Starting point of the route.</documentation> </annotation> </element> <element name="ViaPoint" type="xls:WayPointType" substitutionGroup="xls:_WayPoint"> <annotation> <documentation>Intermediate waypoint along the route.</documentation> </annotation> </element> <element name="EndPoint" type="xls:WayPointType" substitutionGroup="xls:_WayPoint"> <annotation> <documentation>Ending point of the route (i.e. the destination)</documentation> </annotation> </element> <complexType name="WayPointListType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<annotation> <documentation>Defines a list of waypoints along a route.</documentation> </annotation> <sequence> <element ref="xls:StartPoint"/> <element ref="xls:ViaPoint" minOccurs="0" maxOccurs="unbounded"/> <element ref="xls:EndPoint"/> </sequence> </complexType> <element name="WayPointList" type="xls:WayPointListType"> <annotation> <documentation>List of waypoints along a route.</documentation> </annotation> </element> <element name="RouteInstructionsList" type="xls:RouteInstructionsListType" substitutionGroup="xls:_ADT"> <annotation> <documentation>A list of route instructions.</documentation> </annotation> </element> <complexType name="RouteInstructionsListType"> <annotation> <documentation>Defines a list of route instructions.</documentation> </annotation> <complexContent> <extension base="xls:AbstractDataType"> <sequence> <element ref="xls:RouteInstruction" maxOccurs="unbounded"/> </sequence> <attribute name="format" type="string" use="optional" default="text/plain"> <annotation> <documentation>Mime type describing the encoding.</documentation> </annotation> </attribute> <attribute ref="xls:lang" use="required"> <annotation> <documentation>Specifies the language in which the instructions are given.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <complexType name="RouteInstructionType"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<documentation>Defines a single turn-by-turn route instruction or advisory formatted for presentation.</documentation> </annotation> <sequence> <element name="Instruction" type="string"/> <element name="distance" type="xls:DistanceType"/> <element name="RouteInstructionGeometry" type="xls:RouteGeometryType" minOccurs="0"/> <element name="BoundingBox" type="gml:EnvelopeType" minOccurs="0"/> </sequence> <attribute name="duration" type="duration" use="required"> <annotation> <documentation>Specifies the duration needed to execute those instructions. Duration is expressed as defined in the W3C defintion. Reference URL: http://www.w3c.org/TR/xmlschema-2/</documentation> </annotation> </attribute> <attribute name="description" type="string"> <annotation> <documentation>Allows the route instruction to be matched with a RouteMapType. For example "maneuver 1"</documentation> </annotation> </attribute> </complexType> <element name="RouteInstruction" type="xls:RouteInstructionType"> <annotation> <documentation>A turn-by-turn route instruction or advisory formatted for presentation.</documentation> </annotation> </element> <element name="RouteHandle" type="xls:RouteHandleType"> <annotation> <documentation>A reference to a route stored at the Route Determination Service server.</documentation> </annotation> </element> <complexType name="RouteHandleType"> <annotation> <documentation>Defines a reference to a route stored at the Route Determination Service server.</documentation> </annotation> <attribute name="serviceID" type="string" use="optional"> <annotation> <documentation>Uniquely identifies the service which holds the route.</documentation> </annotation> </attribute> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<attribute name="routeID" type="string" use="required"> <annotation> <documentation>Uniquely identifies the route store at the service.</documentation> </annotation> </attribute> </complexType> <complexType name="RouteGeometryType"> <annotation> <documentation>Defines the geometry of a route.</documentation> </annotation> <complexContent> <extension base="xls:AbstractDataType"> <sequence> <element ref="gml:LineString"/>  </sequence> </extension> </complexContent> </complexType> <element name="RouteGeometry" type="xls:RouteGeometryType" substitutionGroup="xls:_ADT"> <annotation> <documentation>Geometry of a route.</documentation> </annotation> </element> </schema>

gml4xls.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1"> <annotation> <documentation>Copyright (c) 2003 OGC, All Rights Reserved - This OGC document is a draft and is copyright-protected by OGC. While the reproduction of drafts in any form for use by participants in the OGC Interoperability Program is permitted without prior permission from OGC, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from OGC.</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 69

OpenLS 1.2

<annotation> <documentation>GML Subset schema for gml:_Object,gml:metaDataProperty,gml:_association,gml:AssociationType,gml:m embers,gml:Array,gml:curveProperty,gml:LineString,gml:LinearRing,gml:exterior, gml:interior,gml:Polygon,gml:surfaceMember,gml:surfaceProperty,gml:MultiSurfa ce,gml:multiSurfaceProperty,gml:SurfaceInterpolationType,gml_Feature,gml:feat ureProperty,gml:featureMembers,gml:_FeatureCollection,gml:featureMember,gm l:featureMembers,gml:_FeatureCollection,gml:Dictionary,gml:doubleList,gml:pos, gml:pointRep,gml:CircleByCenterPoint, written by gmlSubset.xslt. Created using Saxon XSLT processor with the following command 2002-020-13 Paul Daisey U.S. Census $ java com.icl.saxon.StyleSheet -o gml4xls.xsd gmldep.xml gmlSubset.xslt // output file input file stylesheet 2003-03-05 - SJDC - commented out various pieces to create a more restricted profile of GML for XLS use. All changes indicated [SJDC] 2003-03-14 - Marwa Mabrouk - Removed a lot of types only leaving the exact types used by XLS. And made editorial changes to clean up the schema and only leave the types used. The fully commented schema will be retained separately for those interested in researching it </documentation> </annotation> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlinks.xsd"/>  <element name="_Object" abstract="true"> <annotation> <documentation>This abstract element is the head of a substitutionGroup hierararchy which may contain either simpleContent or complexContent elements. It is used to assert the model position of "class" elements declared in other GML schemas. </documentation> </annotation> </element>  <attribute name="id" type="ID"> <annotation> <documentation>Database handle for the object. It is of XML type “ID”, so is constrained to be unique in the XML document within which it occurs. An external identifier for the object in the form of a URI may be constructed using standard XML and XPointer methods. This is done by concatenating the URI for the document, a fragment separator “#”, and the value of the id attribute. </documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> </attribute>  <complexType name="AbstractGMLType" abstract="true"> <annotation> <documentation>All complexContent GML elements are directly or indirectly derived from this abstract supertype to establish a hierarchy of GML types that may be distinguished from other XML types by their ancestry. Elements in this hierarchy may have an ID and are thus referenceable. </documentation> </annotation> <attribute ref="gml:id" use="optional"/> </complexType>  <element name="_GML" type="gml:AbstractGMLType" abstract="true" substitutionGroup="gml:_Object"> <annotation> <documentation>Global element which acts as the head of a substitution group that may include any element which is a GML feature, object, geometry or complex value</documentation> </annotation> </element>  <element name="_Curve" type="gml:AbstractCurveType" abstract="true" substitutionGroup="gml:_GeometricPrimitive"> <annotation> <documentation>The "_Curve" element is the abstract head of the substituition group for all (continuous) curve elements.</documentation> </annotation> </element>  <complexType name="AbstractCurveType" abstract="true"> <annotation> <documentation>An abstraction of a curve to support the different levels of complexity. The curve can always be viewed as a geometric primitive, i.e. is continuous.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometricPrimitiveType"/> </complexContent> </complexType>  <complexType name="AbstractGeometricPrimitiveType" abstract="true"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<documentation>This is the abstract root type of the geometric primitives. A geometric primitive is a geometric object that is not decomposed further into other primitives in the system. All primitives are oriented in the direction implied by the sequence of their coordinate tuples.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometryType"/> </complexContent> </complexType>  <complexType name="AbstractGeometryType" abstract="true"> <annotation> <documentation>All geometry elements are derived directly or indirectly from this abstract supertype. A geometry element may have an identifying attribute ("gml:id"), a name (attribute "name") and a description (attribute "description"). It may be associated with a spatial reference system (attribute "srsName"). The following rules shall be adhered: - Every geometry type shall derive from this abstract type. - Every geometry element (i.e. an element of a geometry type) shall be directly or indirectly in the substitution group of _Geometry.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGMLType"> <attribute name="gid" type="string" use="optional"> <annotation> <documentation>This attribute is included for backward compatibility with GML 2 and is deprecated with GML 3. This identifer is superceded by "gml:id" inherited from AbstractGMLType. The attribute "gid" should not be used anymore and may be deleted in future versions of GML without further notice.</documentation> </annotation> </attribute> <attribute name="srsName" type="anyURI" use="optional"> <annotation> <documentation>In general this reference points to a CRS instance of gml:CoordinateReferenceSystemType (see coordinateReferenceSystems.xsd). For well known references it is not required that the CRS description exists at the location the URI points to (Note: These "WKCRS"-ids still have to be specified). If no srsName attribute is given, the CRS must be specified as part of the larger context this geometry element is part of, e.g. a geometric aggregate.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<element name="_GeometricPrimitive" type="gml:AbstractGeometricPrimitiveType" abstract="true" substitutionGroup="gml:_Geometry"> <annotation> <documentation>The "_GeometricPrimitive" element is the abstract head of the substituition group for all (pre- and user-defined) geometric primitives.</documentation> </annotation> </element>  <element name="_Geometry" type="gml:AbstractGeometryType" abstract="true" substitutionGroup="gml:_GML"> <annotation> <documentation>The "_Geometry" element is the abstract head of the substituition group for all geometry elements of GML 3. This includes pre-defined and user-defined geometry elements. Any geometry element must be a direct or indirect extension/restriction of AbstractGeometryType and must be directly or indirectly in the substitution group of "_Geometry".</documentation> </annotation> </element>  <element name="LineString" type="gml:LineStringType" substitutionGroup="gml:_Curve"/>  <complexType name="LineStringType"> <annotation> <documentation> A LineString is a special curve that consists of a single segment with linear interpolation. It is defined by two or more coordinate tuples, with linear interpolation between them. It is backwards compatible with the LineString of GML 2, GM_LineString of ISO 19107 is implemented by LineStringSegment. </documentation> </annotation> <complexContent> <extension base="gml:AbstractCurveType"> <sequence> <annotation> <documentation>GML supports two different ways to specify the control points of a line string. 1. A sequence of "pos" (DirectPositionType) or "pointRep" (PointPropertyType) elements. "pos" elements are control points that are only part of this curve, "pointRep" elements contain a point that may be referenced from other geometry elements or reference another point defined outside of this curve (reuse of existing points). 2. The "coordinates" element allows for a compact way to specifiy the coordinates of the control points, if all control points are in the same coordinate reference systems and belong to this Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

curve only. The number of direct positions in the coordinates list must be at least two.</documentation> </annotation> <element ref="gml:pos" minOccurs="2" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <element name="pos" type="gml:DirectPositionType"/>  <complexType name="DirectPositionType"> <annotation> <documentation>DirectPosition instances hold the coordinates for a position within some coordinate reference system (CRS). Since DirectPositions, as data types, will often be included in larger objects (such as geometry elements) that have references to CRS, the "srsName" attribute will in general be missing, if this particular DirectPosition is included in a larger element with such a reference to a CRS. In this case, the CRS is implicitly assumed to take on the value of the containing object's CRS.</documentation> </annotation> <simpleContent> <extension base="gml:doubleList"> <attribute name="srsName" type="anyURI" use="optional"> <annotation> <documentation>In general this reference points to a CRS instance of gml:CoordinateReferenceSystemType (see coordinateReferenceSystems.xsd). For well known references it is not required that the CRS description exists at the location the URI points to (Note: These "WKCRS"-ids still have to be specified). If no srsName attribute is given, the CRS must be specified as part of the larger context this geometry element is part of, e.g. a geometric element like point, curve, etc. It is expected that the attribute will be specified at the direct position level only in rare cases.</documentation> </annotation> </attribute> <attribute name="dimension" type="positiveInteger" use="optional"> <annotation> <documentation>The attribute "dimension" is the length of coordinate sequence (the number of entries in the list). This is determined by the coordinate reference system.</documentation> </annotation> </attribute> </extension> </simpleContent> </complexType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<simpleType name="doubleList"> <annotation> <documentation>XML List based on XML Schema double type. An element of this type contains a space-separated list of double values</documentation> </annotation> <list itemType="double"/> </simpleType>  <element name="Point" type="gml:PointType" substitutionGroup="gml:_GeometricPrimitive"/>  <complexType name="PointType"> <annotation> <documentation>A Point is defined by a single coordinate tuple.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometricPrimitiveType"> <sequence> <annotation> <documentation>GML supports two different ways to specify the direct poisiton of a point. 1. The "pos" element is of type DirectPositionType. </documentation> </annotation> <element ref="gml:pos"/> </sequence> </extension> </complexContent> </complexType>  <element name="LinearRing" type="gml:LinearRingType" substitutionGroup="gml:_Ring"/>  <complexType name="LinearRingType"> <annotation> <documentation>A LinearRing is defined by four or more coordinate tuples, with linear interpolation between them; the first and last coordinates must be coincident.</documentation> </annotation> <complexContent> <extension base="gml:AbstractRingType"> <sequence> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<documentation>GML supports two different ways to specify the control points of a linear ring. 1. A sequence of "pos" (DirectPositionType) or "pointRep" (PointPropertyType) elements. "pos" elements are control points that are only part of this ring, "pointRep" elements contain a point that may be referenced from other geometry elements or reference another point defined outside of this ring (reuse of existing points). 2. The "coordinates" element allows for a compact way to specifiy the coordinates of the control points, if all control points are in the same coordinate reference systems and belong to this ring only. The number of direct positions in the coordinate list must be at least four.</documentation> </annotation> <element ref="gml:pos" minOccurs="4" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <complexType name="AbstractRingType" abstract="true"> <annotation> <documentation> An abstraction of a ring to support surface boundaries of different complexity. </documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometryType"/> </complexContent> </complexType>  <element name="_Ring" type="gml:AbstractRingType" abstract="true" substitutionGroup="gml:_Geometry"> <annotation> <documentation>The "_Ring" element is the abstract head of the substituition group for all closed boundaries of a surface patch.</documentation> </annotation> </element>  <element name="exterior" type="gml:AbstractRingPropertyType"> <annotation> <documentation>A boundary of a surface consists of a number of rings. In the normal 2D case, one of these rings is distinguished as being the exterior boundary. In a general manifold this is not always possible, in which case all boundaries shall be listed as interior boundaries, and the exterior will be empty.</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> </element>  <complexType name="AbstractRingPropertyType"> <annotation> <documentation> Encapsulates a ring to represent the surface boundary property of a surface. </documentation> </annotation> <sequence> <element ref="gml:_Ring"/> </sequence> </complexType>  <element name="interior" type="gml:AbstractRingPropertyType"> <annotation> <documentation>A boundary of a surface consists of a number of rings. The "interior" rings seperate the surface / surface patch from the area enclosed by the rings.</documentation> </annotation> </element>  <element name="Polygon" type="gml:PolygonType" substitutionGroup="gml:_Surface"/>  <complexType name="PolygonType"> <annotation> <documentation>A Polygon is a special surface that is defined by a single surface patch. The boundary of this patch is coplanar and the polygon uses planar interpolation in its interior. It is backwards compatible with the Polygon of GML 2, GM_Polygon of ISO 19107 is implemented by PolygonPatch.</documentation> </annotation> <complexContent> <extension base="gml:AbstractSurfaceType"> <sequence> <element ref="gml:exterior" minOccurs="0"/> <element ref="gml:interior" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <complexType name="AbstractSurfaceType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 77

OpenLS 1.2

<annotation> <documentation> An abstraction of a surface to support the different levels of complexity. A surface is always a continuous region of a plane. </documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometricPrimitiveType"/> </complexContent> </complexType>  <element name="_Surface" type="gml:AbstractSurfaceType" abstract="true" substitutionGroup="gml:_GeometricPrimitive"> <annotation> <documentation>The "_Surface" element is the abstract head of the substituition group for all (continuous) surface elements.</documentation> </annotation> </element>  <complexType name="AbstractGeometricAggregateType" abstract="true"> <annotation> <documentation>This is the abstract root type of the geometric aggregates.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometryType"/> </complexContent> </complexType>  <element name="_GeometricAggregate" type="gml:AbstractGeometricAggregateType" abstract="true" substitutionGroup="gml:_Geometry"> <annotation> <documentation>The "_GeometricAggregate" element is the abstract head of the substituition group for all geometric aggremates.</documentation> </annotation> </element>  <element name="MultiPolygon" type="gml:MultiPolygonType" substitutionGroup="gml:_GeometricAggregate"> <annotation> <documentation>Use the "MultiSurface" element instead.</documentation> </annotation> </element> <complexType name="MultiPolygonType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<annotation> <documentation> A MultiPolygon is defined by one or more Polygons, referenced through polygonMember elements. </documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometricAggregateType"> <sequence> <element ref="gml:polygonMember" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <element name="polygonMember" type="gml:PolygonPropertyType"> <annotation> <documentation>This property element either references a polygon via the XLink-attributes or contains the polygon element.</documentation> </annotation> </element> <complexType name="PolygonPropertyType"> <annotation> <documentation>A property that has a polygon as its value domain can either be an appropriate geometry element encapsulated in an element of this type or an XLink reference to a remote geometry element (where remote includes geometry elements located elsewhere in the same document). Either the reference or the contained element must be given, but neither both nor none.</documentation> </annotation> <sequence> <element ref="gml:Polygon" minOccurs="0"/> </sequence> </complexType>  <simpleType name="SurfaceInterpolationType"> <annotation> <documentation>SurfaceInterpolationType is a list of codes that may be used to identify the interpolation mechanisms specified by an application schema.</documentation> </annotation> <restriction base="string"> <enumeration value="none"/> <enumeration value="planar"/> <enumeration value="spherical"/> </restriction> </simpleType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 79

OpenLS 1.2

<element name="boundedBy" type="gml:BoundingShapeType"/>  <complexType name="BoundingShapeType"> <annotation> <documentation>Bounding shape.</documentation> </annotation> <sequence> <group ref="gml:boundingShape"/> </sequence> </complexType>  <group name="boundingShape"> <choice> <element ref="gml:Envelope"/> <element ref="gml:Null"/> </choice> </group>  <element name="Envelope" type="gml:EnvelopeType" substitutionGroup="gml:_Geometry"/>  <complexType name="EnvelopeType"> <annotation> <documentation>Envelope defines an extent using a pair of positions defining opposite corners in arbitrary dimensions.</documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometryType"> <sequence> <element ref="gml:pos" minOccurs="2" maxOccurs="2"/> </sequence> </extension> </complexContent> </complexType>  <element name="Null" type="gml:NullType"/>  <simpleType name="NullType"> <annotation> <documentation>Utility type for null elements. The value may be selected from one of the enumerated tokens, or may be a URI in which case this should identify a resource which describes the reason for the null. </documentation> </annotation> <union memberTypes="gml:NullEnumeration anyURI"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</simpleType>  <simpleType name="NullEnumeration"> <annotation> <documentation> Some common reasons for a null value: innapplicable - the object does not have a value missing - The correct value is not readily available to the sender of this data. Furthermore, a correct value may not exist. template - the value will be available later unknown - The correct value is not known to, and not computable by, the sender of this data. However, a correct value probably exists. withheld - the value is not divulged Specific communities may agree to assign more strict semantics when these terms are used in a particular context. </documentation> </annotation> <restriction base="string"> <enumeration value="inapplicable"/> <enumeration value="missing"/> <enumeration value="template"/> <enumeration value="unknown"/> <enumeration value="withheld"/> </restriction> </simpleType>  <element name="CircleByCenterPoint" type="gml:CircleByCenterPointType" substitutionGroup="gml:ArcByCenterPoint"/>  <complexType name="CircleByCenterPointType"> <annotation> <documentation>A CircleByCenterPoint is an ArcByCenterPoint with identical start and end angle to form a full circle. Again, this represenation can be used only in 2D.</documentation> </annotation> <complexContent> <extension base="gml:ArcByCenterPointType"/> </complexContent> </complexType>  <complexType name="ArcByCenterPointType"> <annotation> <documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

This variant of the arc requires that the points on the arc have to be computed instead of storing the coordinates directly. The control point is the center point of the arc plus the radius and the bearing at start and end. This represenation can be used only in 2D. </documentation> </annotation> <complexContent> <extension base="gml:AbstractCurveSegmentType"> <sequence> <annotation> <documentation>GML supports two different ways to specify the control points of a curve segment. 1. A "pos" (DirectPositionType) or "pointRep" (PointPropertyType) element. The "pos" element contains a center point that is only part of this curve segment, a "pointRep" element contains a point that may be referenced from other geometry elements or reference another point defined outside of this curve segment (reuse of existing points). 2. The "coordinates" element can be used to specifiy the coordinates of the center point, too. The number of direct positions in the coordinate list must be one.</documentation> </annotation> <element ref="gml:pos"/> <element name="radius" type="gml:LengthType"> <annotation> <documentation>The radius of the arc.</documentation> </annotation> </element> <element name="startAngle" type="gml:AngleType" minOccurs="0"> <annotation> <documentation>The bearing of the arc at the start. This type is used by GML 3 geometry in this schema file only</documentation> </annotation> </element> <element name="endAngle" type="gml:AngleType" minOccurs="0"> <annotation> <documentation>The bearing of the arc at the end.</documentation> </annotation> </element> </sequence> <attribute name="interpolation" type="gml:CurveInterpolationType" fixed="circularArcCenterPointWithRadius"> <annotation>

<documentation>The attribute "interpolation" specifies the curve interpolation mechanism used for this segment. This mechanism uses the control points and control parameters to determine the position of this curve segment. For an ArcByCenterPoint the interpolation is fixed as "circularArcCenterPointWithRadius".</documentation> </annotation> </attribute> <attribute name="numArc" type="integer" use="required" fixed="1"> <annotation> <documentation>Since this type describes always a single arc, the attribute is fixed to "1".</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>  <complexType name="AbstractCurveSegmentType" abstract="true"> <annotation> <documentation> Curve segment defines a homogeneous segment of a curve. </documentation> </annotation> </complexType>  <simpleType name="CurveInterpolationType"> <annotation> <documentation>CurveInterpolationType is a list of codes that may be used to identify the interpolation mechanisms specified by an application schema.</documentation> </annotation> <restriction base="string"> <enumeration value="linear"/> <enumeration value="geodesic"/> <enumeration value="circularArcCenterPointWithRadius"/> </restriction> </simpleType>  <element name="ArcByCenterPoint" type="gml:ArcByCenterPointType" substitutionGroup="gml:_CurveSegment"/>  <element name="_CurveSegment" type="gml:AbstractCurveSegmentType" abstract="true"> <annotation>

OpenLS 1.2

<documentation>The "_CurveSegment" element is the abstract head of the substituition group for all curve segment elements, i.e. continuous segments of the same interpolation mechanism.</documentation> </annotation> </element>  <complexType name="LengthType"> <annotation> <documentation>Value of a length (or distance) quantity, with its units. Uses the MeasureType with the restriction that the unit of measure referenced by uom must be suitable for a length, such as metres or feet. </documentation> </annotation> <simpleContent> <extension base="gml:MeasureType"/> </simpleContent> </complexType>  <complexType name="MeasureType"> <annotation> <documentation>Number with a scale. The value of uom (Units Of Measure) attribute is a reference to a Reference System for the amount, either a ratio or position scale. </documentation> </annotation> <simpleContent> <extension base="double"> <attribute name="uom" type="anyURI" use="required"/> </extension> </simpleContent> </complexType>  <complexType name="AngleType"> <annotation> <documentation>Value of an angle quantity recorded as a single number, with its units. Uses the MeasureType with the restriction that the unit of measure referenced by uom must be suitable for an angle, such as degrees or radians. </documentation> </annotation> <simpleContent> <extension base="gml:MeasureType"/> </simpleContent> </complexType> <!-============================================================= ====== --> <element name="CompassPoint" type="gml:CompassPointEnumeration"/>

<!-============================================================= ====== --> <simpleType name="CompassPointEnumeration"> <restriction base="string"> <enumeration value="N"/> <enumeration value="NNE"/> <enumeration value="NE"/> <enumeration value="ENE"/> <enumeration value="E"/> <enumeration value="ESE"/> <enumeration value="SE"/> <enumeration value="SSE"/> <enumeration value="S"/> <enumeration value="SSW"/> <enumeration value="SW"/> <enumeration value="WSW"/> <enumeration value="W"/> <enumeration value="WNW"/> <enumeration value="NW"/> <enumeration value="NNW"/> </restriction> </simpleType> <!-============================================================= ====== --> </schema>

XLS.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="1.1">  <include schemaLocation="ADT.xsd"/> <element name="XLS" type="xls:XLSType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<annotation> <documentation>The top element of an OpenLS request-response message; an XML document.</documentation> </annotation> </element> <complexType name="XLSType"> <annotation> <documentation>Defines the top element of an XML document representing a message.</documentation> </annotation> <sequence> <element ref="xls:_Header"/> <element ref="xls:_Body" maxOccurs="unbounded"/> </sequence> <attribute name="version" type="decimal" use="required"/> <attribute ref="xls:lang" use="optional"> <annotation> <documentation>Defines the preferred language used for formatting responses. </documentation> </annotation> </attribute> </complexType> <element name="_Header" type="xls:AbstractHeaderType" abstract="true"> <annotation> <documentation>Defines the portion of a message that contains header information; see _Body for the specific information needed to execute a request.</documentation> <documentation>Base element representing all types of header information.</documentation> </annotation> </element> <complexType name="AbstractHeaderType" abstract="true"> <annotation> <documentation>Defines the portion of a message that contains information orthogonal to the specific information needed to execute a request. Typical header information includes infomation associated with authentication and authorization, transaction management, payment processing, tracing and auditing.</documentation> <documentation>Abstract type common to all types of header information.</documentation> </annotation> </complexType> <element name="_Body" type="xls:AbstractBodyType" abstract="true"> <annotation> <documentation>The portion of a message containing information that is core to the message; the request-response pair.</documentation> <documentation>Base element representing all types of body information.</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</annotation> </element> <complexType name="AbstractBodyType" abstract="true"> <annotation> <documentation>Defines the portion of a message containing information that is core to the message.</documentation> <documentation>Abstract type common to all types of body information.</documentation> </annotation> </complexType> <element name="RequestHeader" type="xls:RequestHeaderType" substitutionGroup="xls:_Header"> <annotation> <documentation>The header information for request messages.</documentation> </annotation> </element> <complexType name="RequestHeaderType"> <annotation> <documentation>Defines the header information for request messages.</documentation> </annotation> <complexContent> <extension base="xls:AbstractHeaderType"> <attribute name="clientName" type="string" use="optional"> <annotation> <documentation>The client name, used for authentication.</documentation> </annotation> </attribute> <attribute name="clientPassword" type="string" use="optional"> <annotation> <documentation/> <documentation>The client password, used for authentication.</documentation> </annotation> </attribute> <attribute name="sessionID" type="string" use="optional"> <annotation> <documentation>A client-defined unique session Iidentifier, which should be returned in the response header.</documentation> </annotation> </attribute> <attribute name="srsName" type="anyURI" use="optional"> <annotation> <documentation>In general this reference points to a CRS instance of gml:CoordinateReferenceSystemType (see coordinateReferenceSystems.xsd). For well known references it is not required that Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

the CRS description exists at the location the URI points to (Note: These "WKCRS"ids still have to be specified). If no srsName attribute is given, the CRS must be specified as part of the larger context this geometry element is part of, e.g. a geometric aggregate. Default value is WGS84</documentation> </annotation> </attribute> <attribute name="MSID" type="string" use="optional"> <annotation> <documentation>A client-defined unique Iidentifier. Can be used for different purposes, for example billing.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="Request" type="xls:RequestType" substitutionGroup="xls:_Body"> <annotation> <documentation>The core information of a service request message.</documentation> </annotation> </element> <complexType name="RequestType"> <annotation> <documentation>Defines the core information of a service request message.</documentation> </annotation> <complexContent> <extension base="xls:AbstractBodyType"> <sequence> <element ref="xls:_RequestParameters" minOccurs="0"/> </sequence> <attribute name="methodName" type="NMTOKEN" use="required"> <annotation> <documentation>The name of the method to be invoked by the service.</documentation> </annotation> </attribute> <attribute name="version" type="string" use="required"> <annotation> <documentation>The version level of the request parameters supported by the client.</documentation> </annotation> </attribute> <attribute name="requestID" type="string" use="required"> <annotation>

<documentation>A client-defined request identifier, unique within the scope of the session. The request identifier must be returned in the service response.</documentation> </annotation> </attribute> <attribute name="maximumResponses" type="nonNegativeInteger" use="optional"> <annotation> <documentation>This parameter will allow the request to control the number of responses generated. For example the POI request will use this as a contraint to generate a certain number of POIs. In the special cases where one of the responses can contain multiple values this will be controlled within the request itself, in those cases this parameter will not be applicable</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="_RequestParameters" type="xls:AbstractRequestParametersType" abstract="true"> <annotation> <documentation>Base element representing the set of parameters for a service request.</documentation> </annotation> </element> <complexType name="AbstractRequestParametersType" abstract="true"> <annotation> <documentation>Abstract type representing the set of parameters for a service request.</documentation> </annotation> </complexType> <element name="ResponseHeader" type="xls:ResponseHeaderType" substitutionGroup="xls:_Header"> <annotation> <documentation>The header information for response messages.</documentation> </annotation> </element> <complexType name="ResponseHeaderType"> <annotation> <documentation>Defines the header information for response messages.</documentation> </annotation> <complexContent> <extension base="xls:AbstractHeaderType"> <sequence> <element ref="xls:ErrorList" minOccurs="0"/> </sequence> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<attribute name="sessionID" type="string" use="optional"> <annotation> <documentation>The session identifier, specified by the client in the request header.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="Response" type="xls:ResponseType" substitutionGroup="xls:_Body"> <annotation> <documentation>The response information returned from a service request.</documentation> </annotation> </element> <complexType name="ResponseType"> <annotation> <documentation>Defines the response information returned from a service response.</documentation> </annotation> <complexContent> <extension base="xls:AbstractBodyType"> <sequence> <element ref="xls:ErrorList" minOccurs="0"/> <element ref="xls:_ResponseParameters" minOccurs="0"/> </sequence> <attribute name="version" type="string" use="required"> <annotation> <documentation>The version level of the response parameters supported by the service.</documentation> </annotation> </attribute> <attribute name="requestID" type="string" use="required"> <annotation> <documentation>The request identifier, unique within the scope of the session, specified by the client in the service request.</documentation> </annotation> </attribute> <attribute name="numberOfResponses" type="nonNegativeInteger" use="optional"> <annotation> <documentation>This is the number of responses that are generated by the request. For example a map request can contain multiple requests for multiple maps, the responses will contain mulitple responses to that. In the case of Geocode, multiple responses will be equal to the number of requests, each response may contain one or more candidate addresses. For the scope of this

standard, most of the time the number of responses will be equal to 1 </documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="_ResponseParameters" type="xls:AbstractResponseParametersType" abstract="true"> <annotation> <documentation>Base element representing the response information returned from a service request.</documentation> </annotation> </element> <complexType name="AbstractResponseParametersType" abstract="true"> <annotation> <documentation>Abstract type representing the response information returned from a service request.</documentation> </annotation> </complexType> <element name="ErrorList" type="xls:ErrorListType"> <annotation> <documentation>A list of errors encountered while attempting to process a request.</documentation> </annotation> </element> <complexType name="ErrorListType"> <annotation> <documentation>Defines a list of errors.</documentation> </annotation> <sequence> <element ref="xls:Error" maxOccurs="unbounded"/> </sequence> <attribute name="highestSeverity" type="xls:SeverityType" use="optional" default="Warning"> <annotation> <documentation>Set to the highest severity of any of the Error elements. Specifically, if any of the Error elements have a severity of Error then highestSeverity must be set to Error, otherwise set highestSeverity to Warning.</documentation> </annotation> </attribute> </complexType> <element name="Error" type="xls:ErrorType"> <annotation> <documentation>Contains error and/or status information.</documentation> </annotation> </element> <complexType name="ErrorType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<annotation> <documentation>Defines the characteristics of a processing error.</documentation> </annotation> <attribute name="errorCode" type="xls:ErrorCodeType" use="required"> <annotation> <documentation>XML qualified name identifying the error. The wellknown error codes within the "http://www.opengis.org/xls" namespace are enumerated in the type ErrorCodeEnum.</documentation> </annotation> </attribute> <attribute name="severity" type="xls:SeverityType" use="optional" default="Warning"> <annotation> <documentation>Indicates the severity of the error.</documentation> </annotation> </attribute> <attribute name="locationID" type="IDREF" use="optional"> <annotation> <documentation>The ID of the element associated with the error.</documentation> </annotation> </attribute> <attribute name="locationPath" type="string" use="optional"> <annotation> <documentation>If the XML is well formed, then this attribute contains the path to the XML element or attribute associated with the error.</documentation> </annotation> </attribute> <attribute name="message" type="string" use="optional"> <annotation> <documentation>Provides a human readable explanation of the error, which is not intended for algorithmic processing.</documentation> </annotation> </attribute> </complexType>

<simpleType name="ErrorCodeType"> <annotation> <documentation>Enumeration of error codes defined within the "http://www.opengis.net/xls" namespace.</documentation> </annotation> <restriction base="string"> <enumeration value="RequestVersionMismatch"> <annotation> <documentation>Version of Request Schema not supported. Should echo the invliad version number used in the request</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</enumeration> <enumeration value="ValueNotRecognized"> <annotation> <documentation>Element content or attribute value not recognized. Although the document is well formed and valid, the element/attribute contains a value that could not be recognized and therefore could not be used by the service processing the message. The error should include the value that was not recognized</documentation> </annotation> </enumeration> <enumeration value="NotSupported"> <annotation> <documentation>Element or attribute not supported. Although the document is well formed and valid, an element or attribute is present that is consistent with the rules and constraints contained in the OpenLS standard, but is not supported by the service processing the message.</documentation> </annotation> </enumeration> <enumeration value="Inconsistent"> <annotation> <documentation>Element content or attribute value inconsistent with other elements or attributes. Although the document is well formed and valid, according to the rules and constraints contained in the OGC OpenLS tandard the content of an element or attribute is inconsistent with the content of other elements or their attributes.</documentation> </annotation> </enumeration> <enumeration value="DeliveryFailure"> <annotation> <documentation>Message Delivery Failure. A message has been received that either probably or definitely could not be sent to its next destination. Note: if severity is set to Warning then there is a small probability that the message was delivered.</documentation> </annotation> </enumeration> <enumeration value="SecurityFailure"> <annotation> <documentation>Message Security Checks Failed. Validation of signatures or checks on the authenticity or authority of the sender of the message have failed.</documentation> </annotation> </enumeration> <enumeration value="NoResultsReturned"> <annotation> <documentation>The inputs were correct but didn’t produce a result.</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 93

OpenLS 1.2

</enumeration> <enumeration value="TimedOut"> <annotation> <documentation>The operation timed out on the server side.</documentation> </annotation> </enumeration> <enumeration value="InternalServerError"> <annotation> <documentation>An error has occurred inside the server.</documentation> </annotation> </enumeration> <enumeration value="DataNotAvailable"> <annotation> <documentation>The server does not have data coverage.</documentation> </annotation> </enumeration> <enumeration value="Unknown"> <annotation> <documentation>Unknown Error. Indicates that an error has occurred that is not covered explicitly by any of the other errors. The Error message attribute should be used to indicate the nature of the problem.</documentation> </annotation> </enumeration> </restriction> </simpleType> <simpleType name="SeverityType"> <annotation> <documentation>Enumeration of the error severity levels.</documentation> </annotation> <restriction base="string"> <enumeration value="Warning"> <annotation> <documentation>This indicates that although there is an error, other parts of the request will still be processed in the normal way.</documentation> </annotation> </enumeration> <enumeration value="Info/ Status"> <annotation> <documentation>This indicates that although there is an error, other parts of the request will still be processed in the normal way.</documentation> </annotation> </enumeration> <enumeration value="Error"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<annotation> <documentation>This indicates that there is an unrecoverable error in the request and no part of the request will processed.</documentation> </annotation> </enumeration> </restriction> </simpleType> </schema>

DirectoryService.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xls="http://www.opengis.net/xls" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> <include schemaLocation="XLS.xsd"/>  <element name="DirectoryRequest" type="xls:DirectoryRequestType" substitutionGroup="xls:_RequestParameters"/> <complexType name="DirectoryRequestType"> <annotation> <documentation>ADT for a DirectoryRequest</documentation> </annotation> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element ref="xls:POILocation" minOccurs="0"/> <element ref="xls:_POISelectionCriteria"/> </sequence> <attribute name="sortCriteria" type="string" use="optional"> <annotation> <documentation>POI property used to sort the result. It may take on the well-known values of “Name” and “Distance” as well as any other POI property names. </documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

</attribute> <attribute name="sortDirection" type="xls:SortDirectionType" use="optional" default="Ascending"> <annotation> <documentation>Ascending/Descending</documentation> </annotation> </attribute> <attribute name="distanceUnit" type="xls:DistanceUnitType" use="optional" default="M"> <annotation> <documentation>Specifies the unit for measuring distance.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>  <element name="DirectoryResponse" type="xls:DirectoryResponseType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Directory Service Response</documentation> </annotation> </element>  <complexType name="DirectoryResponseType"> <annotation> <documentation>ADT for a ProximityResponse. One or more POIs may be returned</documentation> </annotation> <complexContent> <extension base="xls:AbstractResponseParametersType"> <sequence> <element name="POIContext" type="xls:POIWithDistanceType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <complexType name="WithinBoundaryType"> <annotation> <documentation>Defines a spatial filter which selects POIs located within a specified bounding area.</documentation> </annotation> <sequence> <element ref="xls:AOI"/> </sequence> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

</complexType>  <complexType name="WithinDistanceType"> <annotation> <documentation>Defines a spatial filter which selects POIs located within a specified distance from a location.</documentation> </annotation> <sequence> <element ref="xls:_Location"/> <element name="MinimumDistance" type="xls:DistanceType" minOccurs="0"/> <element name="MaximumDistance" type="xls:DistanceType" minOccurs="0"/> </sequence> </complexType>  <complexType name="NearestType"> <annotation> <documentation>Defines a spatial filter which selects the POI nearest to the specified location.</documentation> </annotation> <sequence> <element ref="xls:_Location" maxOccurs="unbounded"/> </sequence> <attribute name="nearestCriterion" type="xls:NearestCriterionType" use="optional" default="Proximity"> <annotation> <documentation>Proximity - nearest by straightline distance</documentation> </annotation> </attribute> </complexType> <simpleType name="NearestCriterionType"> <restriction base="string"> <enumeration value="Proximity"/> <enumeration value="Fastest"/> <enumeration value="Shortest"/> <enumeration value="Easiest"/> </restriction> </simpleType>  <element name="_POISelectionCriteria" type="xls:AbstractPOISelectionCriteriaType"> <annotation> <documentation>Base element that specifies POI selection criteria</documentation> </annotation> </element> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<complexType name="AbstractPOISelectionCriteriaType" abstract="true"> <annotation> <documentation>Abstract POI selection criteria</documentation> </annotation> </complexType>  <simpleType name="SortDirectionType"> <annotation> <documentation>Defines the sort direction (Ascending/Descending)</documentation> </annotation> <restriction base="string"> <enumeration value="Ascending"/> <enumeration value="Descending"/> </restriction> </simpleType>  <element name="POILocation" type="xls:POILocationType"/> <complexType name="POILocationType"> <annotation> <documentation>Defines the type of location constraints to perform search.</documentation> </annotation> <choice> <element ref="xls:Address"/> <element name="Nearest" type="xls:NearestType"/> <element name="WithinDistance" type="xls:WithinDistanceType"/> <element name="WithinBoundary" type="xls:WithinBoundaryType"/> </choice> </complexType>  <complexType name="POIWithDistanceType"> <annotation> <documentation>Defines a POI and its distance from a predetermined point.</documentation> </annotation> <sequence> <element ref="xls:POI"/> <element ref="xls:Distance" minOccurs="0"/> </sequence> </complexType>  <element name="POIProperties" substitutionGroup="xls:_POISelectionCriteria"> <annotation> <documentation>Specifies POI selection criteria as a list of properties</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

<complexType> <complexContent> <extension base="xls:POIPropertiesType"/> </complexContent> </complexType> </element>  <complexType name="POIPropertiesType"> <annotation> <documentation>Defines POI selection criteria as a list of properties</documentation> </annotation> <complexContent> <extension base="xls:AbstractPOISelectionCriteriaType"> <sequence> <element ref="xls:_POIProperty" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="directoryType" type="string" use="optional"/> </extension> </complexContent> </complexType>  <complexType name="AbstractPOIPropertyType" abstract="true"> <annotation> <documentation>Abstract POI property</documentation> </annotation> </complexType>  <element name="_POIProperty"> <annotation> <documentation>Base element representing a POI property</documentation> </annotation> </element> <complexType name="POIPropertyType"> <annotation> <documentation>Defines a POI property, represented as a name/value pair</documentation> </annotation> <complexContent> <extension base="xls:AbstractPOIPropertyType"> <attribute name="name" type="xls:POIPropertyNameType" use="required"/> <attribute name="value" type="string" use="required"/> </extension> </complexContent> </complexType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenLS 1.2

<element name="POIProperty" type="xls:POIPropertyType" substitutionGroup="xls:_POIProperty"> <annotation> <documentation>A POI property, represented as a name/value pair</documentation> </annotation> </element> <simpleType name="POIPropertyNameType"> <annotation> <documentation>Enumeration of references to properties within the POI element</documentation> </annotation> <restriction base="string"> <enumeration value="ID"/> <enumeration value="POIName"/> <enumeration value="PhoneNumber"/> <enumeration value="Keyword"/> <enumeration value="NAICS_type"/> <enumeration value="NAICS_subType"/> <enumeration value="NAICS_category"/> <enumeration value="SIC_type"/> <enumeration value="SIC_subType"/> <enumeration value="SIC_category"/> <enumeration value="SIC_code"/> <enumeration value="other"/> </restriction> </simpleType> </schema>

GatewayService.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/>

100

<element name="_GatewayParameters" type="xls:AbstractGatewayParametersType" abstract="false"> <annotation> <documentation>All Gateway Requests and Responses descend from this Type. This is required to support other Location Requests defined in LIF.</documentation> </annotation> </element> <complexType name="AbstractGatewayParametersType" abstract="true"> <sequence> <element name="RequestedQoP" type="xls:QualityOfPositionType" minOccurs="0"/>  </sequence> <attribute name="locationType" use="optional" default="CURRENT"> <annotation> <documentation>Defines the type of location requested</documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="CURRENT"/> <enumeration value="LAST"/> <enumeration value="CURRENT_OR_LAST"/> </restriction> </simpleType> </attribute> <attribute name="requestedsrsName" type="string" use="optional"> <annotation> <documentation>The requested Spatial Reference system</documentation> </annotation> </attribute> <attribute name="ver" type="string" default="3.0"> <annotation> <documentation>The version of LIF that this Request supports</documentation> </annotation> </attribute> <attribute name="priority" use="optional" default="HIGH"> <annotation> <documentation>The priority of the request</documentation> </annotation> <simpleType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 101

OpenLS 1.2

<restriction base="string"> <enumeration value="NORMAL"/> <enumeration value="HIGH"/> </restriction> </simpleType> </attribute> </complexType> <element name="InputGatewayParameters" type="xls:InputGatewayParametersType" substitutionGroup="xls:_GatewayParameters"/> <complexType name="InputGatewayParametersType"> <complexContent> <extension base="xls:AbstractGatewayParametersType"> <sequence> <element ref="xls:InputMSID"/> </sequence> </extension> </complexContent> </complexType> <element name="OutputGatewayParameters" type="xls:OutputGatewayParametersType" substitutionGroup="xls:_GatewayParameters"/> <complexType name="OutputGatewayParametersType"> <complexContent> <extension base="xls:AbstractGatewayParametersType"> <sequence> <element ref="xls:OutputMSID"/> </sequence> </extension> </complexContent> </complexType>  <element name="SLIR" type="xls:SLIRType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Standard Location Immediate Request. Response type is Synchronous</documentation> </annotation> </element> <complexType name="SLIRType"> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element ref="xls:InputGatewayParameters"/> </sequence> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

102

</extension> </complexContent> </complexType>  <element name="_MSInformation" type="xls:AbstractMSInformationType" abstract="true"> <annotation> <documentation>Identifier of the mobile subscriber</documentation> </annotation> </element> <complexType name="AbstractMSInformationType"> <attribute name="msIDType" default="MSISDN"> <annotation> <documentation>Type of identifier for the mobile subscriber. MSISDN: Mobile Station International ISDN Number. IMSI: International Mobile Subscriber Identity. IMEI: International Mobile station Equipment Identity. MIN: Mobile Identification Number. MDN: Mobile Directory Number. EME_MSID: Emergency MSID. IPV4: Mobile station IP address (Version 4). IPV6: Mobile station IP address (Version 6) </documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="MSISDN"/> <enumeration value="MIN"/> <enumeration value="IMSI"/> <enumeration value="IMEI"/> <enumeration value="MDN"/> <enumeration value="EME_MSID"/> <enumeration value="IPV4"/> <enumeration value="IPV6"/> </restriction> </simpleType> </attribute> <attribute name="msIDValue" type="string"/> <attribute name="encryption" use="optional" default="ASC"> <annotation> <documentation>Type of encoding for MSID identifier for the mobile subscriber. ASC: Normal textual format. B64: Base 64 encoding. CRP: Encrypted format: In some countries the Network Operator (where is placed the Location Server) isn't allowed to send to a LCS the private information of an MS like MSISDN.The Network Operator can send out to LCS the Encrypted MSID, since only the Network Operator is the only entity able to decode this information, the LCS will be never able to break the privacy of the MS.</documentation> </annotation> <simpleType> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 103

OpenLS 1.2

<restriction base="string"> <enumeration value="ASC"/> <enumeration value="B64"/> <enumeration value="CRP"/> </restriction> </simpleType> </attribute> </complexType> <element name="InputMSInformation" type="xls:InputMSInformationType" substitutionGroup="xls:_MSInformation"/> <complexType name="InputMSInformationType"> <complexContent> <extension base="xls:AbstractMSInformationType"/> </complexContent> </complexType> <element name="OutputMSInformation" type="xls:OutputMSInformationType" substitutionGroup="xls:_MSInformation"/> <complexType name="OutputMSInformationType"> <complexContent> <extension base="xls:AbstractMSInformationType"> <sequence> <element ref="xls:Position"/> </sequence> </extension> </complexContent> </complexType>  <element name="_MSID" type="xls:AbstractMSIDType" abstract="true"/> <annotation> <documentation>List of identifiers of mobile subscribers</documentation> </annotation> <complexType name="AbstractMSIDType"> <attribute name="session" use="optional"> <simpleType> <restriction base="string"> <enumeration value="APN"/> <enumeration value="DIAL"/> </restriction> </simpleType> </attribute> </complexType> <element name="InputMSID" type="xls:InputMSIDType" substitutionGroup="xls:_MSID"/> <complexType name="InputMSIDType"> <complexContent> <extension base="xls:AbstractMSIDType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

104

<sequence> <element ref="xls:InputMSInformation"/> </sequence> </extension> </complexContent> </complexType> <element name="OutputMSID" type="xls:OutputMSIDType" substitutionGroup="xls:_MSID"/> <complexType name="OutputMSIDType"> <complexContent> <extension base="xls:AbstractMSIDType"> <sequence> <element ref="xls:OutputMSInformation"/> </sequence> </extension> </complexContent> </complexType>  <element name="SLIA" type="xls:SLIAType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Standard Location Immediate Response</documentation> </annotation> </element> <complexType name="SLIAType"> <complexContent> <extension base="xls:AbstractResponseParametersType"> <sequence> <element ref="xls:OutputGatewayParameters"/>  </sequence> <attribute name="requestID" type="string" use="optional"> <annotation> <documentation>Unique identification of a request</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> </schema>

105

OpenLS 1.2

LocationUtilityService.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns:gml="http://www.opengis.net/gml" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> <include schemaLocation="XLS.xsd"/>  <element name="GeocodeRequest" type="xls:GeocodeRequestType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Geocode Service Request</documentation> </annotation> </element>

<complexType name="GeocodeRequestType"> <annotation> <documentation>Geocode Request. </documentation> </annotation> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element ref="xls:Address" maxOccurs="unbounded"/> </sequence> <attribute name="returnFreeForm" type="boolean" use="optional" default="false"> <annotation> <documentation>. Used to request freeform addresses in the response, as opposed to structured adddresses</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>  <element name="GeocodeResponse" type="xls:GeocodeResponseType" substitutionGroup="xls:_ResponseParameters">

106

<annotation> <documentation>Geocode Service Response</documentation> </annotation> </element>  <complexType name="GeocodedAddressType"> <sequence> <element ref="gml:Point"/> <element ref="xls:Address"/> <element ref="xls:GeocodeMatchCode" minOccurs="0"/>  </sequence> </complexType>  <complexType name="GeocodeResponseListType"> <sequence> <element name="GeocodedAddress" type="xls:GeocodedAddressType" maxOccurs="unbounded"> <annotation> <documentation>The list of 1-n addresses that are returned for each Address request, sorted by Accuracy.</documentation> </annotation> </element> </sequence> <attribute name="numberOfGeocodedAddresses" type="nonNegativeInteger" use="required"> <annotation> <documentation>This is the number of responses generated per the different requests. Within each geocoded address tit's possible to have multiple candidates</documentation> </annotation> </attribute> </complexType> <element name="GeocodeResponseList" type="xls:GeocodeResponseListType"> <annotation> <documentation>The list of responses for each of the requested Address ADTs. Each requested address may have 1-n responses (numberOfAddresses). </documentation> </annotation> </element> <complexType name="GeocodeResponseType"> <annotation> <documentation>GeocodeResponse. The addresses returned will be normalized Address ADTs as a result of any parsing by the geocoder, etc.</documentation> </annotation> <complexContent> <extension base="xls:AbstractResponseParametersType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

107

OpenLS 1.2

<sequence> <element ref="xls:GeocodeResponseList" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <element name="ReverseGeocodeRequest" type="xls:ReverseGeocodeRequestType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Reverse Geocode Service Request</documentation> </annotation> </element>  <complexType name="ReverseGeocodeRequestType"> <annotation> <documentation>Reverse Geocode Request.</documentation> </annotation> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element ref="xls:Position"/> <element ref="xls:ReverseGeocodePreference" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>  <element name="ReverseGeocodeResponse" type="xls:ReverseGeocodeResponseType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Reverse Geocode Service Response</documentation> </annotation> </element>  <complexType name="ReverseGeocodedLocationType"> <sequence> <element ref="gml:Point"/> <element ref="xls:Address"/> <element ref="xls:SearchCentreDistance" minOccurs="0"/>  </sequence> </complexType> <complexType name="ReverseGeocodeResponseType"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

108

<documentation>ADT for a ReverseGeocodeResponse. One or more addresses may be returned</documentation> </annotation> <complexContent> <extension base="xls:AbstractResponseParametersType"> <sequence> <element name="ReverseGeocodedLocation" type="xls:ReverseGeocodedLocationType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation>Reverse Geocoder may find 0 to n PointAddress combinations that match.</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <simpleType name="ReverseGeocodePreferenceType"> <annotation> <documentation>Defines a Preference for Reverse Geocode response. </documentation> </annotation> <restriction base="string"> <enumeration value="StreetAddress"/> <enumeration value="IntersectionAddress"/> </restriction> </simpleType> <element name="ReverseGeocodePreference" type="xls:ReverseGeocodePreferenceType"> <annotation> <documentation>Describes the preference for what the Reverse Geocoder service should return: StreetAddress, IntersectionAddress, or PositionOfInterest (Place and/or PostalCode). If not specified, then the service will return the nearest StreetAddress. . </documentation> </annotation> </element> <element name="SearchCentreDistance" type="xls:DistanceType"> <annotation> <documentation>Distance of reverse geocoded location from starting position.</documentation> </annotation> </element> </schema>

109

OpenLS 1.2

PresentationService.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns:gml="http://www.opengis.net/gml" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/>

<include schemaLocation="XLS.xsd"/> <!-==============================================GetCapabilities Request=====================--> <element name="GetPortrayMapCapabilitiesRequest" type="xls:GetPortrayMapCapabilitiesRequestType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Request the capabilities that the implementation provides (srs, formats, layers, styles)</documentation> </annotation> </element> <complexType name="GetPortrayMapCapabilitiesRequestType"> <complexContent> <extension base="xls:AbstractRequestParametersType"/> </complexContent> </complexType> <!-==============================================GetCapabilities Response=====================--> <element name="GetPortrayMapCapabilitiesResponse" type="xls:GetPortrayMapCapabilitiesResponseType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Content of the capabilities response</documentation> </annotation> </element> <complexType name="GetPortrayMapCapabilitiesResponseType"> <complexContent> <extension base="xls:AbstractResponseParametersType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

110

<sequence> <element name="AvailableSRS" type="xls:AvailableSRSType"> <annotation> <documentation>The list of the projections that the impl provides (EPSG:XXXX)</documentation> </annotation> </element> <element name="AvailableLayers" type="xls:AvailableLayersType"> <annotation> <documentation>The list of the layers that the implementation provides for portraying the baseMap. To try and keep this within scope of openLS, the style of these layers is left up to the impl.</documentation> </annotation> </element> <element name="AvailableFormats" type="xls:AvailableFormatsType"> <annotation> <documentation>The list of formats (mime-types) that the impl will encode the protrayed map with (image/gif, image/png, text/xml-svg etc)</documentation> </annotation> </element> <element name="AvailableStyles" type="xls:AvailableStylesType"> <annotation> <documentation>The list of available named styles</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="AvailableSRSType"> <sequence> <element name="SRS" type="string" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="AvailableLayersType"> <sequence> <element name="Layer" type="string" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="AvailableFormatsType"> <sequence> <element name="Format" type="string" maxOccurs="unbounded"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 111

OpenLS 1.2

</sequence> </complexType> <complexType name="AvailableStylesType"> <sequence> <element name="Style" type="string" maxOccurs="unbounded"/> </sequence> </complexType> <!-==============================================Request========= ============--> <element name="PortrayMapRequest" type="xls:PortrayMapRequestType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Content of a presentation request</documentation> </annotation> </element> <complexType name="PortrayMapRequestType"> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element name="Output" type="xls:OutputType" maxOccurs="unbounded"> <annotation> <documentation>Specifies the output of the map(s) that should generated</documentation> </annotation> </element> <element name="Basemap" type="xls:LayerType" minOccurs="0"> <annotation> <documentation>The layers that should make up the baseMap. (getCapabilites provides the list the impl provides) </documentation> </annotation> </element> <element name="Overlay" type="xls:OverlayType" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation>Overlays the set of ADT's onto the basemap</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType>

112

<!-============================================================= =====--> <complexType name="OutputType"> <choice minOccurs="0"> <element name="BBoxContext" type="gml:EnvelopeType"> <annotation> <documentation>Context described as a bounding box</documentation> </annotation>  </element> <element name="CenterContext" type="xls:CenterContextType"> <annotation> <documentation>Context described by a center point and scale</documentation> </annotation> </element> </choice> <attribute name="width" type="nonNegativeInteger"> <annotation> <documentation>width of the resulting map in pixels</documentation> </annotation> </attribute> <attribute name="height" type="nonNegativeInteger"> <annotation> <documentation>height of the resulting map in pixels</documentation> </annotation> </attribute> <attribute name="format" type="string"> <annotation> <documentation>mime type describing the encoding (getCapabilites provides the list that the impl provides)</documentation> </annotation> </attribute> <attribute name="BGcolor" type="string" use="optional"> <annotation> <documentation>Background Color of the map in RGB Hex format, defaults to "#FFFFFF" (White)</documentation> </annotation> </attribute> <attribute name="transparent" type="boolean" use="optional"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

113

OpenLS 1.2

<documentation>The opacity of the map, defaults to true if not specified</documentation> </annotation> </attribute> <attribute name="content" type="xls:presentationContentType" use="optional" default="URL"/>    </complexType> <simpleType name="presentationContentType"> <annotation> <documentation>Map can be returned as one of those content types</documentation> </annotation> <restriction base="string"> <enumeration value="URL"/> <enumeration value="Data"/> </restriction> </simpleType> <complexType name="OverlayType"> <sequence> <choice> <element ref="xls:POI"/> <element ref="xls:RouteGeometry"/> <element ref="xls:Position"/> <element ref="xls:Map"/> </choice> <element name="Style" type="xls:StyleType" minOccurs="0"> <annotation> <documentation>The Style describing how the ADT's should be portrayed. Either a named style or a user defined style. The implementation should use a default if neither is specified</documentation> </annotation> </element> </sequence> <attribute name="zorder" type="integer" use="optional"> <annotation>

114

<documentation>The order in which the overlay's are laid on top of each other over the base map</documentation> </annotation> </attribute> </complexType> <complexType name="LayerType"> <sequence> <element name="Layer" maxOccurs="unbounded"> <complexType> <sequence> <element name="Style" type="xls:StyleType" minOccurs="0"> <annotation> <documentation>The style describing how the layer should be portrayed</documentation> </annotation> </element> </sequence> <attribute name="name" type="string" use="required"> <annotation> <documentation>The layer name, getCapabilites provides a list the impl provides</documentation> </annotation> </attribute> </complexType> </element> </sequence> <attribute name="filter" use="required"> <simpleType> <restriction base="string"> <enumeration value="Include"/> <enumeration value="Exclude"/> </restriction> </simpleType> </attribute> </complexType> <complexType name="StyleType"> <choice> <element name="Name" type="string"> <annotation> <documentation>Portray using a named style</documentation> </annotation> </element> <element name="StyleContent" type="string"> <annotation> <documentation>Portray using a user defined style</documentation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 115

OpenLS 1.2

</annotation> </element> </choice> </complexType> <complexType name="ClipType"> <choice> <element ref="gml:Polygon"> <annotation> <documentation>Clips the portrayed map with a polygon</documentation> </annotation> </element> <element ref="gml:CircleByCenterPoint"> <annotation> <documentation>Clips the portrayed map with a circle</documentation> </annotation>  </element> <element name="LineCorridor" type="xls:LineCorridorType"> <annotation> <documentation>Clips the portrayed map along a line with a corridor width</documentation> </annotation> </element> </choice> </complexType> <complexType name="LineCorridorType"> <sequence> <element ref="gml:LineString"/> <element ref="xls:Distance"/>  </sequence> </complexType> <!-==============================================Response======= ==============--> <element name="PortrayMapResponse" type="xls:PortrayMapResponseType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Content of a presentation response</documentation> </annotation> </element> <complexType name="PortrayMapResponseType"> <complexContent> <extension base="xls:AbstractResponseParametersType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

116

RouteService.xsd <?xml version="1.0" encoding="UTF-8"?>  <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> <include schemaLocation="XLS.xsd"/> <!-================================================================ ====================== Route Service Basic ============================================================== =========================== --> <element name="DetermineRouteRequest" type="xls:DetermineRouteRequestType" substitutionGroup="xls:_RequestParameters"> <annotation> <documentation>Specifies the Determine Route request parameters.</documentation> </annotation> </element> <complexType name="DetermineRouteRequestType"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

117

OpenLS 1.2

<documentation>Defines the Determine Route request parameters.</documentation> </annotation> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <choice> <element ref="xls:RouteHandle"> <annotation> <documentation>Reference to a proviously determined route stored at the Route Determination Service server.</documentation> </annotation> </element> <element ref="xls:RoutePlan"/> </choice> <element ref="xls:RouteInstructionsRequest" minOccurs="0"> <annotation> <documentation>Request parameters for turn-by-turn route directions and advisories formatted for presentation.</documentation> </annotation> </element> <element ref="xls:RouteGeometryRequest" minOccurs="0"> <annotation> <documentation>Request parameters for route geometry.</documentation> </annotation> </element> <element ref="xls:RouteMapRequest" minOccurs="0"/> </sequence> <attribute name="provideRouteHandle" type="boolean" use="optional" default="false"> <annotation> <documentation>Requests the return of a route handle.</documentation> </annotation> </attribute> <attribute name="distanceUnit" type="xls:DistanceUnitType" use="optional" default="M"> <annotation> <documentation>Specifies the unit for measuring distance.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="RoutePlan" type="xls:RoutePlanType"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

118

<documentation>The criteria upon which a route is determined.</documentation> </annotation> </element> <complexType name="RoutePlanType"> <annotation> <documentation>Defines the criteria upon which a route is determined.</documentation> </annotation> <sequence> <element ref="xls:RoutePreference"/> <element ref="xls:WayPointList"/> <element ref="xls:AvoidList" minOccurs="0"/> </sequence> <attribute name="useRealTimeTraffic" type="boolean" use="optional" default="false"> <annotation> <documentation>Specifies whether to use real time traffic information when determining the best route.</documentation> </annotation> </attribute> <attribute name="expectedStartTime" type="dateTime" use="optional"> <annotation> <documentation>Specifies the date and time at which travel is expected to begin. Specified in the format YYYY-MM-DD HH:MM. Defaults to current date and time.</documentation> </annotation> </attribute> <attribute name="expectedEndTime" type="dateTime" use="optional"> <annotation> <documentation>Specifies the date and time at which travel is expected to end. The format for the end time is specified as Duration</documentation> </annotation> </attribute> </complexType> <element name="AvoidList" type="xls:AvoidListType"> <annotation> <documentation>The list of areas, locations, and types of features in which the route should avoid passing through.</documentation> </annotation> </element> <complexType name="AvoidListType"> <annotation> <documentation>Defines the list of areas, locations, and types of features in which the route should avoid passing through.</documentation> </annotation> <sequence> <element ref="xls:AOI" minOccurs="0" maxOccurs="unbounded"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

119

OpenLS 1.2

<annotation> <documentation>List of geographic areas to avoid.</documentation> </annotation> </element> <element ref="xls:_Location" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation>List of locations to avoid.</documentation> </annotation> </element> <element ref="xls:AvoidFeature" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <element name="RouteMapRequest" type="xls:RouteMapRequestType"> <annotation> <documentation>The request parameters for route maps.</documentation> </annotation> </element> <complexType name="RouteMapRequestType"> <annotation> <documentation>Defines the request parameters for route maps.</documentation> </annotation> <sequence> <element name="Output" type="xls:RouteMapOutputType" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="RouteMapOutputType"> <annotation> <documentation>Defines the rendered route map output parameters.</documentation> </annotation> <sequence> <element name="BBoxContext" type="gml:EnvelopeType" minOccurs="0"> <annotation> <documentation>Rectangular area to be displayed in the rendered map. If not specified, defaults to full route.</documentation> </annotation>  </element> </sequence> <attribute name="width" type="nonNegativeInteger"> <annotation> <documentation>pixel width of the resulting map</documentation> </annotation> </attribute> <attribute name="height" type="nonNegativeInteger"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

120

<annotation> <documentation>pixel height of the resulting map</documentation> </annotation> </attribute> <attribute name="format" type="string"> <annotation> <documentation>mime type describing the encoding</documentation> </annotation> </attribute> <attribute name="BGcolor" type="string" use="optional"/> <attribute name="transparent" type="boolean" use="optional"/> <attribute name="style" type="xls:RouteMapStyleType" use="optional"/> </complexType> <simpleType name="RouteMapStyleType"> <annotation> <documentation>A route map can be either an overview or a maneuver</documentation> </annotation> <restriction base="string"> <enumeration value="Overview"> <annotation> <documentation>Used to describe the map showing the full route</documentation> </annotation> </enumeration> <enumeration value="Maneuver"> <annotation> <documentation>Used to describe the map showing a particular maneuver (often the maneuver corresponds to a single instruction)</documentation> </annotation> </enumeration> </restriction> </simpleType> <element name="RouteInstructionsRequest" type="xls:RouteInstructionsRequestType"> <annotation> <documentation>The request parameters for turn-by-turn route instructions and travel advisories formatted for presentation.</documentation> </annotation> </element> <complexType name="RouteInstructionsRequestType"> <annotation> <documentation>Defines the request parameters for turn-by-turn route instructions and travel advisories formatted for presentation.</documentation> </annotation> <attribute name="format" type="string" use="optional" default="text/plain"> <annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

121

OpenLS 1.2

<documentation>The preferred format of the route instructions, specified as a mime type.</documentation> </annotation> </attribute> <attribute name="provideGeometry" type="boolean" use="optional" default="false"/> <attribute name="provideBoundingBox" type="boolean" use="optional" default="false"/> </complexType> <element name="RouteGeometryRequest" type="xls:RouteGeometryRequestType"> <annotation> <documentation>The request parameters for route geometry.</documentation> </annotation> </element> <complexType name="RouteGeometryRequestType"> <annotation> <documentation>Defines the request parameters for route geometry.</documentation> </annotation> <sequence> <element name="BoundingBox" type="gml:EnvelopeType" minOccurs="0"> <annotation> <documentation>Rectangular area of route for which the geometry is requested. If not specified, defaults to full route.</documentation> </annotation>  </element> </sequence> <attribute name="scale" type="positiveInteger" use="optional" default="1"> <annotation> <documentation>Maximum scale at which the route will be displayed. Expressed as a ratio of world units to a device unit. For example 1:50000 would be specified as 50000.</documentation> </annotation> </attribute> <attribute name="provideStartingPortion" type="boolean" use="optional" default="false"> <annotation> <documentation>If true, return the geometry of the starting portion of the route contained within the specified bounding area, up to the specified maximum number of points. If false, return the geometry of the complete route contained within the specified area, reducing the accuracy of the geometry as necessary to not exceed the specified maximum number of points.</documentation> </annotation> </attribute>

122

<attribute name="maxPoints" type="positiveInteger" use="optional" default="100"> <annotation> <documentation>Maximum number of geometric points to return.</documentation> </annotation> </attribute> </complexType> <!-================================================================ =================== Response ============================================================== ======================== --> <element name="DetermineRouteResponse" type="xls:DetermineRouteResponseType" substitutionGroup="xls:_ResponseParameters"> <annotation> <documentation>Specifies the Determine Route response parameters.</documentation> </annotation> </element> <complexType name="DetermineRouteResponseType"> <annotation> <documentation>Defines the Determine Route response parameters.</documentation> </annotation> <complexContent> <extension base="xls:AbstractResponseParametersType"> <sequence> <element ref="xls:RouteHandle" minOccurs="0"> <annotation> <documentation>Reference to the route stored at the Route Determination Service server.</documentation> </annotation> </element> <element ref="xls:RouteSummary"> <annotation> <documentation>Response for requested route summary.</documentation> </annotation> </element> <element ref="xls:RouteGeometry" minOccurs="0"> <annotation> <documentation>Response for requested route geometry.</documentation> </annotation> </element> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

123

OpenLS 1.2

<element ref="xls:RouteInstructionsList" minOccurs="0"> <annotation> <documentation>Response for requested route instructions.</documentation> </annotation> </element> <element ref="xls:RouteMap" minOccurs="0" maxOccurs="unbounded"> <annotation> <documentation>Response list for requested route maps.</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <element name="RouteMap" type="xls:RouteMapType"> <annotation> <documentation>A route map.</documentation> </annotation> </element> <complexType name="RouteMapType"> <annotation> <documentation>Defines a route map.</documentation> </annotation> <complexContent> <extension base="xls:MapType"> <attribute name="description" type="string"> <annotation> <documentation>Allows the route instruction to be matched with a RouteMapType. For example "maneuver 1"</documentation> </annotation> </attribute> </extension> </complexContent> </complexType> <element name="AvoidFeature" type="xls:AvoidFeatureType"> <annotation> <documentation>Type of feature to avoid when determining the route.</documentation> </annotation> </element> <simpleType name="AvoidFeatureType"> <annotation> <documentation>Enumeration of types of features to avoid when determining the route.</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

124

<restriction base="string"> <enumeration value="Highway"> <annotation> <documentation>Minimize the use of highways.</documentation> </annotation> </enumeration> <enumeration value="Tollway"> <annotation> <documentation>Minimize tolls.</documentation> </annotation> </enumeration> </restriction> </simpleType> <simpleType name="RoutePreferenceType"> <annotation> <documentation>Enumeration of preferences to be taken into consideration when determining the route.</documentation> </annotation> <restriction base="string"> <enumeration value="Fastest"> <annotation> <documentation>Minimize the travel time by vehicle.</documentation> </annotation> </enumeration> <enumeration value="Shortest"> <annotation> <documentation>Minimize the travel distance by vehicle.</documentation> </annotation> </enumeration> <enumeration value="Pedestrian"> <annotation> <documentation>Best route by foot.</documentation> </annotation> </enumeration> </restriction> </simpleType> <element name="RoutePreference" type="xls:RoutePreferenceType"> <annotation> <documentation>Preference to be taken into consideration when determining the route.</documentation> </annotation> </element> </schema>

125

OpenLS 1.2

XLinks.xsd

<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xlink=http://www.w3.org/1999/xlink version="1.1"> <annotation> <documentation>Copyright (c) 2003 OGC, All Rights Reserved - This OGC document is a draft and is copyright-protected by OGC. While the reproduction of drafts in any form for use by participants in the OGC Interoperability Program is permitted without prior permission from OGC, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from OGC.</documentation> </annotation> <annotation> <appinfo source="urn:opengis:specification:gml:schemaxlinks:v3.0c2">xlinks.xsd v3.0b2 2001-07</appinfo> <documentation> GML 3.0 xlinks schema. . </documentation> </annotation> <!-============================================================= = global declarations =========================================================== ==== -->  <attribute name="href" type="anyURI"/>  <attribute name="role" type="anyURI"/> <attribute name="arcrole" type="anyURI"/> <attribute name="title" type="string"/>  <attribute name="show"> <annotation> <documentation> The 'show' attribute is used to communicate the desired presentation of the ending resource on traversal from the starting resource; it's value should be treated as follows: new - load ending resource in a new window, frame, pane, or other Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

126

presentation context replace - load the resource in the same window, frame, pane, or other presentation context embed - load ending resource in place of the presentation of the starting resource other - behavior is unconstrained; examine other markup in the link for hints none - behavior is unconstrained </documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="new"/> <enumeration value="replace"/> <enumeration value="embed"/> <enumeration value="other"/> <enumeration value="none"/> </restriction> </simpleType> </attribute> <attribute name="actuate"> <annotation> <documentation> The 'actuate' attribute is used to communicate the desired timing of traversal from the starting resource to the ending resource; it's value should be treated as follows: onLoad - traverse to the ending resource immediately on loading the starting resource onRequest - traverse from the starting resource to the ending resource only on a post-loading event triggered for this purpose other - behavior is unconstrained; examine other markup in link for hints none - behavior is unconstrained </documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="onLoad"/> <enumeration value="onRequest"/> <enumeration value="other"/> <enumeration value="none"/> </restriction> </simpleType> </attribute>  Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

127

OpenLS 1.2

<attribute name="label" type="string"/> <attribute name="from" type="string"/> <attribute name="to" type="string"/> <!-============================================================= = Attributes grouped by XLink type, as specified in the W3C Proposed Recommendation (dated 2000-12-20) =========================================================== === --> <attributeGroup name="simpleLink"> <attribute name="type" type="string" fixed="simple" form="qualified"/> <attribute ref="xlink:href" use="optional"/> <attribute ref="xlink:role" use="optional"/> <attribute ref="xlink:arcrole" use="optional"/> <attribute ref="xlink:title" use="optional"/> <attribute ref="xlink:show" use="optional"/> <attribute ref="xlink:actuate" use="optional"/> </attributeGroup> <attributeGroup name="extendedLink"> <attribute name="type" type="string" fixed="extended" form="qualified"/> <attribute ref="xlink:role" use="optional"/> <attribute ref="xlink:title" use="optional"/> </attributeGroup> <attributeGroup name="locatorLink"> <attribute name="type" type="string" fixed="locator" form="qualified"/> <attribute ref="xlink:href" use="required"/> <attribute ref="xlink:role" use="optional"/> <attribute ref="xlink:title" use="optional"/> <attribute ref="xlink:label" use="optional"/> </attributeGroup> <attributeGroup name="arcLink"> <attribute name="type" type="string" fixed="arc" form="qualified"/> <attribute ref="xlink:arcrole" use="optional"/> <attribute ref="xlink:title" use="optional"/> <attribute ref="xlink:show" use="optional"/> <attribute ref="xlink:actuate" use="optional"/> <attribute ref="xlink:from" use="optional"/> <attribute ref="xlink:to" use="optional"/> </attributeGroup> <attributeGroup name="resourceLink"> <attribute name="type" type="string" fixed="resource" form="qualified"/> <attribute ref="xlink:role" use="optional"/> <attribute ref="xlink:title" use="optional"/> <attribute ref="xlink:label" use="optional"/> </attributeGroup> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

128

<attributeGroup name="titleLink"> <attribute name="type" type="string" fixed="title" form="qualified"/> </attributeGroup> <attributeGroup name="emptyLink"> <attribute name="type" type="string" fixed="none" form="qualified"/> </attributeGroup> </schema> UOM.xsd <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xls="http://www.opengis.net/xls" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlinks.xsd"/> <complexType name="AbstractMeasureType" abstract="true"> <attribute name="value" type="decimal" use="required"/> <attribute name="accuracy" type="decimal" use="optional"/> </complexType> <element name="_Measure" type="xls:AbstractMeasureType" abstract="true"/> <simpleType name="DistanceUnitType"> <restriction base="string"> <enumeration value="KM"/> <enumeration value="M"/> <enumeration value="DM"/> <enumeration value="MI"/> <enumeration value="YD"/> <enumeration value="FT"/> </restriction> </simpleType> <complexType name="DistanceType"> <complexContent> <extension base="xls:AbstractMeasureType"> <attribute name="uom" type="xls:DistanceUnitType" use="optional" default="M"/> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

129

OpenLS 1.2

</extension> </complexContent> </complexType> <element name="Distance" type="xls:DistanceType" substitutionGroup="xls:_Measure"/> <complexType name="AltitudeType"> <complexContent> <extension base="xls:DistanceType"/> </complexContent> </complexType> <element name="Altitude" type="xls:AltitudeType"/> <!-============================================================= --> <complexType name="AngleType"> <annotation> <documentation>This type is used as a unit of measure for ADTs only, it's not used by the GML3 geometry. This will be a point for future work of harmonization.</documentation> </annotation> <complexContent> <extension base="xls:AbstractMeasureType"> <attribute name="uom" type="string" use="optional" fixed="DecimalDegrees"/> </extension> </complexContent> </complexType> <element name="Angle" type="xls:AngleType" substitutionGroup="xls:_Measure"/> <!-============================================================= --> <simpleType name="SpeedUnitType"> <restriction base="string"> <enumeration value="KPH"/> <enumeration value="MPH"/> <enumeration value="MPS"/> <enumeration value="FPS"/> </restriction> </simpleType> <complexType name="SpeedType"> <complexContent> <extension base="xls:AbstractMeasureType"> <attribute name="uom" type="xls:SpeedUnitType" use="optional" default="KPH"/> </extension> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

130

</complexContent> </complexType> <element name="Speed" type="xls:SpeedType" substitutionGroup="xls:_Measure"/> <!-============================================================= --> <complexType name="TimeStampType"> <attribute name="begin" type="dateTime" use="required"/> <attribute name="duration" type="duration" use="optional"/> </complexType> <element name="TimeStamp" type="xls:TimeStampType"/> <complexType name="TimeType"> <complexContent> <extension base="xls:TimeStampType"> <attribute name="utcOffset" type="integer" use="optional"/> </extension> </complexContent> </complexType> <element name="Time" type="xls:TimeType"/> </schema> Geometry.xsd

<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.opengis.net/xls" xmlns:xls="http://www.opengis.net/xls" xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="1.1">  <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlinks.xsd"/> <include schemaLocation="UOM.xsd"/>  <complexType name="EllipseType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 131

OpenLS 1.2

<complexContent> <extension base="gml:AbstractGeometricPrimitiveType"> <sequence> <element ref="gml:pos"/> <element name="majorAxis" type="gml:LengthType"/> <element name="minorAxis" type="gml:LengthType"/> <element name="rotation" type="gml:AngleType"/> </sequence> </extension> </complexContent> </complexType>  <element name="Ellipse" type="xls:EllipseType"/>  <element name="CircularArc" type="xls:CircularArcType"/>  <annotation> <documentation>A CircularArc is a geometric object defined by LIF (MLP 3.0) which is defined by two arcs (r[1] > r[2]), and two lines that radiate from the center point, at a given start angle and end angle. As with the definitions for circle and ellipse, this object is defined by its parameters: a center point, two radii, and two angles. This represenation can be used only in 2D.</documentation> </annotation> <complexType name="CircularArcType"> <annotation> <documentation>This is Modeled after GML ArcByCenterPointType. </documentation> </annotation> <complexContent> <extension base="gml:AbstractGeometricPrimitiveType"> <sequence> <element ref="gml:pos"/> <element name="innerRadius" type="gml:LengthType"> <annotation> <documentation>The radius of the inner arc.</documentation> </annotation> </element> <element name="outerRadius" type="gml:LengthType"> <annotation> <documentation>The radius of the outer arc.</documentation> </annotation> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

132

</element> <element name="startAngle" type="gml:AngleType"> <annotation> <documentation>The bearing of the arc and radial line at the start.</documentation> </annotation> </element> <element name="endAngle" type="gml:AngleType"> <annotation> <documentation>The bearing of the arc and radial line at the end.</documentation> </annotation> </element> </sequence> <attribute name="interpolation" type="gml:CurveInterpolationType" fixed="circularArcCenterPointWithRadius"> <annotation> <documentation>The attribute "interpolation" specifies the curve interpolation mechanism used for this segment. This mechanism uses the control points and control parameters to determine the position of this curve segment. For an ArcByCenterPoint the interpolation is fixed as "circularArcCenterPointWithRadius".</documentation> </annotation> </attribute> <attribute name="numArc" type="integer" use="required" fixed="1"> <annotation> <documentation>Since this type describes always a single arc, the attribute is fixed to "1".</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>  </schema>

133

Annex A.2: OpenGIS Location Services (OpenLS) Requirements (Informative) 1 Requirements 1.1 Terminology

The key words “must”, “should” and “may” are to be interpreted in the detailed requirements as follows: Must—The item is an absolute requirement in this standard. Should— There may exist valid reasons in particular circumstances to ignore the item, but the full implications must be understood and carefully weighed before choosing a different approach. May—The item will be considered, but further examination is needed to determine if the item should be treated as a requirements. Note that only the Italic versions of these terms are to be interpreted as above. 1.2 General Requirements Note: These requirements were taken from the document entitled: “XML for Location Services (XLS) Requirements”, dated 15 Apr 2002, v1.1, and supersede that document.

These requirements pertain to the exchange of location information for the GeoMobility Server, an open location services platform. As such, these requirements reflect the character and nature of location information exchange for the OpenLS Core Services. The following sponsor observations led to these requirements: §

The location services market demands technology that subscribes to the principal of simplicity so that these services will be widely adopted throughout the wireless-IP realm. The objective is to shield the wireless provider from “GIS complexity”. We are driven by the desire to hit the mainstream with simple, essential, widely adopted capabilities. Also, one size does not necessarily fit all. Consider these technologies that have emerged for wireless IP: o Java: J2ME o SVG: Mobile SVG o kDom and kXML (kxml.enhydra.org)

§

Small form factor mobile terminals with limited memory, power, and processing resources and limited bandwidth demands lightweight solutions for location information exchange. Devices widely available in the market could be classified into three general classes.

134

o Class A - Devices with very limited capabilities like pagers and cell phones o Class B - Devices with moderate capabilities like Palm OS PDA o Class C - Devices with relatively good capabilities like Windows CE devices §

Current network capabilities are very limited in bandwidth. Bandwidth available for devices ranges between 9.6 Kbps and 28.8 Kbps in general

§

Next generation devices will be smarter and therefore will accept location information for limited onboard processing.

§

Back-end server traffic is also a concern. Messages should be as compact as possible.

1.2.1 Usage Scenarios

The usage scenarios for XLS are captured in the use cases for the OpenLS Core Services (see references in section 3). These use cases define the general scope of XLS. Design Guidelines

The following design guidelines were considered for XLS. They are based on participants’ experience in both the wireless community and with the OGC process. They constitute general design guidance toward achieving OpenLS objectives. General Guidelines

1) XLS must be based on current market conditions in terms of available technology, content and industry standards. 2) 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. 3) XLS should have small footprint (compact for transmission to low powered mobile terminals with limited memory). 4) 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. 5) 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 Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

135

OpenLS 1.2

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 Compatible, Consistent and Extensible

1) XLS should be scalable so that it can support a wide variety of devices, users, and applications. 2) 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. 3) XLS should be defined in XML schema (xsd). 4) XLS types should be defined in a way that would give them enough flexibility to be used according to SOAP encoding rules. 5) XLS specification activities should be harmonized with ISO 19133 (Navigation), ISO 19118 (XML Encoding rules) and GML. 6) XLS should be designed so that XLS instances can be transformed (e.g., through an XSLT stylesheet) into GML. 7) An appropriate versioning scheme should be devised to guarantee clear versioning numbers. Detailed Requirements General

1) XLS must be based upon well-defined Abstract Data Types for OpenLS. 2) 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. (Current parsers for the devices do not have XSLT support.) Encoding

1) XLS must encode the Abstract Data Types for OpenLS in a compact form. The effort to keep the model simple goes hand-in-hand with the need to avoid the overhead of unnecessary encoding, decoding and feature construction/deconstruction complexity for users of OpenLS services. 2) XLS should use short tags.

136

3) XLS may use a minimum tag set that is sufficient to meet the encoding requirements for the OpenLS Abstract Data Types. 4) XLS may include binary encodings. 5) XLS should avoid multiple levels of nesting. (Keep the depth of the trees shallow for simplicity and to minimize the size of code written to handle it. This helps to keep the applications installed on wireless devices as small in size as possible.) Properties

1) XLS must support the properties required for Abstract Data Types for OpenLS. 2) Properties must be simple properties. Multiple nesting levels should be avoided in properties to avoid complexity. Metadata

1) XLS should support metadata. Geometry Elements

1) XLS must include point, line, line-string and polygon geometries, per OGC Simple Feature Model. 2) XLS may include other geometries. XLS Feature Relationship Schema

1) 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. 2) XLS must support simple relationships in which relationships do not carry properties. XLS Feature Schema

1) XLS should support a simplified feature model that doesn’t require multiple nesting levels. 2) XLS must support the Abstract Data Types for OpenLS and related operations.

137

OpenLS 1.2

Interface Envelop and Encoding Requirements

This section outlines the requirements pertaining to the encoding of the interfaces (i.e., the Request and Response Parameters) for OpenLS Core Services. 1.3.1 Key Concepts

a) A Client Application is any application that interacts with Core Services, whether it resides on an end-user device or on a server. b) A Request is the XML string that is passed from a Client Application to a Core Service. c) A Response is the XML string that is passed from a Core Service to the Client Application. d) A Session is a series of interactions between a Client Application and one or more Core Services. Those interactions are typically in the form of series of Requests and Responses. e) Well-Known Request Type and Well-known Response Type are Types that are known to both Client Applications and Core Services. f)

In this document we refer to the ‘Request and Response pair’ for a Core Service as: R/R.

1.3.2 General Usage Pattern

Figure 9 illustrates the general usage pattern for XML based R/R in OpenLS. The use case starts with the execution of a Client Application that processes a user’s request for service. This in turn leads to a request for the use of a Core Service, e.g., a Directory Service. The Client Application encodes the request for the Core Service as an XML Request. Using the HTTP/Post method, the XML Request is sent to a Servlet. The Servlet parses the XML Request, and according to the Request tags, generates the proper function call to the Core Service. The Core Service processes the Request and sends back the Response to the Servlet. The Servlet in turn encodes the Response as an XML Response and forwards it to the Client Application. The Client Application in turn decodes the XML Response and applies the proper presentation functions for display on the Client Device. In the case of thin Client Devices, it is possible that parsing of the XML Response is done on the server and the portrayal content is streamed directly to the Client Device.

138

Wireless to IP Gateway

XML Encoding App

HTTP/Post XML Request

Presentation

Client Application

Web Server

Servlet XML Decoding App

getService (p1, p2, pn)

XML Response

OpenLS Core Services

Figure 9. Usage Pattern for OpenLS Request/Response Pairs 1.3.3 Assumptions

1) The architecture is based on connectionless protocol. A Client Application may establish a connection for making a Request, and disconnect right after a Response has arrived. 2) The Client Application knows the Request URI for the OpenLS Core Service. This includes the Port Number. 3) Client Applications are aware of all Interfaces that the Core Service exposes. 4) The Core Service can parse and understand the semantics of the XML Request Parameters generated by the Client Application. 5) Core Services know all the mandatory and optional Request Parameters generated by Client Applications. 6) Client Applications can parse and understand the semantics of the XML Response Parameters generated by Core Services. 7) Client Applications know all mandatory Response Parameters, and possibly some, all, or none of the optional Response Parameters generated by Core Services. If an optional parameter is sent to a Client Application, it is then assumed that the Client Application can understand it; otherwise the Client Application generates an error message or ignores this optional Response Parameter. 1.3.4 General Requirements

The following requirements pertain to both Request and Response Schemas:

139

OpenLS 1.2

1) The R/R schemas must be based on XML Schema, re: W3C Recommendation (2 May 2001). 2) Encoded ADT-based R/R Parameters in XML must be consistent with the encoding guidelines and requirements as stipulated in the latest version of the XML for Location Services (XLS) Requirements (section 0). 3) R/R pairs must be consistent with the XLS ADTs. 4) R/R Pairs must be Well-Known Types. 5) Upon receiving a Request from a Client Application, a Core Service must send at least one Well-Known Response to the Client Application. A Response might be an answer to the Request, an error message, or an acknowledgement of receiving the Request. 6) XML R/R instances must be well formed and valid with respect to their schemas. 1.3.5 Encoding Requirements 1.3.5.1 Naming

1) If applicable, you should satisfy encoding name conventions as stipulated in the latest version of the XML for Location Services (XLS) Requirements (section 0). 2) You should use English descriptors that accurately describe the attribute/element/type, etc. For example, use names like firstName, grandTotal, or CorporateCustomer. Although names like x1, y1, or fn are easy to type because they’re short, they do not provide any indication of what they represent and result in schemas that are difficult to understand, maintain, and enhance. 3) Be consistent in using terminology. You should use terminology that applies for the application domain. For example, if you create an element MobileDevice and the mobile operators call it MobileTerminal, use the latter. 4) You should use avoid long names. Some standards recommend a maximum of 13 characters and some 15 characters. For OpenLS, try to limit names to 15 characters in length. 5) Do your best to avoid the use of abbreviations. If you must use an abbreviation, then be consistent with its use. For example, if you want to use a short form for the word “number”, then you should use something like ‘nbr’ or ‘num’ (it doesn’t really matter what form you use), but be consistent in its use. 6) You should avoid names that are similar or differ only in case. For example Name and name. This aids interpretability of the schema.

140

7) You should avoid names that only differ in their plurality. For example, the attribute names mobileTerminal and mobileTerminals should not be used together. 8) In general, you should use lower case letters, but capitalize the first letter of element names, enumerations and type names. You should use all lower case for attribute names, unless you are using a compound name (see the next requirement). 9) You should use mixed case to make compound names more readable. Specifically, you should use upper case for the first letter in all but the first word of a compound Attribute name (e.g., attributeName), or upper case for the first letter of all words comprising a compound element name, type name or enumeration (e.g. ElementName). 10) Abstract Types should use the keyword ‘Abstract’ in their name. For example, an Abstract Type for Device might be represented as: AbstractDeviceType. 11) You should use an underscore (i.e. ‘_’) to prefix abstract element names (e.g., _Device). 12) You should avoid the use of acronyms. If you find it necessary to use an acronym, you should capitalize all letters. For example, using the acronym ‘GIS’, use GISAttribute for an attribute and GISObject for an element. 1.3.5.2 Structures

1) If possible, you should use Attributes instead of Elements. You should use Attributes if they are simple types and have cardinality = 1, at most. 2) You should avoid using Anonymous Types. Named types allow reuse. 3) You should avoid using the same local Element name for different types. 4) You must use “sequence” blocks instead of “all” blocks within “ComplexType”. Complex types that contain "all" blocks cannot be legally subtyped. 5) You should avoid Anonymous “choice” Blocks. 6) You should only declare List types when necessary. 7) You should avoid unsignedInt, unsignedByte, unsignedLong, and unsignedShort and use facets instead when you need to restrict the domain. 1.3.5.3 Coordinate Systems and Units of Measure

1) You should use degrees as the default units of measure for angles.

141

OpenLS 1.2

2) You should use meters as the default units of measure for distances and coordinates. 3) You should express azimuth in degrees measured clockwise from true north. 4) You should use WGS 84 as the default datum and Coordinate Reference System. 5) You should follow the OGC recommendation for Coordinate Reference Systems (SRS). 6) You should follow the OGC recommendation for Units of Measure. 1.3.5.4 Name Spaces

1) All schemas generated under the OpenLS initiative must set the targetNameSpace attribute value to: http://www.opengis.net/xls. 1.3.6 Request Requirements

Each OpenLS Core Service shall have an XML Request Packet that contains the Request. The XML Request Packet must include at least two main Blocks1, a Header Block and one or more Method Blocks (which will contain the actual requests): 1)

Request Header Block a)

A Request Header Block should contain the username and password for the Client Application.

A Request Header Block should contain the type of the client device, if applicable (based upon a well-known list of known types).

A Request Header Block may contain a client-defined Session Identifier, to be echoed back by the server.

Request Method Block(s) a)

An XML Request should contain zero or more Method Blocks.

A Request Method Block must contain a “global” unique method name (Type NMT) that identifies the method that will be invoked by the Core Service. The term “global” refers to a unique ID that identifies a method in the context of the applicable OpenLS Core Service.

1 This structure is designed for compatibility with a SOAP-based API.

142

A Request Method Block must contain Request Version, which indicates the version of the Request that it supports.

A Request Method Block must contain Response Version, which indicates the version of the Response that the Client Application supports.

A Request Method Block must contain a maximum of one Sub-Block that contains the XML payload (the request parameters) for the specified method.

Each Request Method Block must have a Request Identifier. The Request Identifier is a string that must appear in the Method Request Tag as an ‘ID’ attribute. A Request Identifier must be unique within the scope of a session.

1.3.7 Response Requirements

The XML Response Packet must include at least two main Blocks, a Header Block and one or more Response Method Blocks: Response Header Block

1) a)

A Header Block may include the status of the Response (use a standard list of enumerations for status -- TBD).

A Header Block should contain a Session Identifier, which corresponds with the applicable Request Session Identifier.

Note: The error list associated with the Header Block is for authentication errors and other errors generated for the envelop, whereas error lists associated with a Response Method Block are for individual responses.

Response Method Block(s)

2) a)

An XML Response must contain at least one Response Method Block.

The Response Method Block must contain zero or one Sub-Blocks that contain the XML payload for the specified method.

A Response Method Block must contain Response Version, which indicates the version used to encode the Response.

A Response Method Block may include the status of the Method Response (use a standard list of enumerations for status -- TBD).

A Response Method Block may include zero or more Fault (Error) Elements, which indicate the error status (use a standard enumerated list of errors -- TBD), code and description generated during the scope of the session. [Note: Error handling is based upon the SOAP Fault Element.]

143

OpenLS 1.2

Response Packets may have the same identifier as the Method Request Tag. The ‘ID’ is a must if this method employs a Request Identifier, and it must match the Request Identifier. Having more than one Response Method Block is usually a result of sending more than one Request Method Block.

1.3.8 HTTP Transaction Protocol Requirements 1.3.8.1 HTTP Request Requirements 1)

OpenLS Core Services must conform to HTTP/1.1 Post Request according to IETF RFC 2616.

HTTP/1.1 Post Requests must contain Two Blocks. The first Block must be the header that conforms to HTTP/1.1. The second Block, the body, must contain the content payload of the Request.

HTTP/1.1 Post Request Header Block:

Must include the Content-Length.

Must include the Content-Type. For the purpose of this test bed, the ContentType must be text/xml.

Must contain CRLF (Carriage Return and Line Feed).

HTTP/1.1 Post Request Body Block a)

The Request Block must include the XML payload of the Request.

The following is an example of an HTTP/1.1 Post Request: <SLIR requestVersion=”1.1” responseVersion=”1.4” id=”1> <InputGatewayParameters> <InputMSIDS> <InputMsInformation msIdType="msisdn" msIDValue=” +12066741000”/> </InputMSIDS> </InputGatewayParameters> </SLIR>

1.3.8.2 HTTP Response Requirements

144

OpenLS Core Services must conform to HTTP/1.1 Post Response according to IETF RFC 2616.

HTTP/1.1 Post Responses must contain Two Blocks. The first Block must be the header that conforms to HTTP/1.1. The second Block, the body, must contain the response to the Post Request.

HTTP/1.1 Post Response Header Block

Must include the Content-Length.

Must include a Response code and its corresponding Response String as described in RFC 2616 for HTTP/1.1.

Must include the Content-Type. For the purpose of this test bed, the ContentType must be text/xml.

The Header must contain CRLF (Carriage Return and Line Feed).

HTTP/1.1 Post Response Body Block a)

This block must include the XML String of the Response.

The following is an example of an HTTP/1.1 Post Response:

1.4 Abstract Data Type Requirements

The ADTs are well-known information types that are used by the Core Services, and form the Information Framework for the GeoMobility Server. Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

145

OpenLS 1.2

1.4.1 Address ADT

Address ADT contains address information for a geographic place. Addresses reference and uniquely identify particular points of interest and can serve as the basis for aggregating data for that location. The Address ADT consists of a street address (or intersection), place name (e.g. country, municipality, etc.), postal code, street locator, building locator, and supplemental address information. As used here, addresses are the means of referencing primarily residences and buildings (of all types, where a subscriber may conduct business). 1.4.2 Area of Interest (AOI) ADT

Contains an Area of Interest as defined by a named circle, bounding box, or polygon. Used to as a search parameter or can be displayed for a subscriber (e.g. Hot Zone). 1.4.3 Location ADT

The extensible, abstract type for all expressions of Location that can be used by OpenLS application and services to specify the location of a target or a subscriber. Location is the root of a semantic tree that includes a Point, Position ADT, Address ADT, and POI ADT as its subtypes. 1.4.4 Map ADT

Map ADT contains a rendered map that results from the Map Portrayal Operation of the Presentation Service. It can then be used as input to other Presentation Services. Map ADT consists of content information (format, width and height) and context information (bounding box, center point and scale). 1.4.5 Point of Interest (POI) ADT

A place or entity with a fixed position that may be used as a reference point or a target in an OpenLS service. The POI is the primary output from a Directory Service, and thus, is also the “place” where one might obtain a product or service. It contains name, type, category, address, phone number, and other directory information about the place, product, and/or service. 1.4.6 Position ADT

Position ADT contains any observed or calculated position, in the broad semantic context of the use of the term. It primarily contains a geographic position and quality of position. Position is the primary output from a Gateway Service. Position maps to the semantics of the Location, Shape and Quality of Position elements, as defined in the Mobile Location Protocol (MLP) Specification (Version 3.0, OMA). Thus, it contains the full definition of a position of a Mobile Terminal (Standard Location Immediate Service). Position may also be used by an OpenLS application to represent any position of interest. Position is distinguished from POI, which is a well-known place with a position, name, address, etc. Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

146

1.4.7 Route Instructions List ADT

Route Instructions List ADT contains a list of travel instructions consisting of turn-byturn directions and advisories along the route, ordered in sequence of their occurrence, and formatted for presentation to the user. Route Instructions List ADT is generated by the Route Service and “presented” to a subscriber via the Presentation Service. 1.4.8 Route ADT

The Route ADT is actually two ADTs: Route Summary and Route Geometry. Route Summary contains the route’s overall characteristics, such as its start point, waypoints, end point, transportation type, total distance, travel time, and bounding box. Route Geometry contains a list of geographic positions along the route, ordered in the sequence of planned travel, starting with the position of the route’s origin and ending with the position of the route’s destination. The geometry includes the positions of all nodes along the route, including waypoints. The geometry also includes intermediate points needed to describe the geometric shape of the route segments between each node in the route. These two ADTs are generated by the Route Service and “presented” to a subscriber as routing information, e.g. as a route displayed over a map, via the Presentation Service, or they are used directly by an application to guide a mobile subscriber to their destination.

1.5 Service Requirements 1.5.1 Directory Service requirements 1.5.1.1 General

The definition of request/response pairs defined below will encompass the requirements for both Pinpoint and Proximity Directory Services. The two usages of the Directory Service will be affected by selecting the appropriate optional parameters in the XML schema. 1.5.1.2 Request Requirements

The parameters of the combined Pinpoint/Proximity request must include: Directory Type: e.g., White Pages, Yellow Pages, Green Pages, etc. The Pinpoint query will use parameters that will uniquely identify the Point of Interest. At least one of the following options may be used to identify the target location: Point of Interest Name, identifying a specific location – e.g., Red Dragon Chinese Restaurant; Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

147

OpenLS 1.2

Point of Interest Point, identifying an exact location coordinate of the Point of Interest; Point of Interest Address, identifying the street address of the Point of Interest. The Proximity query will use parameters that will identify a shortlist of candidate locations by distance from a location that may itself be specified by a Pinpoint query, e.g., “Give me the taxi rank nearest to the Red Dragon Chinese Restaurant”. This may involve a combination of Proximity parameters to spatially constrain the search: Proximity Type: type of proximity algorithm – e.g., Linear Distance, Bounding Polygon; Source Location – point for determining proximity (possibly a POI); Proximity Minimum Distance; Proximity Maximum Distance; Proximity WithinBoundary, a polygon for Bounding Polygon search; It will also involve a combination of parameters to constrain the result of the search: Maximum Number of elements to be returned: e.g., nearest 5 restaurants. Sort criteria (attribute to sort on; ascending/descending). Other parameters may be used to constrain the search, resulting in a shortlist of Points of Interest: List of Point of Interest Place/Product/Service types identifying a group of locations with some common attribute - e.g., Restaurants, Restaurants.Asian, Restaurants.Asian.Chinese, Restaurants.Asian.Chinese.Seafood; Formal Categorisation in the form of a Name Reference System, e.g., NAICS, NACE, UPC, specifying the properties appropriate to that Name Reference System; List of one or more keywords; Partial street address, such as State, City or Suburb. The XML Request will comprise a Header Block and a Method Block, according to the Request and Response Encoding Requirements.

148

1.5.1.3 Response Requirements

The parameters of the combined Proximity/Pinpoint response include the required elements of the Point of Interest ADT. The XML Response will comprise a Header Block and a Method Block, according to the Request and Response Encoding Requirements. 1.5.2 Gateway service requirements

The Gateway Service should support the following requirements: Use Case

Priority

Client requests a single mobile terminal’s immediate location.

Client requests single mobile terminal’s periodic location

Client requests multiple mobiles’ immediate location

Client requests single mobile terminal’s triggered location

Client request multiple mobiles’ periodic location

Client requests multiple mobiles’ triggered location

1.5.3 Location Utility service requirements

1.5.3.1 Geocode Service

The following requirements must be supported by the Geocoder Service: Given an Address ADT, must be capable of using an address matching Geocoding algorithm to determine a position for the specified address. Must be capable of performing geocoding using an incomplete address and return the complete set of address information (i.e., a normalized address). Must be able to indicate the number of matches in the response (possibly zero) for a particular address supplied in the geocoding request. Must be capable of processing one or more addresses in a single geocoding request. Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved. 149

OpenLS 1.2

May provide information on the quality of the result using a ‘match code’.

1.5.3.2 Reverse Geocode Service

The following requirements must be supported by the Reverse Geocoder Service: Given a Position ADT, must be able to return one or more locations (i.e., Address ADTs with associated Point geometries), and optionally, the ranges of these locations from the given position, as it is defined in the Position ADT. The form of the returned address(es) must be based upon the user’s preference, as stated in the request. The user should be able to specify a preference of StreetAddress, StreetIntersection, or PositionOfInterest (Place and/or PostalCode). If not specified, the service should default to StreetAddress. Must be capable of returning all location information of a preferred type within an area of interest (AOI ADT – a Circle, Polygon or Box). Must be able to indicate the number of matches in the response (possibly zero) for a given request.

1.5.4 Presentation Service

The main purpose of the Presentation Service is the portrayal of maps, and the portrayal of ADTs as map overlays. The act of portrayal is taking the information from the other OpenLS Core Services (ADTs), adding style and producing output that is easily understood by a user.

DESCRIPTION

Must

Accept output Parameters



Support context parameters



Accept a list of ADT’s



Should

May

150

Provide a base map



Support named styles



Support user defined styles



GetCapabilities *



*GetCapabilities provides a list of the following: layers, styles, formats and SRS’s.

21.3 Route Service Requirements

The Route Service shall support the following functionality: Given a set of route criteria, determine a new route. Determine a route, using the routing criteria of an existing route. The new route may be different than the existing route due to changes in real time traffic, and if the travel start time defaults to the current time, due to transportation network time restrictions, or any other reason. After determining the route, return any combination of the following information: v summary information v route geometry v maps of the route v turn-by-turn instructions and advisories for presentation

151

OpenLS 1.2

Annex A.3: OpenGIS Location Services (OpenLS) Schema, OpenLS 1.1 Changes (Informative)

1. Add geometry to route instruction element.

. Add an attribute: provideGeometry that is boolean and optional to RouteInstructionsRequest. <attribute name="provideGeometry" type="boolean" use="optional" default="false">

Modify RouteInstructionType: to include RouteInstructionGeometry element. <element name="RouteInstructionGeometry" type="xls:RouteGeometryType" minOccurs="0">

Add an attribute: provideBoundingBox that is boolean and optional to RouteInstructionsRequest. <attribute name="provideBoundingBox" type="boolean" use="optional" default="false">

Modify RouteInstructionType: to include RouteBoundingBox element. <element name="BoundingBox" type=" gml:EnvelopeType " minOccurs="0" maxOccurs="1" >

2. Explain usage of “lang” attribute on XLS element.

Add a the following statement into section XXX of the XLS specification: The “lang” attribute of the XLS element may be used to specify a preferred language for formatting responses. For example, this attribute may be used to request that route instructions be returned in alternate languages from the Route Service. Include an annotation element in the lang attribute of the XLS element. The new attribute definition becomes: <attribute ref="xls:lang" use="optional"> <annotation> <documentation>Defines the preferred language used for formatting responses. </documentation> </annotation> </attribute>

Valid values for the xls:lang attribute are defined in XML 1.0 ( which references IETF RFC 1766, which inturn are constructed from two-letter language code defined by ISO 639 and from two-letter country codes as defined by ISO 3166). For example: en-GB, en-US, fr Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

152

3. Allow more than two street intersections.

Remove xls:StreetIntersection and change xls:Street to be unbounded. Change: <element name="StreetAddress" type="xls:StreetAddressType" maxOccurs="unbounded">

Remove: <complexType name="StreetIntersectionType"> <annotation> <documentation>Describes the intersection of two streets</documentation> </annotation> <sequence> <element ref="xls:Street"/> <element name="IntersectingStreet" type="xls:StreetNameType"> <annotation> <documentation>Structured street name for intersecting street.</documentation> </annotation> </element> </sequence> </complexType> <element name="StreetIntersection" type="xls:StreetIntersectionType"> <annotation> <documentation>Street and intersecting street.</documentation> </annotation> </element>

4. Directory Request – SortCriteria / POI properties.

Replace the current description of sortCriteria in section 9.1.5.1 in this standard: Replace the current description of sortCriteria in section 9.1.5.1 in this standard: Attribute to be used for sorting result. Sort may be based upon: POIName, distance or other POIPropertyNameType (e.g., NAICS_type) Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

153

OpenLS 1.2

With: Attribute to be used for sorting the results. It may take on the well-known values of “Name” and “Distance” as well as any other POI property names. Replace the current definition of sortCriteria attribute and simpleType in the schema: <attribute name="sortCriteria" type="xls:SortCriteriaType" use="optional"> <annotation> <documentation>POI property used to sort the result. Could be by distance from the source POI. </documentation> </annotation> </attribute> <simpleType name="SortCriteriaType"> <annotation> <documentation>Defines the POI Property used for sorting the responses</documentation> </annotation> <restriction base="string"> <enumeration value="Name"/> <enumeration value="Type"/> <enumeration value="Distance"/> </restriction> </simpleType> With a definition that does not restrict the values to just “Name”, “Distance”or “Type”: <attribute name="sortCriteria" type="string" use="optional"> <annotation> <documentation>POI property used to sort the result. It may take on the well-known values of “Name” and “Distance” as well as any other POI property names. </documentation> </annotation> </attribute>

154

5. Editorial changes

Make requirements and Annex. Make Gateway consistent with the other services in editing.

6. Add expectedEndTime to route.

Include the attribute: <attribute name="expectedEndTime" type="dateTime" use="optional">

RoutePlanType. Specifies the date and time at which travel is expected to end. The format for the end time is specified as Duration.

7. Change projections of returned content

All of the request methods that implement RequestParameters should have either an attribute or a tag that would control the response projection. to add one more attribute in addition to the ones there, the new attribute would reflect the coordinate system required to use for this request.

This is the definition used by OpenLS for coordinate reference systems, it’s defined in the GML4XLS schema. OpenLS uses this definition for the geometry, and in order to be consistent with the parameters used across different parts of the schema, it’s important to use it. <attribute name="srsName" type="anyURI" use="optional"> <annotation> <documentation>In general this reference points to a CRS instance of gml:CoordinateReferenceSystemType (see coordinateReferenceSystems.xsd). For well known references it is not required that the CRS description exists at the location the URI points to (Note: These "WKCRS"ids still have to be specified). If no srsName attribute is given, the CRS must be specified as part of the larger context this geometry element is part of, e.g. a geometric aggregate.</documentation>

155

OpenLS 1.2

</annotation> </attribute>

It would be an optional attribute with a default to WGS84.

8. Specify preferred distance units in directory responses

Add the following entry to section 9.1.5.1 – Directory Request Parameters: Name

Mandatory?

Data Type

Description

distanceUnit

DistanceUnitType (ADT)

Specifies the unit for measuring distance. Default = “M”

Add a reference to the distanceUnit attribute in the definition of DirectoryRequestType in ADT.xsd: <complexType name="DirectoryRequestType"> <annotation> <documentation>ADT for a DirectoryRequest</documentation> </annotation> <complexContent> <extension base="xls:AbstractRequestParametersType"> <sequence> <element ref="xls:POILocation" minOccurs="0"/> <element ref="xls:_POISelectionCriteria"/> </sequence> <attribute name="sortCriteria" type="xls:SortCriteriaType" use="optional"> <annotation> <documentation>POI property used to sort the result. Could be by distance from the source POI.</documentation> </annotation>

156

9. Schema validation fix

In several xsd files (ADT, LocationUtilityService, PresentationService, RouteService): Import the http://www.opengis.net/gml namespace on line 4. <import namespace="http://www.opengis.net/gml" schemaLocation="gml4xls.xsd"/> 10. Clarify street encodings

Add to documentation that Element value can be encoded as a simplified street value. Modify the following: <complexType name="StreetNameType"> <annotation> <documentation>The data elements that make up the name of a street</documentation> </annotation> to:

157

OpenLS 1.2

<documentation>The data elements that make up the name of a street. There are two valid methods for encoding this information: 1). Use the structured elements and attributes. 2). The element value may contain a simplified string (e.g. 43 West 83rd. Street).</documentation>

11. Documentation change to clarify Street Attributes

This standard should be enhanced to include documentation for the attributes of StreetNameType: directionalPrefix

The direction for a street (e.g., North), placed before the official name.

typePrefix

The street type (e.g., Rd or Ave) specified before the official name

officialName

The name for a street (e.g., Main).

typeSuffix

The street type (e.g., Rd or Ave) specified after the official name

directionalSuffix

The direction for a street (e.g., North), placed after the official name.

An example to include: <Street directionalPrefix="W" officialName="83RD" typeSuffix="ST" /> 12. Correlate a route map with a route instruction.

Changes to RouteMapOutputType (Yellow) <complexType name="RouteMapOutputType"> <annotation> <documentation>Defines the rendered route map output parameters.</documentation> </annotation> <sequence>

158

<element name="BBoxContext" type="gml:EnvelopeType" minOccurs="0"> <annotation> <documentation>Rectangular area to be displayed in the rendered map. If not specified, defaults to full route.</documentation> </annotation>  </element> </sequence> <attribute name="width" type="nonNegativeInteger"> <annotation> <documentation>pixel width of the resulting map</documentation> </annotation> </attribute> <attribute name="height" type="nonNegativeInteger"> <annotation> <documentation>pixel height of the resulting map</documentation> </annotation> </attribute> <attribute name="format" type="string"> <annotation> <documentation>mime type describing the encoding</documentation> </annotation> </attribute> <attribute name="BGcolor" type="string" use="optional"/> <attribute name="transparent" type="boolean" use="optional"/> <attribute name="style" type="xls:RouteMapStyleType" use="optional"/> </complexType> <simpleType name="RouteMapStyleType"> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

159

OpenLS 1.2

<annotation> <documentation>A route map can be either an overview or a maneuver</documentation> </annotation> <restriction base="string"> <enumeration value="Overview"> <annotation>

<documentation>Used to describe the map showing the full route</documentation> </annotation> </enumeration> <enumeration value="Maneuver"> <annotation> <documentation>Used to describe the map showing a particular maneuver (often the maneuver corresponds to a single instruction)</documentation> </annotation> </enumeration> </restriction> </simpleType>

Changes to RouteInstructionType (yellow) <complexType name="RouteInstructionType"> <annotation> <documentation>Defines a single turn-by-turn route instruction or advisory formatted for presentation.</documentation> </annotation> <sequence> <element name="Instruction" type="string"/> <element name="distance" type="xls:DistanceType"/> </sequence> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

160

<attribute name="duration" type="duration" use="required"> <annotation> <documentation>Specifies the duration needed to execute those instructions. Duration is expressed as defined in the W3C defintion. Reference URL: http://www.w3c.org/TR/xmlschema-2/</documentation> </annotation> </attribute> <attribute name="description" type="string"> <annotation> <documentation>Allows the route instruction to be matched with a RouteMapType. For example "maneuver 1"</documentation> </annotation> </attribute> </complexType>

Changes to RouteMapType (Yellow) <complexType name="RouteMapType"> <annotation> <documentation>Defines a route map.</documentation> </annotation> <complexContent> <extension base="xls:MapType"> <attribute name="description" type="string"> <annotation> <documentation>Allows the route instruction to be matched with a RouteMapType. For example "maneuver 1"</documentation> </annotation> </attribute> </extension> </complexContent> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

161

OpenLS 1.2

</complexType>

13. Remove SearchArea from ReverseGeocodeRequest

Delete the SearchAreaType and remove the parameter SearchArea from the ReverseGeocodeRequest 14. Remove devType from RequestHeader

Delete devType from RequestHeader 15. Correct/update document submitters

Change Navtech to NavTeq Correct Serge Margoulies name on the document Add names: Tele Atlas, Telcontar

162

Annex A.4: OpenGIS Location Services (OpenLS) Schema, SOAP Profile (Informative) At some point in the future, the sponsors of this standard intend to support a SOAP profile of OpenLS. However, this will be produced during subsequent testbed project activities. For information purposes, an initial version of a SOAP Profile is presented below. This was contributed by one of the sponsors. Please note that this is informative only (not mandatory). It’s NOT required to implement any SOAP interfaces to be compliant with OpenLS. <?xml version="1.0" encoding="UTF-8" ?> <!-Schema for the SOAP/1.1 envelope This schema has been produced using W3C's SOAP Version 1.2 schema found at: http://www.w3.org/2001/06/soap-envelope Copyright 2001 Martin Gudgin, Developmentor. Changes made are the following: - reverted namespace to http://schemas.xmlsoap.org/soap/envelope/ - reverted mustUnderstand to only allow 0 and 1 as lexical values - made encodingStyle a global attribute 20020825 Original copyright: Copyright 2001 W3C (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved. http://www.w3.org/Consortium/Legal/ This document is governed by the W3C Software License [1] as described in the FAQ [2]. [1] http://www.w3.org/Consortium/Legal/copyright-software-19980720 [2] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620.html#DTD Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

163

OpenLS 1.2

--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/" targetNamespace="http://schemas.xmlsoap.org/soap/envelope/">  <xs:element name="Envelope" type="tns:Envelope" /> <xs:complexType name="Envelope"> <xs:sequence> <xs:element ref="tns:Header" minOccurs="0" /> <xs:element ref="tns:Body" minOccurs="1" /> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType> <xs:element name="Header" type="tns:Header" /> <xs:complexType name="Header"> <xs:sequence> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType> <xs:element name="Body" type="tns:Body" /> <xs:complexType name="Body"> <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"> <xs:annotation> <xs:documentation>Prose in the spec does not specify that attributes are allowed on the Body element</xs:documentation> </xs:annotation> </xs:anyAttribute> </xs:complexType>  <xs:attribute name="mustUnderstand" default="0"> <xs:simpleType> <xs:restriction base="xs:boolean"> <xs:pattern value="0|1" /> </xs:restriction> Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.

164

</xs:simpleType> </xs:attribute> <xs:attribute name="actor" type="xs:anyURI" /> <xs:simpleType name="encodingStyle"> <xs:annotation> <xs:documentation>'encodingStyle' indicates any canonicalization conventions followed in the contents of the containing element. For example, the value 'http://schemas.xmlsoap.org/soap/encoding/' indicates the pattern described in SOAP specification</xs:documentation> </xs:annotation> <xs:list itemType="xs:anyURI" /> </xs:simpleType> <xs:attribute name="encodingStyle" type="tns:encodingStyle" /> <xs:attributeGroup name="encodingStyle"> <xs:attribute ref="tns:encodingStyle" /> </xs:attributeGroup> <xs:element name="Fault" type="tns:Fault" /> <xs:complexType name="Fault" final="extension"> <xs:annotation> <xs:documentation>Fault reporting structure</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="faultcode" type="xs:QName" /> <xs:element name="faultstring" type="xs:string" /> <xs:element name="faultactor" type="xs:anyURI" minOccurs="0" /> <xs:element name="detail" type="tns:detail" minOccurs="0" /> </xs:sequence> </xs:complexType> <xs:complexType name="detail"> <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax" /> </xs:complexType> </xs:schema>

165

OpenLS 1.2

Annex A.5: OpenGIS Location Services (OpenLS) Schema, OpenLS 1.2 Changes (Informative)

1. Address ADT changes 1.1 The lang attribute, in combination with the mandatory country code, forms a locale, which is essential for parsing freeform addresses. <complexContent> <extension base="xls:AbstractLocationType"> <attribute name="addressee" type="string" use="optional"/> <attribute name="countryCode" type="xls:CountryCodeType" use="required"/> <attribute name="language" type="language" use="optional"> <annotation> <documentation>the language of the address to be specified. For example, in Canada, this can be used to specify "FR" (French) as the language. By supporting both country code and language, we allow the "locale" of the address to be fully specified, which assists in parsing of freeform addresses. ISO 639 2-Letter code is expected here.</documentation> </annotation> </attribute> </extension> </complexContent> </complexType>

1.2 Add restrictions (regular expression) to enforce 2-3 letter country code. Modify schema comments to allow 3-letter country codes. <simpleType name="CountryCodeType"> <annotation> <documentation xml:lang="en"> ISO 3166 Alpha-2 Country Codes </documentation>

166

</annotation> <restriction base="string"> <minLength value="2"/> <maxLength value="3"/> </restriction> </simpleType> 1.3 These changes are backwards compatible. The use of the BuildingLocator element would be discouraged but would not be removed from the spec. We also propose the introduction of range elements to handle block faces. 1. Add an attribute named “locator” to StreetAddressType. a. Can accommodate a number, or any other building locator b. “windmill house”, “24E” and “323” are acceptable uses of the locator c. We will adopt the following conventions for representing address ranges in the locator attribute: i. Discontinuous range example: “1-9” means 1,3,5,7,9 ii. Two discontinous ranges: “1-9,2-10” implies 1,3,5,7,9 on one side of block and 2,4,6,8,10 on other side of block iii. Continous range: “1…10” means 1,2,3,4,5,6,7,8,9,10 <complexType name="StreetAddressType"> <annotation> <documentation>A set of precise and complete data elements that cannot be subdivided and that describe the physical location of a place.</documentation> </annotation> <sequence> <element ref="xls:_StreetLocation" minOccurs="0"/> <element ref="xls:Street" maxOccurs="unbounded"/> </sequence> <attribute name=”locator”> <annotation> <documentation>typically used for the street number (e.g. “23”).</documentation>

167

OpenLS 1.2

</annotation> </attribute>

</complexType>

1.4 The “43” highlighted in yellow should be removed: <complexType name="StreetNameType"> <annotation> <documentation>The data elements that make up the name of a street. There are two valid methods for encoding this information: 1). Use the structured elements and attributes. 2). The element value may contain a simplified string (e.g. 43 West 83rd. Street). An example: <Street directionalPrefix="W" officialName="83RD" typeSuffix="ST"/> </documentation> </annotation>

1.5 Add a new acceptable place name, “choume-banchi-go” to accommodate Japanese hierarchies of the form 7-2-22. <Place name=”chome-banchi-go”>7-2-22</Place>

<simpleType name="NamedPlaceClassification"> <annotation> <documentation>The classification for the hierarchy a level of which is defined to be one of five different types: CountrySubDivision, CountrySecondarySubdivision, Municipality, or MunicipalitySubdivision.</documentation> </annotation> <restriction base="string">

168

2. Geocode request Type 2.1 Add “returnFreeForm” Boolean attribute to the GeocodeRequestType. (This does not affect the addressing system of OpenLS, but is closely related).

169

OpenLS 1.2

2. Error codes Motivation For developers using the APIs they need far more information with regard to the error that has been generated. Existing Error code changes

Error code

Change Description

RequestVersionMismatch

Include value of version sent in request

Severity

Error

ResponseVersionMismatch removed ValueNotRecongnized

Include value not recognized

NotSupported

The same

Inconsistent

The same

OtherXML

removed

DeliveryFaliure

The same

SecurityFailure

The same

Unknown

The same

New Added Error codes

Error code

NoResultsReturned

Description

The inputs were correct but didn’t produce a result

Severity

Info/Status

170

TimedOut

The operation timed out on the server side

Warning

InternalServerError

An error has occurred inside the server

Info/Status

DataNotAvailable

The server does not have data coverage

Warning

171

OpenGIS Location Service (OpenLS) Implementation Specification: Core Services (version 1.2.0) — OGC 07-074

Related documents