Back at the introduction of iPhone SDK 3.0 (check out the video in the Apple Keynotes podcast), Scott Forstall demo’ed Map Kit, showing how to display locations in with the attractive Maps GUI. He added that turn-by-turn apps would be permitted, with one proviso: “bring your own maps”.

So… what does that really entail and mean?

Well, back up and look at what the iPhone provides. Core Location uses whatever location technologies are available to a device — Skyhook‘s wifi positioning system, cell tower triangulation, and/or GPS — to determine your location. Depending on your hardware, you may also get a course (which indicates a direction of travel) and on iPhone 3GS you can get a heading from the compass, indicating the orientation of the device.

Map Kit, on the other hand, is responsible for displaying location data. Given a location to center on and a zoom level, you can show maps of the location, and decorate the map with annotations (often displayed as push-pins) that represent points of interest on the map.

So what’s missing? The ability to get any kind of location data other than the user’s current position. You can show the user on the map, but there’s little in Core Location or Map Kit that relates the location to what’s around it. Map Kit does provide “reverse geolocation”, so you can get some region information for a point (city, state, country for sure, maybe street if you have a good location). But even if you see streets on your map view, there’s nothing in the provided APIs to tell you what or where those streets are, what’s located on them, or how to move about them.

This is what “bring your own maps” means. Simple iPhone apps might be able to put a bunch of Lat/Lng pairs on a map from some kind of data source (like a database of where you’ve sent tweets from), but can’t really do anything with that data other than display it. Nothing in the provided APIs lets you, say, search for all the Apple Stores in Michigan, or get directions to one of them.

The point of “bring your own maps” was made again in the WWDC Map Kits presentation, noting that there are many map services out there. And this is true. Programmable Web has a nice list of dozens of online geolocation, mapping, and other location services. You just need to pick one, incorporate it into your application, and do whatever logic you’re going to do with the data you receive from it: show points of interest on a map, calculate routes, etc.

I’ve been working on prototyping a geo-app and it turns out that bringing your own maps is a bigger problem than you might think. As an end user, there’s a glut of online map sites to freely play with. But using this data in an iPhone application is quite another story.

The major road blocks come from terms-of-service limitations:

  • The iPhone SDK TOS forbids using any interpreted language, so SDKs that use server-side languages like Java, PHP, etc. are off-limits.
  • Many of the mapping sites put the majority of their work into a JavaScript API, but again, you can’t run JavaScript by itself in an iPhone application (even though this is a much-touted form of development on the Mac, as seen in Dashboard widgets and Quartz Composer).
  • As an upshot of the previous two points, you generally need to find a map service that offers data via a web service, or a similar network protocol. It’s possible that a C or C++ API could be incorporated into a native iPhone app, depending on what libraries it uses (stdio and BSD sockets already being present on the iPhone).
  • Most map providers explicitly prohibit commercial use, at least at their free level of service (which only makes sense… why would they pay to license map data and let someone else make money off it?) Some allow commercial use in specific web-centric scenarios, such as hosting Google Maps on a site that is supported by advertising.
  • Many providers prohibit initiating a search from a sensor-determined location, ie, the GPS-identified current location, which obviates the whole point of many potential iPhone location-based apps.
  • Some providers explicitly prohibit incorporating their mapping data with other providers’. Since Google’s tiles are the visuals for Map Kit, you can’t incorporate data from Bing’s map service into an MKMapView.

So, I spent last night going over the Terms of Service from various providers. Here are the good and bad points (from the POV of developing a paid iPhone app) from each:

  • Google Maps (FAQ, terms)
    • Good: Commercial use OK if freely available (presumably an ad-supported free app would qualify?). Non-web apps specifically permitted (if free).
    • Bad: Can’t use in paid app. HTTP API limited (doesn’t do directions, though this is the top feature request). “Maps Data” API still driven by creation/manipulation of maps, not geo-data by itself. No real-time guidance (10.9.a). Only to be used for displaying Google maps (10.12)
  • Yahoo! Maps (terms)
    • Good: Free, even for some commercial uses. REST web service.
    • Bad: Can’t use with GPS data (1.f.vi), can’t use for anything other than showing Yahoo! maps (1.f.ix).
  • MapQuest (terms)
    • Good: Most (all?) functionality available via HTTP/XML.
    • Bad: Free access is only for evaluation (2.4.b). Not clear if starting your search from a GPS position is prohibited. See if you can make sense of this proviso from section 3, because I can’t:

      “[You may not…] derive results from the Service based on sensor-derived location data or information or input in the form of coordinate data, provided that a coordinate location or location derived by a single sensor, including without limitation a sensor incorporated into, connected to or in communication with any mobile device or system, may be used solely as an origin or destination in deriving a map or direction;”

  • Navteq (terms)
    • Good: Multiple web services
    • Bad: 30-day trial (10K sessions or 10K transactions), then must pay for license. Haven’t yet found the TOS for commercial licensees (the evaluation terms are fairly short, and of course preclude use in commercial apps)
  • Teleatlas (terms)
    • Good: N/A.
    • Bad: C#, VB, and Java only.
  • Bing Maps Web Services (terms)
    • Good: Free terms apparently prohibit only the routing of multiple GPS-located objects (but also prohibit presenting “individual maneuvers” of a route sync’ed to user’s GPS-located position).
    • Bad: Dev Kit for web services requires downloading an .exe (uh, no). Programming reference is all in terms of CLR langauges (C#, VB, J#, etc.) [except possibly for C++ ?]. No integrating with other mapping platforms.
  • OpenStreetMap
    • Good: N/A.
    • Bad: No API. Not even clear how you restrict a search to a geographic area. Web results border on useless (no hits for “subway in grand rapids” or “subway 49525″)

Some of these clearly cannot work in an iPhone application, most notably those that that are built around languages that don’t exist and/or are forbidden on the iPhone (sure, you can probably statically compile a scripting language, but is that really going to be easier than just finding a web service you can call from Obj-C?). Of those that remain, the big question is whether enough of the deal-killers go away with commercial licensing. For example, if you can find points-of-interest or routes with Bing, but can’t put them on a Google Map, then Bing is probably out of the running.

To top it all off, there’s a question of financial viability. Your map licensing model probably needs to match your app’s pay model. If you’re going to charge for your app, you need to make sure the location service you license is fully paid up for as long as your app may be in use out in the field (which is indefinite). If the map service is a recurring fee, maybe you get around this by selling to the user as the app plus n months or years of service, then fund the future use of the app with in-app purchase. Another option if the map service requires periodic payment is to give the app away free, support it with advertising, and use recurring ad revenues to pay the mapping bills. This clearly has both merits and hazards, to say nothing of the dubious prospect of serving up tiny little hard-to-see Google ads if your app is meant to be used in a moving vehicle.

A final point: with so many of the TOSes written with the expectation that they’ll be used in webapps, maybe that’s an equally valid way to go for some applications. After all, iPhone 3.0 provides location awareness in Safari, so you could write a web app that figures out where it is when run on an iPhone.

4 Comments

  • 1. openid.aol.com/sdfisher75 replies at 8th October 2009 um 2:10 am :

    Aren’t you allowed to use Javascript as long as you use Apple’s interpreter to run it?

    Probably a moot point, though.

  • 2. [Time code];&hellip replies at 30th November 2009 um 3:42 pm :

    […] months ago, in Bringing Your Own Maps, I went off on an atypical excursion into the realms of location-based applications and how an […]

  • 3. [Time code];&hellip replies at 5th February 2010 um 12:06 am :

    […] introduction of the iPhone 3.0 SDK when they said “bring your own maps”. I previously detailed my search for a map provider, based on the needs for an iPhone mapping application: an API that can be called from an […]

  • 4. [Time code];&hellip replies at 16th May 2011 um 12:04 pm :

    […] where are the other guys getting their data from? As I wrote in Bringing Your Own Maps, my research revealed that the map data providers’ terms of service for their free services […]

Leave a comment

You must be logged in to post a comment.