Location-based Services Use Case    (2SKP)

Name:    (2SMJ)

Putting Location into Location-based Services - evolving geospatial from maps to spatially-enabled information    (2SMK)

Description:    (2SML)

The development and importance of location-based services (LBS) to programs of federal, state, regional, tribal, and local governments and jurisdictions is growing as the service oriented architectures are being developed and implemented. Allied Business Intelligence estimates that the LBS industry will account for more than $40 billion in revenue by 2006.    (2SMM)

For LBS to thrive within the evolving technical and physical environment we need to address the requirement of defining explicitly what location is and how it is to be characterized. Currently, there are several ‘exchange protocols’ that have been defined for different application pillars (i.e. Health, Justice, etc.) that do not share the same description of location. The characterization of location must be addressed by this COP. The definition must take place at the elemental level within our data and information life cycles (i.e. linkage to Data Reference Model). It must also support the business processes and requirements driving that acquisition of locational information, as well as the interchange and interoperability requirements that sharing that locational information must meet.    (2SMN)

A location-based service (or LBS) is a service provided to the user or client based on their current geographic location. This position can be designated through user entry (address for example on a web portal or a GPS receiver), but often the term implies the use of technologies built into a cellular telephone network that uses triangulation between the known geographic coordinates of the base stations through which the communication takes place. Furthermore, the computational capabilities in mobile devices, ranging from navigational systems in cars to hand-held devices and cell phones, continue to rise, making mobile devices increasingly accessible. One implication is that knowledge of the coordinates is often times owned and controlled by the Service provider and not by the end user, thus being a transparent geospatial function.    (2SMO)

The Global Positioning System and cellular technologies are enabling a new generation of electronic devices that know where they are, and are capable of modifying the information they collect and present based on that knowledge. The Wireless Communication and Public Safety Act of 1999 permits operators of cellular networks to release the geographic locations of users in certain emergency situations, and a range of electronic services are now being developed and offered to assist users in finding nearby businesses and other facilities. A location-based service (LBS) could be defined as an information service that exploits the ability of a person and/or their technology to know where it is, and to modify the information it presents accordingly. The Open Geospatial Consortium has developed a number of initiatives related to technical specifications for LBS.    (2SMP)

Actors:    (2SMQ)

LBS Client Node - an element of the LBS system that acts as a user's portal through which interaction with the ‘localized’ information can be queried or accessed. LBS client nodes can be connected to the Internet by wireless or wired communications and LBS software may be installed and operated on many hardware platforms including, cellular phones, PDAs, GPSs, laptop computers, or desktop computers.    (2SMR)

LBS Server Node - an element of the LBS system that acts as the server of relevant information to LBS Clients or other LBS Server Nodes within or across networks. LBS Servers are typically located within a state, county, or local jurisdiction. LBSs represent the physical location at which the coordination of information and resources to support LBS activities normally takes place. LBSs can be organized by functional discipline (fire, law enforcement, medical services, and so on); by jurisdiction (city, county, region, and so on); or, more likely, by some combination thereof.    (2SMS)

LBS Catalog - an element of the LBS system that catalogs information and services related to the geographic area of interest as it appears in the broader system and acts as an information clearinghouse filter. The LBS Catalog houses metadata records that conform to an LBS Metadata schema.    (2SMT)

LBS Metadata Schema - a metadata schema that provides a template for metadata about information provided into the LBS system and that allows for the proper categorization and classification of incoming information such that it can be properly queried or otherwise provided to clients requesting information from this network. The LBS metadata schema requires that all information is tagged with its geospatial and temporal context so that it can be accessed and assessed appropriately.    (2SMU)

Exchange Standard for Locational Information - Information exchange standard that focuses on defining ‘location’ for geospatial purposes. This is to include the data definition of the elements of ‘location’ as well as the categorization of ‘locational’ types. This exchange standard will be critical for supporting locational data analysis within the LBS system as well as LBS data and information compilation, exchange, and integration with other information sources.    (2SMV)

XML locational notation - XML allows computing machines to share data regardless of the operating system or programming languages used by their peers. At their core, XML Web services are small applications that use XML to share data and functionality amongst themselves across the Internet. XML is an open standard supported by all major operating systems, development tools, and platforms. XML Web services enable communication between previously disparate systems. By embracing XML-based Web services, it enables your services and the business lines it supports to participate in the world of connected computing that will define this decade.    (2SMW)

OGC's OpenLS APIs - These are XML schemas that describe a finite, invariant set of spatial processing function interfaces for geocoding, reverse geocoding, spatial querying, mapping, and routing. The OpenLS objective is to provide a standardized solution for carriers/operators that allows them to choose and implement standard interfaces and components into their LBS systems, ensuring that application developers have standard tools and/or services to use when building LBS applications. The goal of OGC is to facilitate seamless and smooth integration with other OpenLS-compliant GIS engines for the centralized architecture model; thus the more vendors join the cause, the better off the LBS industry will be as a whole.    (2SMX)

Precondition:    (2SMY)

The location-based services themselves must be effectively targeted to key market / business segments (e.g. health and safety, social services, recreation / tourism, emergency response, etc.). The services must provide compelling functionality to these market / business segments, and they must also be relevant to, or a requirement of, the end-user community. The development and adoption of an exchange standard for locational information as well as metadata for the information is critical.    (2SMZ)

Flow of Events    (2SN0)

Possible uses of the LBS use case within specific application areas (from McGeough, 2001) could include but are not limited to:    (2SN1)

Basic Use Case #1 Path - User specifies location through interaction with web interface such as:    (2SNM)

  1. Interactively clicks on a map position    (2SNN)
    1. User specifies location on map interactively    (2SNO)
    2. Location is determined and passed to LBS catalog of services    (2SNP)
    3. Determination is made of all Services within some defined locality of point (i.e. school districts, voting districts, legislative districts, taxation, social services, etc.)    (2SNQ)
    4. Service sends response back to web browser & displays information    (2SNR)
  2. Or interactively enters their address    (2SNS)
    1. User specifies location via address entry into web form    (2SNT)
    2. Address is passed to location service middleware to acquire location (e.g., those provided by Mobilaris, Openwave, TCS, and Telenity)    (2SNU)
    3. Location is determined and passed to LBS catalog of services    (2SNV)
    4. Determination is made of all Services within some defined locality of point (i.e. school districts, voting districts, legislative districts, taxation, social services, etc.)    (2SNW)
    5. Service sends response back to web browser & displays information    (2SOC)

Basic Use Case #2 Path: - User location is determined through a device (cell phone, PDA, etc.) and radiotriagulation/location of that signal or device.    (2SNX)

  1. User initiates interaction from wireless device    (2SNY)
  2. Information on the calls physical communication attributes is passed to location service middleware to calculate location (i.e. GeoMode, etc.)    (2SNZ)
  3. Location once determined is passed to LBS catalog of services    (2SO0)
  4. Determination is made of all known Services within some defined locality of point (i.e. school districts, voting districts, legislative districts, taxation, social services, etc.)    (2SO1)
  5. Service sends response back to the wireless device and displays information    (2SO2)

Postcondition:    (2SO3)

‘Location’ defined: A functional data element standard for the definition of ‘location’ for use within the enterprise architectures of federal, state, local, and other user communities of interest.    (2SO4)

Best Management Practices for XML LBS: Why they are important, how they work, and how they can be taken advantage of today. This would include building Services as well as consuming other third party services within these applications. This use case will also explore the benefits for use case defined lines of business. Through the development of LBS and XML schemas the potential exists to have a completed application that will not require a service provider to install map data, a render engine or a geocoder on any hardware to deliver a piece of geospatially derived information. This can be accomplished through ‘XML calls’ to geo-services provider.    (2SO5)

Services are discoverable. Universal Description, Discovery and Integration (UDDI) is an associated standard that allows an organization that has created an XML Web service to promote it to the developer community. A developer can use a UDDI search engine to find Web services that meet certain criteria and provide needed functionality, regardless of who is providing the Web service. Once discovered, they can begin using them immediately.    (2SO6)

Services are self-describing. Once a Web Service is discovered, the developer can begin using it immediately. All they need is the full URL path to the services WSDL. The WSDL is an XML formatted file that describes every bit of functionality the service supports. Each method, parameter, property, and return value of the service is described in a standard fashion, allowing modern development tools to immediately allow access to the exposed functionality. Given a WSDL, they can create proxy classes that communicate with the service.    (2SO7)

Services conceal complexity. Much of what we do each day in the GIS world IS complex. More than a non-GIS user will endure to use a typical mapping application, and more than a traditional application developer wants to get involved with to ‘just’ integrate location technology into their business application. Any organization wanting to integrate the element of location doesn't necessarily want to develop GIS expertise. They don't want to bear the costs of GIS software and data licensing not to mention the dedicated GIS servers and staff needed to maintain the GIS infrastructure. They simply want to provide their users with compelling applications that just so happen to need these technologies.    (2SO8)

Services are independent: Using XMLWeb Services for LBS development allows these elements to be very independent. Device independent. Programming language independent. Platform independent. These are good things for all of us, and the benefit cannot be overstated. Any developer in the organization can utilize the power of location in their applications, not just the dedicated GIS staff. As well, porting applications from the desktop to mobile devices takes a fraction of the time it used to.    (2SO9)

Smart Client revolution: Smart Clients will continue to change computing. XML Web Services for LBS will be more nimble and increasingly used in configurations. Most typical today is Server to Server. But perhaps the most relevant scenario for the average user is Client to Server communications. Smart client computing, made possible in large part by XML Web services, is upon us. Here, applications running on connected devices ranging from a desktop workstation to a mobile laptop or Tablet PC interact with heavy weight Web services to access data and information. This brings location intelligence to the applications used everyday, when and where you need it. Smart clients will be able to go out over the Web, utilize a Web service, and answer the business problem they face, within the application they are working.    (2SOA)

With technical options outlined through this Use Case, the remaining challenges are how to help organizations with their business models. This includes how to teach them to attract all those users of federal, state, and local information who could use geographic information on a daily basis to answer fundamental questions and meet basic needs that we have the information to deliver on.    (2SOB)