Page 1 of 1

Location Based Services: A collaborative approach


Saurabh Bagaria
Sr. Project Manager
saurabhbagaria@gmail.com


For many decades, it has made good business sense to a high-end technology like Geospatial Technology to create a viable and meaningful end-user service like Location Based Service. Market research conducted by BCC Research, predicts the global market for mobile location technologies to increase to over $48.8 billion by 2012.

LBS are one of the key applications of Geo spatial technologies. Though it has a good potential opportunity, the proliferation of these services is limited by many challenges which range from lack of widespread availability of powerful devices, to connectivity issues, cost and affordability etc. This article focuses on one such important constraint i.e. data. There are many challenges associated with data, which is one of the key ingredients for any attractive recipe for geo-spatial applications. These can be operational, technical or business challenges. In this article we will be discussing some of these limitations. We would also like to propose a collaborative solution which is a service oriented, loosely coupled, message based, event driven, common data infrastructure to help tackle some of these limitations.

THE PROBLEM
There has been a lot of development in Geospatial technologies over the past two decades. The industry has taken a big leap forward in hardware, software and data acquisition techniques individually. However, what an end user needs is a solution service and not just an application bundled with some data. In short, what a user needs is a usable application with the relevant data at an affordable cost. There are many challenges with respect to "Relevant Data". Some of the commonly faced issues are: Coverage: There is unlimited data in this world and users have varied needs; there are users who do not require coverage beyond a city, and there are users who would want the service wherever they go without any data degradation. Such users are looking for two features i.e. constant access to the service and consistency in the quality of data in terms of coverage.

Let us consider the case of medical representatives whose job requires them to be constantly on the move and who have to frequently visit new places. They would like to have access to a service that informs them about all the medical facilities and contacts within, say, a 10km range. Such service can be a boon for them and will help improve their efficiency. The problem here is that a local service provider may not have access to regions beyond their targeted user base and the cost of acquiring data in entirety is huge which may not make business sense. Granularity: This is a measure of the size or description of components that make a system. In other words; the relative size, scale, level of detail or depth of penetration that characterizes an object e.g. a yard broken into inches has higher granularity than a yard broken into feet.

There are two aspects to granularity viz. granularity of scale and granularity of features. Both of these are difficult to tackle, unless the data providers have a huge user base. But as the user base increases so does the diversity and the problem here is ever increasing horizon of requirements.

Frequency of update: A user paying for such services would want the latest changes bundled with the application. Even if data acquisition is managed, there are other challenges associated with data updating as the entire service has to go through data standardization checks, rigorous regression and parallel deployments. The cost and time required to update LBS data is high. Geo-rectifying and digitizing a hard-copy map is time and labor intensive Cost: This does not require much of an explanation. There is a huge cost associated with LBS infrastructure and this has to be passed on to the customer, resulting in high charges per bit of data delivered. Intense competition is bringing data rates down and this pushes the pay-back for providers by many years. Cached information within wireless transceivers (across all platforms) for LBS (including mobile search and advertising) brings down the cost per bit of data delivered. To make Location based services widely acceptable the industry has to deliver an optimum solution with acceptable levels of limitations which the common user can afford and not a masterpiece that is too perfect or expensive for regular use. Data Formats: There are many data formats and standards already available and in use by users in the world market. Each data format has its own pros and cons. Applications tightly coupled with data formats have limited interoperability. This has an impact on both the application providers as well as users e.g. application providers get bound to a data provider and a user gets bound to an application provider. Though there are many exchange formats (such as DXF for AutoCAD, MIF for MapInfo and E00 for Arc/Info) that help maximize data interoperability, most of these formats lack unified description methods for spatial objects i.e. different data formats use different data models to describe spatial objects. Thus, after data exchange or format translations, information of the original data cannot be expressed accurately, and information loss occurs. Moreover, real-time updating of spatial data and data consistency cannot be realized via external data exchange.

These issues may appear simple when we look at them individually, but to have services with mass reach and appeal, we will have to deal with all of them. In the next section we propose a collaborative solution aimed at addressing most of these issues. Collaborative Data Interchange Infrastructure (CDII): "A Service oriented, loosely coupled, message based, event driven solution"

APPROACH
The solution we are proposing is inspired by the approach cell phone providers have used to increase their coverage. The key here is to provide the users with what you have, and for what you don't, use someone else's capability. This helps increase capabilities quickly and every time there is a new provider, the entire community grows.

METHODOLOGY
A collaborative data interchange requires adherence to a set of standards and protocols. A universal data standard with voluntary consensus-type standard methods, practices, guides and specifications will ensure high quality & interchangeable data for LBS applications. For this author propose to take lead from OGC WMS & WFS and J UNE 200 8 GIS DEVELOPMENT 45 The goal of this project was to provide all the tools necessary to add complex geospatial data types and services to their applications using a language that's in the comfort zone of the programmer rather than the GIS professional “ ” integrate it with Service oriented architecture (SOA) concepts. OGC would lend the geo spatial data interchange standards and SOA would help provide the base framework and communication protocols. The use of SOA will also promote business agility and deliver IT flexibility. Also web services are already in use by various GIS software's and are accessible using web, which allows the user to retrieve data that others are sharing world-wide. The collaborative data interchange infrastructure would not only require technical fulfillment and adoption of standards, but would also require creation of a geospatial service oriented environment. Each provider would need to expose the common interface which would then be discovered, published and invoked in a standard form. At any given point there will be two separate entities viz. one providing the services and one consuming those. These entities may play either of the roles depending on the user request. Figure 1 is a simplified process flow explaining the concept.
  • Any provider willing to be a part of CDII as a provider would need to expose their services using standard interfaces.
  • These services should be discoverable, which means anyone wanting to use someone else's data capability should be able to find these services using some global directory or service descriptor repository.
  • For capabilities that the provider does not have, they become service consumers to other providers and would follow one of the approaches mentioned below.

- The service consumer should be able to query the capabilities of the service provider. The service provider will send a response stating what data is present (layers, scale, vintage etc.) and what capabilities associated with this data are exposed (GetMap Image, GetFeatureInfo etc)

- Alternatively, the service consumer would send the request to the CDII directory with their requirement and CDII will return the list of providers capable of doing the transaction as well as the cost associated with each one of them
  • The service consumer will then send the actual request to the provider and in turn the provider will send an appropriate response and a transaction will take place.
  • Transaction management should also be taken care, there can be multiple subscription models used for these transactions; like pay per use, fixed duration, fixed area with fixed duration and many more such combinations.
IMPACT
Having providers share their services would soon create an ecosystem that will benefit from anyone new joining the value chain at various levels, help strengthen the capabilities of existing providers and definitely help the end user consumer who is looking for a solution and not just a set of complicated technologies and an incomplete application. Apart from this if a user can have an added capability to create data as per his convenience, it will be an added benefit. This information when created by a user, about a certain point of interest or about a road towards a destination can be made available to public at large by sharing it with the server, as in the case of GPS devices. This will help create information database of unmapped regions.


Fig. 1: Collaborative data interchange model Devyani Sharma* QA Engineer Garima Tiwari* QA Engineer *Pitney Bowes Mapinfo, India


Page 1 of 1