Until recently, iPhone location app designs were limited by the constraints of single-tasked OS capabilities: launch Foursquare and check-in, use Yelp find a nearby place of interest, open another app to update your status and tag it with location.
All of these scenarios require users to have a participatory role in publishing and sharing. This works well for some apps that require active engagement such as broadcasting your Twitter status and where you’ll be later. But an entirely new class of compelling scenarios really shine when you use a technology called geofencing to leverage background location and push location updates up to public and private clouds.
Guest author Tasso Roumeliotis is founder and CEO of Location Labs, the leader in Location-as-a-Service for mobile application developers. You can follow his location stream on Twitter: @Tassor
The interesting nuance here is that the geofence location is relatively static (a traffic accident doesn’t move much), but the geofence time window is extremely dynamic (accident locations appear and disappear). This gets very interesting when you incorporate rapidly moving real-time data, like Twitter feeds.
Place Geofences
Place-based geofences use a stream of continuously pushed location to identify when a user enters or exits a place or static zone. A place may be the local bar or even the state of California. Place and zone data sources are infinite – from restaurants and other POIs to boundaries such as a county, city, zip code, neighborhood, your home, school, or workplace.
If you need more ideas for zone data types, check out UrbanMapping’s geodata catalog, which lists dozens of geodata source types. With places loaded into a geofencing service, you can build Smartphone apps to trigger when a user enters or leaves the static area that you care about. Your app could send an email, text or multimedia alert to the user (“Billy has arrived safely at school!”) or trigger an action such as updating a database.
Imagine a geofence that automatically checks you in to one of your favorite venues, without having to even interact with the Foursquare mobile client. Or when you leave, it checks you out so your friends aren’t wondering where you are.
Dynamic Geofences
Anyone reading this post has heard of, or probably even used, a mobile app that delivers real-time and right-time information to your smartphone app: weather alerts, Amber Alerts, traffic alerts, emergency notifications. With dynamic-feed proximity-based geofencing and geofencing APIs, it’s possible to deliver these dynamic data sources just-in-time as mobile users move within geographic proximity of continuously shifting, moving-target data streams.
The interesting nuance here is that the geofence location is relatively static (a traffic accident doesn’t move much), but the geofence time window is extremely dynamic (accident locations appear and disappear). This gets very interesting when you incorporate rapidly moving real-time data, like Twitter feeds. You could imagine real-time location-aware celebrity sighting notifications where I would receive an alert that Lionel Messi (the best soccer player in the world, who lead my beloved Argentina in the World Cup) was spotted and then geo-tagged and tweeted about around the corner from me.
Also, think about all the “expiring assets” – movie tickets just before showtime, pizza slices post-lunch rush – these could be fed to nearby subscribers, offering discounts. Or maybe an exclusive Gilt sale that lasts a couple of hours.
Peer-to-Peer Geofences
With peer-to-peer geofencing, both the geofence location and the time window are regularly shifting – and the goal is to detect “collision” (nearness) of two very dynamic points as, for example, when we want to detect that two friends are near each other. This is a more advanced feature of a geofencing services aPI because it involves a real time comparison of many streams of location data both for location and time collision (it’s much less interesting to detect that your friend was here a few days ago).
What’s Taking So Long?
The easy part is coming up with these use cases. But Android, Blackberry and WinMo have had background process capability for some time – why haven’t we seen an explosion of these kinds of apps on those platforms?
It turns out that managing background process – especially using location and geospatial calculations – can be very complex. Naïve implementations can be a massive drain on battery life of a phone (leaving the GPS chip on would drain the battery in a few hours). Geospatial calculations can be complex, as is rapid computation of massive amounts of location data.
Producing a scalable, commercial-grade solution is a difficult problem. iPhone attempted to solve some of these issues (like battery drain), the solution is far from ideal. For instance, in our early testing, the iPhone background location API was not reliable out-of-the-box for geofencing. We have a long way to go. But the opportunity is huge and obvious, so I expect we will see much innovation in this area in the coming months as the industry moves into Location 2.0.
Photo by Yaroslav B.