CG (Computer Graphics) is proudly produced & published
by Technews
Issue Date: August 2002

Building a locations-based service

August 2002
Pat Thomson, Intergraph Systems

For organisations with a mobile workforce, ‘working smarter’ is a constant challenge. Systems and tools must be continually improved to manage the delicate balance between customer service, profitability and effectiveness. Location-based services (LBS) can help improve this balance by:

* Truly mobilising your team - allowing wise decisions to be made instantly in the field.

* Increasing efficiency by empowering workers to make on-site decisions, cutting travel time, and reducing paperwork and administration costs.

* Improving performance through faster responses, less downtime, and more accurate corporate databases.

* Increasing communication both to and from the workforce for better workflow management.

* Improving customer satisfaction and loyalty due to more efficient and better-informed work practices.
Implementing LBS
Before we can start any project, we need to know and understand what the system is going to be used for. Without a clearly defined purpose, we cannot build an effective system.
We must be able to articulate the goals and objectives of the service, and the desired outputs of the service. We need to have an understanding of what applications require the service, and if new applications are required, what they are going to be.
It is essential to clearly define the processing that the service will need to do. Typical LBS applications can include:
* Distance calculations.

* Geocoding operations (Address to Coordinate).

* Network routing problem solving.
Production of maps
* Provision of information pertinent to location.
A traditional corporate application consists of some data, and an end user application allowing the user to interact with that data.
In the classical style, this is achieved via some form of application server, dedicated to the task of providing access to that data. This could be 'read-only' access, or be 'read-write' to allow the end user to perform updates.
The purpose is to interact with the end user application and the corporate back-end systems. It can be viewed as a single point of contact for these applications.
We may even have other types of devices that empower a broader range of end users; for example, personal digital assistants (PDAs), mobile phones, or laptop computers.
For a location-based service, it would be expected that some form of geographical information system (GIS) data access was required.
To access that data, we simply slot in another component that has its own discreet tasks to perform. This is our location service that will interface with the GIS and provide maps as well as answers to spatial queries.
This diagram explains the various components and how they can fit together. To start building our LBS we need three types of data.
* GIS Data.

* Base Mapping.

* Address Geocode sources.

* Route networks.

* Other GIS, eg Points of Interest.

* Positional Information.

* Automated.

* GPS.

* Mobile infrastructure.

* User entered.

* Corporate.

* All the corporate information related to locations.
We also need to consider the different types of applications that will be using the location-based service.
* The Web-based application is an application running on a Web server of any type under any operating system. This application provides the Web client, either a PC or handheld device, with browser functionality to access the location server for spatial content.

* Direct interaction is a thick client application, communicating directly with the location server to access data on the GIS server. The client can be either a desktop device or wireless device, but each device requires its own processing functionality and GUI.
Other applications can include:
* The SMS-based service where the client is a simple cellphone and the application server interacts with the client via SMS messaging.

* The application server can interact with LBS via the location server and XML. (extensible mark-up language, heralded as the best way to meet the electronic data transfer and storage needs of business in the Internet age.)
Once we have clearly documented what we want our LBS implementation to achieve, we need to document the mechanics of how this is to be achieved.
We will start with a Design Specification that should include specific details on:
* Data sets used during processing.

* Comprehensive details of the queries expected to be asked of the service.

* Details of the information required to enable an answer to the query.

* Details on how this information is to be presented to the end user.
The queries that the LBS will need to answer depend on the objectives of the system, but the most frequently used categories will include the following:
* Where am I? Or in other words "Show me a map of my position and surroundings."

* Where is my nearest...?

* How do I get there?

* Show me a map of ...

* What information will I need when I get there?
Queries must be configured to convey the appropriate known information to the LBS, and ask for the required output.
Lastly, we need to look at the data we require. The data can reside on the corporate database, the GIS server or even external data from a commercial data provider.
In this way we have built a typical location-based service solution. In a small way, one only has to think about your last cellphone call or e-mail exchange to catch a glimpse of the benefits afforded by an enterprise that incorporates mobile technology. Of course, those benefits go far beyond simple convenience, speed and accessibility, but a successful mobile IT strategy is rooted in these basic principles.
For more information: Pat Thomson, Intergraph Systems, 011 313 1222,

Others who read this also read these articles

Search Site


Previous Issues