Tech R&D: Allowing lots of hotspots

Many geo-located apps such as Curzon Memories, are concerned with local geographical areas with perhaps tens of spatial hotspots. The current AppFurna

Many geo-located apps, such as Curzon Memories , are concerned with local geographical areas with perhaps tens of spatial hotspots. The current AppFurnace platform provides a very convenient way of incorporating those hotspots and linked content when an app is built. However, this static approach has two serious limitations for scenarios such as that envisaged for City Strata :

  • it does not scale to support apps that require, say, hundreds of thousands of spatial hotspots
  • it does not allow spatial hotspots and their associated content to be added, modified or deleted after the app is released


The full-blown service imagined for City Strata has both of those requirements - large scale and dynamic content. We need another approach.

Our basic strategy in this project is to use hotspots and content stored in the cloud rather than in the app itself, and to download information to the app as required to enable geo-located media presentation. There are a number of cloud-based services, such as Parse , that can hold geo-tagged locations. In this project, of course, we are integrating the online database at the heart of the Know Your Place service provided by Bristol City Council.

We will say more about downloading content in a subsequent post. Here, we will focus just on managing the spatial hotspots themselves, exploring several approaches that balance simplicity, responsiveness and flexibility.

Load hotspots on startup

The prototype Cinemapping app implements the simplest shift away from a completely static approach by fetching its spatial hotspot data (and associated text and image links) from the Cinemap layer of Know Your Place when it is started by the user. From then, the app operates as if the hotspots had been incorporated when it was built.

This approach is straightforward to develop and test, and has the advantage of being unaffected by connectivity problems once the hotspot data has been downloaded. On the other hand, it shares some of the scale and update limitations associated with the static approach.

Trigger hotspots in the cloud

At the other extreme, we can invert the relationship by making the online service responsible for checking the user’s location against spatial hotspots. In this approach, the app simply tracks the user’s position and sends that information to the online service. The service runs algorithms to determine whether the user has triggered a hotspot and sends an appropriate notification back to the app. On receipt of the notification, the app renders the associated content just as the current prototype does when it detects that a hotspot has been entered.

As you might expect, this approach overcomes the scale and update limitations exhibited by the approaches described so far. The online service tests the user’s position against a large and up-to-date database of spatial hotspots. Moreover, the triggering algorithms can themselves now be modified and tuned without needing to rebuild, re-submit and distribute an updated app. The approach also works well when the app is backgrounded - location tracking can be maintained by an app and position updates sent within the constraints imposed by, for example, iOS. Notifications directed to background apps are reported to the user who can then choose whether to foreground the app again and view the resulting content.

The drawbacks mirror the advantages of the earlier approaches. Though the app itself can be a little simpler, the overall system is likely to be more complex because it requires an online service capable of tracking and testing the location of many users in the context of many hotspots. That’s certainly possible but introduces a greater engineering challenge than a service simply serving hotspot data. In addition, the app’s behaviour is now much more sensitive to interruptions in both the phone’s network connectivity and the operation of the service itself. Finally, there may be users who are uncomfortable with the fine-grain online tracking of their location that the approach implies.

Cache nearby hotspots

Our favoured approach is to combine elements of both approaches just outlined, in which:

  • the app tracks the users location and reports coarse-grain changes to the online service
  • the service responds with data on hotspots near to the user’s current location
  • the app then users fine-grain location tracking to detect that the user has entered a hotspot and triggers associated content


This approach is illustrated in the video below which shows a demo app maintaining a cache of the nearest ten hotspots within 1km as the user moves across the city. The green circle represents the scope of the current “radar sweep”, and the orange blobs represent the Know Your Place cinema memory hotspots in that sweep.

(For those interested in technical details, the demo app connects to an intermediate service implemented in node.js and running on DotCloud that itself connects to both Know Your Place and Parse.)

By caching hotspots in this way, we can:

  • handle lots of hotspots in the service and a relevant few in the app
  • reflect changes made to hotspots since the user was last in that area
  • minimise latency on geo-triggers due to roundtrips between the app and service
  • reduce the app’s dependency on comprehensive network connectivity. The app only contacts the service every kilometre or so, and has several opportunities to do so before moving out of the region of the cached hotspots
  • reduce the performance requirements of the service which now needs to process location information from users much less frequently than before
  • address user concerns by reporting only coarse grain locations


For the background mode, we can use use iOS’s ability to monitor the cached hotspots on an app’s behalf, or revert to server-side monitoring. In either case, we will need to introduce notifications to signal to the user that a hotspot has been triggered and that associated content is available once the app is foregrounded again.

Next steps

The demo illustrates the potential of a combined approach but a full implementation of the online service is beyond the scope of the current project. We may choose to incorporate some elements in the Cinemapping prototype. In the meantime, we also need to consider the masses of associated online content...