Your SlideShare is downloading. ×
  • Like
Mobile Augmented Reality Using FOSS
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Mobile Augmented Reality Using FOSS


Provides quick overview of open source Mobile Augmented Reality and the results of an integration exercise between GeoServer and Mixare to build a augmented reality application.

Provides quick overview of open source Mobile Augmented Reality and the results of an integration exercise between GeoServer and Mixare to build a augmented reality application.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Presented at FOSS4G 2010 in Barcelona
  • Stats were gathered from searches on repositories using the term “augmented reality” A quick survey of major code repositories reveal few complete AR browser clients
  • There are two major platforms of mobile augmented reality; Android and iOS
  • Currently native apps dominate the AR browser space: Layar, Junaio, Wikitude, and open source browser Mixare Native apps offer the benefits of access to sensors (compass, gps, accelerometer, and video) on the mobile device Developers can build a custom and tailored experience for users
  • Web apps can currently access geolocation through HTML5, but they can not access the phone’s sensors A dev version of Android demoed at Google I/O 2010 showed the browser accessing the accelerometer, but these features could take several years to be implemented in a production version
  • however, the Kamra system (possible release summer 2010) is an AR browser using HTML5 and KML
  • currently AR Browsers based on a web application does not exist
  • Directly sharing data streams/channels (content) between native applications is not possible While many AR providers provide an API for authoring content, this is not an open ecosystem The problem of fragmentation affects both major mobile smart phone devices, software must be tweaked for each version of the OS or device
  • Off-the-shelf MAR software was evaluated for integration. Proprietary clients and open source clients were evaluated, since the purpose was to use existing software. Mixare was chosen because it is an active open source project that has the base functions of a MAR.
  • The geo data server should be able to deliver AR info via XML or JSON. GeoServer was chosen because of its ability to deliver data via the Web Feature Server interface.
  • The first step was to create the data output format used by Mixare, which is similar to GeoName’s JSON.
  • Adding the GeoName JSON format to GeoServer was almost trivial because of GeoServer’s archetype-wfsoutputformat module that simplifies creating custom output formats. The data used was a shape file with points of interest. Most of the data was already contained in the shape file, except for elevation which was requested from GeoName’s elevation service on-the-fly. For protoyping, it was easier to add a J2EE filter to add the distance to the JSON instead of adding a vector parameter. This was a dirty hack, but it worked.
  • The Mixare client was changed to load from GeoServer. There were compilation problems with several different version of Android (1.6, 2.1, and 2.2) and on different phones (HTC Dream, HTC EVO 4G, Motorola Droid). The integration worked in that it displayed the data from GeoServer as intended, but the user experience was not as rich as commercial clients.
  • Given more time I would have approached the exercise differently. First, I would have added a vendor option to the WFS request to fix the J2EE filter hack. Second, I would have tried using a Web Processing Service (WPS) to generate the content. A WPS would support manipulating other data sources before generating the JSON. As a stretch goal, I would have tried to add a markerless tracking service to Mixare.
  • Handset up display (HUD) mode for MAR provides a terrible user experience. Because, Mixare is a basic client (in comparison to commercial MAR applications) this is more evident. MAR applications, at this time, are mostly toys that may provide a momentary unique experience. Although this exercise was successful in showing that integrating open source components to create a MAR platform was relatively easy, the need for a standard AR format is apparent. Currently there is an effort for a W3C POI specification underway. This exercise demonstrates that it is easy to hook up components to provide an experience, but it still requires a degree of familiarity with application programming. The development of a generic HTML5 client would facilitate the publishing of AR experiences and ultimately their uptake


  • 1. Mobile Augmented Reality Using FOSS
  • 2. Open source AR in the wild
    • Stats
      • Google Code: 104
      • SourceForge: 37
      • GitHub: ~75
    • Mostly sketches, ARToolkit projects, libs and utilities
    • Not seeing many full clients
  • 3. Mobile Augmented Reality (MAR) Platforms Android iOS
  • 4. Current MAR Native Applications
  • 5. MAR Web Applications
  • 6. Kamra
  • 7. MAR Web Applications
  • 8. Barriers to open source
    • Walled gardens/silos of AR data
    • Fragmentation
      • Android
        • 1.5, 1.6, 2.0, 2.1,2.2
        • apps vary across carriers
      • Apple
        • iPhone, iPod Touch, iPad
        • iPad video out, determined by application
  • 9. Client choices
    • Evaluated available clients
      • Proprietary: Wikitude, Layar and Junaio
      • Open Source: gamaray and Mixare
    • Commonalities
      • XML/JSON formats
      • Points of Interest
    • Mixare – Android/java, most mature/active OS MAR project
  • 10. Choices of Geo Data Servers
    • Driven by client requirements
      • Required formats mostly XML or JSON based
      • Only point format supported, think POI (Points of Interest)
    • Chose GeoServer
      • Java
      • Familiarity
      • Work for OpenGeo
  • 11. GeoServer
    • Create data output used by Mixare
        • {"status": "OK",    "num_results": 1,    
        • "results": [        
        • { "id": "2827",            
        • "lat": "46.43893",            
        • "lng": "11.21706",            
        • "elevation": "1737",            
        • "title": "Penegal",            
        • "distance": "9.756",            
        • "has_detail_page": "1",            
        • "webpage": " ` %2Fpicture.png"        
        • }
  • 12. GeoServer
    • Almost trivial with Geoserver-archetype-wfsoutputformat
      • Most of data contained in feature
      • Elevation from Geonames service
      • Added distance using a filter to modify response
      • JSON and GeoTools libs available and handy
  • 13. Mixare
    • Compilation
      • Failed on Android 1.6 (HTC Dream)
      • Worked on Android 2.1 (Droid, HTC EVO 4G)
      • Unstable on Android 2.2 – Cyanogen Mod 6.0 (HTC Dream)
    • Works for the most part but user experience is not as rich as commercial clients.
  • 14. Things I would do differently
    • Correctly add vendor option, fix filter hack
    • Create a WPS process to generate content
      • More flexible
      • Included in GeoServer 2.1 (just released)
    • Stretch goal: add markerless tracking to Mixare using Kooaba or other image service
  • 15. Final Thoughts
    • Handset up display clients provide a terrible user experience
    • At this time, MAR are mostly toys
    • Activity towards an AR format and POI spec. is promising but slow.
    • HTML5 client needed
  • 16. Contact
    • Sophia Parafina, OpenGeo (
    • Email: [email_address]
    • Twitter: @spara
    • Blog:
    • Blog twitter: @locatively
  • 17. Image Credits