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