Philadelphia, May 2–4, Architecture and Design Considerations for Mobile Location Based Services Prof. Mike Jackson Centre for Geospatial Science University of Nottingham UK Dr Chris Tucker President/CEO IONIC Enterprise Inc. Alexandria, VA.

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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 $ will see well in excess of 700m new mobiles sold. If 30% of UK population spent £1 per week annual revenue > £1billion.

Philadelphia, May 2–4, 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….

Philadelphia, May 2–4, 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)

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, So is LBS likely to drive similar change?

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, So what does this give us / demand from us? The best 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!

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, Some comments on the database (2): 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.

Philadelphia, May 2–4, Some comments on the database (3): 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.

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, Communicating the Spatial Information Five years ago we had …….

Philadelphia, May 2–4, Communicating the Spatial Information We fairly quickly had good colour maps

Philadelphia, May 2–4, Communicating the Spatial Information 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.

Philadelphia, May 2–4, 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

Philadelphia, May 2–4, 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.

Philadelphia, May 2–4, Thank you. Questions?