Location Based Services with emphasis on Travel and Traffic Services

1
Location Based Serviceswith emphasis onTravel
and Traffic Services

• Presented to the Joint Steering Group by
• Cliff Kottman
• Open GIS Consortium
• September 11,

2
Definition

• Location Based Services are applications that
  exploit the location or mobility of the Client or
  Server or both.
• Standards that support these services will
• prescribe useful location-based information (for
  example, a sequence of navigation instructions),
  or
• enable the sharing of processes between
  multi-tier architectures (such as emergency
  services) or
• enable a market for open interoperable location
  related components (such as regional repositories
  of points of interest).

3
Overview

• I. Mission and Objectives
• II. Value Proposition
• The Business Case for Sponsors
• The Business Case for Participants
• III. Use Case(s)
• IV. Strawman Conceptual Architecture
• V. Testbed Process

4
I. Mission and Objectives

• The Open GIS Consortium envisions a multi-phased
  initiative that creates and moves Location
  Service capability from testbed to pilot to
  commercial availability while building a
  sustainable team of potential commercial
  providers, and while shaping and following
  relevant international standards

5
Phased Testbed?Pilot?Market Availability
Testbed, Phase 1
Testbed, Phase 2
Pilot A, Phase 1
Pilot A, Phase 2
Pilot B, Phase 1
Pilot B, Phase 2


Pilot N, Phase 1
Pilot N, Phase 2
Commercial Product/Service A
Commercial Product/Service B
Commercial Product/Service C
Commercial Product/Service D

Commercial Product/Service N
6
OGC, Sponsors and ParticipantsA Collaboration
Testbed or Pilot Activity
Sponsor Team
Requirements
Cost-sharing

Funding
Specifications Infrastructure Market
Solutions SCOTS
7
Overall Mission

• Provide a commercial method to deliver real-time
  traffic and tourism information services
• Support the implementation of 511.

8
II. Value Propositions

• Powerful value propositions for
• Sponsors and Participants

9
Value Propositions for Sponsors

• Lower Cost of Raw Traffic Data
• Reduced Operational Costs for Sensor-Based
  Systems
• Deepen our understanding of the requirements for
  quality 511 implementation
• Understand how commercial implementation is best
  suited for a wide geographic (ideally global and
  seamless) implementation

10
Value Proposition for Participants

• Identify and enhance the understanding of the
  relationships between traffic data services and
  the emerging 511 programs.
• Experiment with alternative service regimes and
  approaches
• Understand the nature and quality of the
  information that needs to be delivered
• Identify and understand the role of the vehicle
  in two-way communication mode.

11
Candidate Participants

• State and Local Governments, Auto OEMs, and
• Providers of
• Platforms
• Connectivity Services
• Information Services
• Advertising
• Information Aggregation

• Content
• Horizontal Services
• Wireless Carriers
• Internet Service (ISP)
• Location Technologies

12
Why OGC?

• Technical Know-how
• Geospatial Industry representative (200 members)
• Five years of specification development
  experience
• Proven Record of Sucesses
• Proven Interoperability Program process (4
  testbeds and pilots)
• Consensus driven processes are built in
• Mainstream IT Connection
• Connectivity to mainstream IT community (vendors,
  integrators, and standards liaison)

13
III. Use Cases

• Introduction and Application to Location Services

14
General Use Case Setting (1)
Service Request Payload
Service Requestor
Service Provider
Service Payload
Interface
Interface

• Consensus Interfaces enable Plug-and-Play
• Service Provider Components
• Only Payloads and their Semantics are public

15
General Use Case Setting (2)
Private Structures And Processes
Service Request Payload
Service Requestor
Service Provider
Service Payload
Actor
Component
Interface
Interface
16
General Use Case Setting (3)
Service Request Payload
Service Provider
Service Payload
Service Requestor
Component
Actor
Interface
the system
17
Getting Started Use Case (1)
Register Metadata
Catalog
Metadata Needs and Preferences
2
1
Service Provider ID
3
Service Request
4
Actor
6
Service
1
5
Alternate Service Providers register their
metadata in Catalogs that help identify a service
that best Matches the Actors Needs and
Preferences
18
Getting Started Use Case (2)
1
Request for Capabilities
Capabilities Statement
2
Preferences
3
Service Request
4
Service Requestor
Service Payload
Actor
5
19
Location Services Exploit Repositories (1)

• Gazetteers
• Backdrop Images
• Road Network
• Traffic Conditions
• Yellow Pages
• Weather
• Points of Interest
• Others

(Route) Server
Yellow Pages Repository
Route Repository
PoI Repository
Traffic Data Repository
Backdrop Repository
20
Location Services ExploitRepositories (2)
Provide Route Enriched with Gazetteers,
Backdrops, Traffic, Retail Outlets, Weather, PoI,

Enriched Route
Traveler
(Route) Server
Route Repository
Route Repository
Yellow Pages Repository
Route Repository
PoI Repository
Traffic Data Repository
Backdrop Repository
Route Repository
Weather Repository
21
The PoI Theme and its Regions
A Region of Interest may Overlap
many Repositories
Region 4
Region 8
Region 2
Region 7
Region 9
Region 5
Region 3
Region10
Region 6
Region 11
Region 16
Region 12
Region 15
Region 20
Region 14
Region 21
North America may have many Regions
Repositories must be regional in order To be
authoritative and accurate
22
Regional Authorities/Jurisdictions
Postal zone Area code Census tract Time
zone Countries Cities States Parks Forests Waterwa
ys Waste Water Points of Interest Historic Sites
Military Bases Restricted Fishing Power
Grids Water Distribution Greenways BLM
Lands Reservations Habitats Land Titles Public
Land Survey Cable Networks Traffic Flight Control
Parcels Rights of Way Yellow Page volume School
District Fire District Tour Book Common Natural
Language Watershed Temporate zones Militarized
Zones Cooperatives Backdrop Images Gazetteers
Region 4
Region 8
Region 2
Region 7
Region 9
Region 5
Region 3
Region10
Region 6
Region 11
Region 16
Region 12
Region 15
Region 20
Region 14
Region 21
23
Brokers Serve Thematic and Regional Repositories

Client
Request with Region And Theme in Payload
Broker
Catalog Services are invoked here
Response Payload
Server 1
Server 2
A client may invoke many Regional, Thematic
Repositories with many different servers
Regional Yellow Pages Repository
Regional Route Repository
Regional PoI Repository
Regonal Traffic Data Repository
Regional Backdrop Repository
24
Brokers Serve Thematic and Regional Repositories

Request with Region(s) and Theme(s) in its
Payload
Client
Broker
Metadata
A client may invoke many Regions Themes The
Broker uses registered Metadata to find
appropriate Catalogs
Metadata
Thematic Catalog 1
Regional Catalog 222
Regional Catalog 222
Thematic Catalog 1
Regional Catalog 222
Thematic Catalog 1
Regional Catalog 222
Thematic Catalog 1
Regional Catalog 222
Thematic Catalog 23
Regional Catalog 622
25
Request for Location
GetLocation Payload (object)
Location Service
Location Payload
The Actor and the object may be the same or
different, and each may be mobile or fixed. The
object can have point, curve, segmented curve,
or surface geometry. The GetLocation Payload
must specify the type of location desired in
the return payload.
26
Repository of Fixed Devices

• For a Electric Power Distribution Enterprises
• Poles - Conductors
• Conduits - Manholes
• Transformers - Meters, etc.
• Work Order Processing Requires Location Services
• Regional Repositories Cover their Service Area
• Collectively, they Cover the Electrified World
• Differences in Schema addressed by Thesauri or
  Semantic Translators

27
Types of Location(1)

• Point Geometry
• Curve Geometry
• Segmented Curve, e.g.
• a.   300 yards north of mile marker 143 on
  Interstate 66.
• b.  Between two and three miles downstream from
  reactor 3 on Two Mile Island.
• c.        Third door on the right down this hall.
• - d. At the intersection of 4th street and
  the city limits.
• Surface

28
Types of Location(2)

• Location Name
• Address and address range
• Types of Addresses
• P.O. Box
• Multiple Address Lines
• Rural Routes
• Apartment Numbering
• Address Schema of Countries

29
Types of Location(3)

• Relative Location
• Azimuth and Range
• Pathway (turn directions) (Descriptive
  Directions)
• Auto
• Public transportation
• Pedestrian
• Handicap
• Bicycle
• Electronic Pathways

30
Types of Location(4)

• Route (turn table) Plan
• Time of arrival at each turn
• En-route updates

31
Location Service Concepts

• ? The Device
• Cell phone
• Palm top
• Lap-top
• Kiosk
• Car-based computer
• Cell antenna
• Mobile device
• Display
• ? Actors

• ? The Location
• Point and Reference
• Segmented Line
• Address
• Route
• Descriptive Directions
• Gazetteer
• Direction
• Polygon
• ? Payload Items

• ? The Service
• Routing
• Avoiding Traffic
• Tourism
• Regional Attractions
• Event Handling
• Maps and Backdrops
• Guidance
• Preference
• ? Service Providers

32
Some Basic Use Cases

• Translate Location (to a different type)
• Provide Backdrop
• Locate
• Location Calculus
• Compute Velocity
• Compute Route
• Proximal Analysis

33
More Basic Use Cases

• Proximal Search
• Event Notification
• Stolen Car
• Mayday
• Assistance Request

34
Transform Location
Location, Type-in, and Type-out
Translate Location Service
Location in Type-out
User with preference
Location services must provide the ability to
transform locations between different types
(example geocoding, using gazetteers) , changing
coordinate systems, replacing a lake surface with
the lake name, converting address to WGS84, and
so on.. Actor may be end user, or intermediate
process.
35
Provide Backdrop
Backdrops can be maps, images, custom displays,
or hybrids
Backdrop Repository
Backdrop Server
Backdrop data
User needing Context
Backdrop Request
Backdrop Needs preferences
Backdrop Needs
Backdrop Catalog(s)
Backdrop Broker
Requesting
Target
Target
Backdrop Requester
Device
Device
Device
Catalog IDs
Different applications require different backdrop
data
36
Provide Location
Location data Accuracy Quality etc.
Table of Fixed Locations
User Needing Location
Mobile Location Needs
Location Needs Preferences ID of item To be
located
Location Technology Triangulation, GPS, etc.
Location Broker
Requesting
Target
Target
Location Requester
Device
Device
Device
37
Parameters for Provide Location

• ID of object to be Located
• Type of Location to be returned (includes SRS-ID
  if coordinates are returned)
• Accuracy
• Authority
• Life Expectancy
• Velocity (if mobile)
• Other preferences and defaults privacy, cost,

38
Location Calculus
Request for Location Calculus, preferences
Broker
Location Calculus Service
Thematic And Regional Catalog
Results Payload
Advanced User

• The LocationServices system
• should address queries such as
• Where is the hardware store most convenient to my
  route home?
• What are the three termite control companies
  nearest my home?

Repository
39
Detect Velocity
Request for Velocity (of object)
Periodic Request for Location Of Object
Curious About Velocity
Optimal Velocity Estimate
Kahlman Filter
Note there are alternate architectures
40
Compute Route

• Accepts origin and destination information
• Accepts real-time information (traffic, reverse
  lanes, event direction affected, etc.)
• Accepts type of PathWay
• Pedestrian - Automobile - Bicycle
• Handicap Electronic
• Public Transportation
• Multiple pickup and drop-off
• Accepts target function to optimize (e.g., time,
  cost, distance, or combination)
• Produces an optimal route of the desired type

Traveler
Request for Route with input parameters
Route (optimal for chosen parameters)
Compute Route Service
Real Time Data
41
Proximal Analysis

• Whats Within Proximity And Matches Needs and
  Preferences
• - Walking, or by Auto, etc.
• Points of Retail Outlet
• Whats showing?
• Whats on Sale?
• Open Sessions with discovered hits
• Time to be served
• Special information

Broker
Regional Point of Interest Server
Regional PoI Repository
42
Proximal Search

• Identifies devices of a specified type based on
  proximity (e.g., in a region, within a radius of
  a center).
• Enables identification of potential customers
  based on proximity
• Useful for emergency management by allowing
  officials to poll devices near a sensitive
  location, and to communicate directly with them.
• E.g., what cell phones are in this building?

List Of Proximal Device IDs
Proximal Search with parameters
Proximal Search Service
43
Event Notification

• Assesses impact of events on ones route
• Duration
• Direction
• Hazmat Warning
• Triggers En-Route Update if impact above
  threshold

Updated Route Event Notification
Event Notification parameters
Event Notification Service
External Events
Event description And duration
44
Stolen Car, Mayday, Locked Key, Assistance
Request

• Triggers notification of authorities

preferences
Periodic Locate
Mayday Service
Locked Key Service
Assistance Request Service
Notice
Notice
Feedback
Periodic Notice
Notice
Authorities
45
Some Location Service Topics

• Accuracy
• Authority, Security and Privacy
• Voice
• Wireless
• FM broadcast

46
IV. Strawman Conceptual Architecture
47
General Client-Server Architecture
Client
Server
Legend
Device (and role)

Interface to be defined

Content to be defined

Connection (wireline or wireless)

48
ExampleRouting Information Subset
Route Client
Route Server
Route Repository
Point of Interest Repository
Traffic Data Repository
49
N-Tier Architecture
Requestor, Displayer, Navigation,
Client
Theme and Region Resolution,
Broker
Traffic, Events, Urgent Messages,
External Input
For Processors, Servers, and Operators,
Catalog
Server
Route, Location, Mayday, Locked Key,
Imagery, Map, Road Network, Weather,
Repository
50
New object types

• Object types needing careful definition,
  modeling, and encoding
• Point, Curve, Surface, SRS
• Route, Event, Road Network
• Segmented Line
• Address
• Turn Directions
• Velocity

51
How to Protect Privacy

• Alternatives
• Allow no Proxies
• Requests for location of a personal device must
  be serviced by the device itself
• Owner chooses parameters that allow selective
  access
• Employ a dedicated Proxy Service
• Delegate to a proxy the business of exposing a
  location
• Proxy maintains a list of of devices allowed to
  make location query
• Upon request, proxy checks list and behaves
  accordingly
• Issue a Certificate
• Location interface raises exception unless
  request accompanied with a certificate
• Allows emergency use of Location information

52
Other Ways to Protect Privacy

• Provide Location with Selective Accuracy
• Answer Location Queries with generalized
  information
• More precise to valid needs
• Less precise to unjustified requests
• E.g., Reveal only nearest 1-degree square
• Or, reveal only name of country in which the
  device resides

53
V. Testbed Process
54
Objectives of the OGC Interoperability Program

• To join market requirements (sponsors) and market
  capabilities (participants) in hands-on
  engineering activity that leads to
  interoperability specifications that work in the
  real world.
• To promote quicker time-to-market for
  (participant) products that implement
  interoperability specifications (and are
  responsive to market (sponsor) requirements.
• To involve the user community in the application
  of products implementing interoperability
  specifications
• Making specifications better through feedback
• Building an infrastructure that captures the
  momentum of previous work in a useful, reusable
  environment on the Internet

Specify
Prototype
Test
Demo
Pilot
55
OGC Interoperability Program

• Collaborative, applied RD efforts develop,
  prototype and test candidate specifications
  addressing Sponsor requirements.

• Collaborative efforts apply technology
  implementing OGC specifications to real world
  situations.

• Candidate
• Specifications

OGC Testbeds
Pilot Projects

OGC Specification Development Process
Coordination Function
Technology Infusion

• Candidate
• Specifications

Infrastructure

• On-line infrastructure developed under Testbeds,
  Pilots, and other related activities within
  geospatial community.

56
Testbed Approach