Philadelphia, May 2–4, 2005 Architecture and Design Considerations for Mobile Location Based Services Prof. Mike Jackson Centre.

Philadelphia, May 2–4, 2005

www.locationintelligence.net

Architecture and Design Considerations for Mobile Location Based Services

Prof. Mike JacksonCentre for Geospatial ScienceUniversity of NottinghamUK

[email protected]

Dr Chris Tucker

President/CEO

IONIC Enterprise Inc.

Alexandria, VA.

[email protected]



Summary

•LBS have had a slow start but will become all pervasive

•LBS is not the same as GIS

•If GIS community is to play in LBS market it needs to

understand the drivers of its new customer base

•There will be challenges at all levels – data, system design,

delivery, support, …

•The paper highlights some of the issues to be addressed.



Why are LBS appealing to consumers?

Where am I? Location fixing

Where is the nearest 4* hotel? Directory Services

How do I get there? Routing and Navigation

What’s on near me? Location based services / entertainment

Where are my friends? Buddy finder

Give me a guided tour Guided tour with maps, photo’s and voice

Find me a date! Location based dating

Tempt me with a shopping treat Location / context sensitive ads



Why are LBS of such interest to business?

•Because mobility and location are central to peoples use of mobile communications

•Globally applicable - they at not age, sex, nationality or even very life-style dependent

•They will be as much part of people’s life-style and an integral part of collective social behaviour as mobile voice communication is

•Because though per use revenue may be small potential volume could mean big $. 2005 will see well in excess of 700m new mobiles sold. If 30% of UK population spent £1 per week annual revenue > £1billion.



So what’s the problem?Isn’t LBS just a re-wrapping of GIS?

Yes:

Conceptually -- LBS is just a new name for an old concept

And:

Algorithmically -- Most geospatial algorithmic problems

solved long ago mathematically and practically ….. but….



So what’s the problem?Isn’t LBS just a re-wrapping of GIS?

But:• Data wise --- Capture of suitably structured location data still a big problem - $$$$

spent by NAVTEQ and TeleAtlas and on-going and only represents vehicle routing

and navigation element.

• The under-pinning architecture required by LBS differs significantly from

what GIS provides

And:

•The user interaction model needs to be radically different (again data +

architecture issues)



Many parallels with web-mapping

•With the explosion in the availability and use of the Internet a new demand was generated

•To meet this demand required new software platforms and new approaches to marketing

•And with the shift in user base and platform it opened the way for new suppliers to step-in with more appropriate technology and business models. These suppliers now dominate this market.



So is LBS likely to drive similar change?



Emerging characteristics of ‘3G’ wrt LBS

• High band width + always on connectivity to data services

• Colour displays + good graphics potential – but still tiny screen

• Client-end processing and mass storage potential

• Accurate (metres) device self-locate [LSS GPS + INS]

• Data centric focus - wide range of app’s and x-app synergies

• High-res still / video camera for location data enrichment



Potential of 3G LBS and Business Services

• Potential to exploit rich data content

• Potential to exploit detailed mapping and imagery

• Potential to customise and personalise services

• Potential to exploit device location awareness

• Both service push and pull opportunities



So what does this give us / demand from us?

The best < worst?> of both GIS and web-mapping worlds ….

• Accurate location and precision app’s detailed mapping/content

• Very large data bases – e.g. in UK, terabytes

• Need for rich data models to deliver wide range of app’s

• Need for real-time response

• Need to service very large numbers of users

• Need for enterprise-wide architecture – integral links to CRM,

Billing, . Location Server, business logic, etc.

• And all communicated through a tiny hand-held device!



Design Considerations (1)

• Scalable, high performance, spatial database

• Flexible data modelling

• Rich and efficient geospatial functionality

• Data aggregation and conflation capabilities

• Global applicability + performance across wide range of app’s

• Flexible user communication and portrayal capabilities



Design Considerations (2)

• Future-proof architecture – flexibility and extensibility

• Both server and client-side capabilities needed

• Compatibility with Enterprise-wide architecture

• Fast to market approach for initial services

• Adaptability to respond rapidly to market fads and fashions



Some comments on data issues (1):

• Precision location of devices – few metres – drives need for more detailed mapping and precise geocoding of content.

• Most large scale map data has been captured with mapping as the primary objective - attribution and structure of data not optimised for consumer LBS.

• Large scale map data is not comprehensively available for many countries and where generated by Government Agencies may prove difficult to secure on a flexible commercial basis



Some comments on data issues (2):

• Different scales of map data needed to cover range of areas of interest and app’s are often not derived from a single source and not directly compatible.

• Content is often poorly geocoded and/or geocoding is derived from sources not directly compatible.



Some comments on the database (1):

•The combination of:

• very large quantities of structured and image based spatial data • need for rich spatial analysis • support for very large numbers of users • need for near instant response• wireless mobile handsets

poses a challenge for any database supplier.

•Mapping, routing + navigation, geocoding and spatial search and analysis set different and potentially conflicting demands.




•The context within which data may need to be used will be constantly varying + will inevitably lead to compromise in terms of the spatial indexing and search criteria. The operational dynamics of demand with mass consumer LBS are not yet understood.

The intricacies of incremental up-date in a rapidly evolving service and database context are relatively unexplored

The overhead associated with data model evolution needs to be considered from the outset - the applications and system requirements are likely to evolve rapidly as the market matures.




•At this stage multiple data repositories optimised for different operations is almost inevitable if performance thresholds are to be achieved

•Routing and navigation solutions mostly use own data model•Geocoders typically use their own optimised data model•Zone monitoring typically demands a dedicated approach

• The industry has otherwise standardised on the use of Oracle and Oracle Spatial for the major repository and an increasingly wide range of spatial operations. The next couple of years will demonstrate whether this confidence is justified.



Communicating the Spatial Information

• The real challenge for both software engineers and cartographers! Scale, context and customer based generalisation.

• How to answer a spatial query submitted to a high resolution and complex data base in an intuitive manner suitable for a casual user of a mobile in highly variable viewing conditions.

• The user interface to enable the necessary ease and flexibility to initiate the query in the first place will also set challenges.




Five years ago we had …….




We fairly quickly had good colour maps




But facsimile maps are not the answer.

We still know little about how people perceive, communicate about and operate within the space around themselves.

The solution will certainly present both data and marketing-communications challenges.

And because the mobile is servicing such individual and location - application specific needs the portrayal needs to be self-tailoring to be applicable to the user + application instance.



Conclusions (1)We need to:

• Invest more in understanding the needs of the LBS market and LBS users - they are not the same as for GIS

•Need to re-visit how spatial information is perceived by and best

communicated to users.

•Adapt our understanding of LBS data needs and data management requirements

• Separate applications from the software platform technology to

stimulate innovative app’s development and rapid market response



Conclusions (2)

Implications:

• Need for an OGC standards-based architecture which supports interoperability and flexible adoption of ‘best-of-breed’ software and data components to enable rapid market evolution.

• A move away from single vendor and stove- pipe solutions.

• Need for higher domain expertise by the system integrators

responsible for detailed design and delivery.



Thank you.

Questions?

Philadelphia, May 2–4, 2005 Architecture and Design Considerations for Mobile Location Based Services Prof. Mike Jackson Centre.

Documents

isnt lbs

lbs market

summary lbs

lbs likely

pervasive lbs

mobile location

new demand

new suppliers