Introduction of usage limits to the Maps API

When the Maps API Terms of Service were updated in April of this year we announced that usage limits would be introduced to the Maps API starting on October 1st. With October upon us, I’d like to provide an update on how these limits are being introduced, and the impact it will have on your Maps API sites.

The usage limits that now apply to Maps API sites are documented in the Maps API FAQ. However no site exceeding these limits will stop working immediately. We understand that developers need time to evaluate their usage, determine if they are affected, and respond if necessary. There are three options available for sites that are exceeding the limits:

To assist in evaluating whether your site is exceeding the usage limits we will shortly be adding the Maps API to the Google APIs Console. Once available you will be able to track your usage in the APIs Console by providing an APIs Console key when you load the Maps API. If you find that your site does exceed the usage limits each day you can opt to pay for your excess usage by enabling billing on your APIs Console project. We will then start billing excess usage to your credit card when we begin enforcing the usage limits in early 2012.

For very popular sites Maps API Premier is likely to be a more cost effective option. It also offers a number of additional benefits, including terms that permit for-fee and internal use, enterprise technical support, a Service Level Agreement, fixed and invoiced annual pricing, and increased quotas for the Maps API Web Services. For more information on how Maps API Premier could benefit your application please contact the Sales team using this form.

We will announce the availability of the Maps APIs in the APIs Console on this blog later this quarter, and provide more details on how to set up an APIs Console account and update your Maps API application with an APIs Console key. We will also provide at least 30 days notice on this blog before enforcement of the usage limits and billing for excess usage begins.

We understand that the introduction of these limits may be concerning. However with the continued growth in adoption of the Maps API we need to secure its long term future by ensuring that even when used by the highest volume for-profit sites, the service remains viable. By introducing these limits we are ensuring that Google can continue to offer the Maps API for free to the vast majority of developers for many years to come.

 

How the Google Maps API limits affect your site

Several weeks ago we shared an update about the introduction of usage limits to the Google Maps API. Today I’d like to provide additional details about these limits, the types of sites that may be affected, and as promised, equip you with the means for measuring your site’s Maps API usage.

Usage limits and affected sites

Usage limits are being introduced to secure the long term future of the Maps API, while minimising the impact on developers. We have purposefully set the usage limits as high as possible – at 25,000 map loads per day – to minimise the number of affected developers, while ensuring that the service remains viable going forward. Based on current usage, only the top 0.35% of sites will be affected by these limits, meaning that the Google Maps API will remain free for the vast majority of sites.

We recognise that sites may occasionally experience spikes in traffic that cause them to exceed the daily usage limits for a short period of time. For example, a media site that uses a map to illustrate a breaking news story, or a map-based data visualization that goes viral across social networks, may start to generate higher traffic volumes. In order to accommodate such bursts in popularity, we will only enforce the usage limits on sites that exceed them for 90 consecutive days. Once that criteria is met, the limits will be enforced on the site from that point onwards, and all subsequent excess usage will cause the site to incur charges.

Please be aware that Maps API applications developed by non-profit organisations, applications deemed by Google to be in the public interest, and applications based in countries where we do not support Google Checkout transactions or offer Maps API Premier are exempt from these usage limits. We will publish a process by which sites can apply for an exemption on the basis of the above criteria prior to enforcement of the limits commencing. Non-profit organizations are also encouraged to apply for a Google Earth Outreach grant, which provides all the additional benefits of a full Maps API Premier license.

Evaluating API usage by your site

To help you measure your site’s Maps API usage, we have now added the Maps API to the Google APIs Console. The Google APIs Console is a centralised dashboard for Google’s developer offerings, and we encourage all developers, no matter how big or small your application, to create an APIs Console account.

We are initially introducing the limits for Maps API v2 and Maps API v3 map loads. The Maps Image APIs, and differentiated pricing and limits for Maps API v3 Styled Maps, are not currently included in the APIs Console, but will be added in the future. Once you’ve created an APIs Console account, please follow the instructions in the Maps API documentation to enable Maps API v2 or Maps API v3 on your APIs Console Project, and update your application to provide your APIs Console key when loading the Maps API.

After updating your Maps API application, you will begin to see your usage reported in the APIs Console.

 

via: GoogleGeoDevelopers

Android’s New Public APIs in ICS

 

 

Since Android is open-source, anyone can look at the code and see how it works inside. If you do this, you’ll notice that most but not all of the APIs arepublicly documented.

If they’re publicly documented, they’re part of what we consider the Android Application Framework. This means their tests appear in the Compatibility Test Suite (CTS) so that our hardware partners have to prove that the APIs work, and that we promise to try very hard not to change them and thus break your code.

In almost every case, there’s only one reason for leaving APIs undocumented: We’re not sure that what we have now is the best solution, and we think we might have to improve it, and we’re not prepared to make those commitments to testing and preservation.

We’re not claiming that they’re “Private” or “Secret” — How could they be, when anyone in the world can discover them? We’re also not claiming they’re forbidden: If you use them, your code will compile and probably run. And in fact we know of quite a few apps out there whose developers have used undocumented APIs, often to good effect. It’s hard to get too upset about this in cases where there’s a useful API that we haven’t gotten around to stabilizing.

But the developers who use those APIs have to be prepared to deal with the situation that arises when we move them from the undocumented outside into the Android Application Framework. Fortunately, this is reasonably straightforward. Also we take a close look at Android Market, using our in-house analytics tools, to get a feel for the impact when we know one of these changes is coming.

There are a few such changes coming up in the Android 4.0 “Ice Cream Sandwich” (ICS) release of Android. We wanted to take the opportunity to combine these words on undocumented APIs with some specifics about the changes.

Calendars

Let’s start with the good news: As of ICS, the Android Framework will include a fully-worked-out set of APIs for accessing Calendar data. You can guess the bad news: Quite a few developers have built apps (including many good ones) using the undocumented Calendar APIs, some using fairly low-level access to the calendar database. Unfortunately, these integrations were unsupported, and prone to breakage by platform updates or OEM customization of calendar features.

We want to see lots of good calendar apps and extensions that work reliably across Android devices, and aren’t broken by platform updates. So we decided to create a clean API, including a comprehensive set of Intents, to manage calendar data in ICS. Now anyone can code against these new APIs and know that Android is committed to supporting them, and that partners have to support these APIs as part of CTS.

Once the new APIs arrive, you’re going to have to update your apps before they’ll run correctly on ICS while still working on older releases. There are a variety of techniques for doing that, many of which have been featured on this blog, including reflection and lazy loading. Recently, we introduced Multiple-APK support, which could also be used to help with this sort of transition.

Text To Speech

Android has never really had a text-to-speech API at the Framework level, but there was unofficial access at the C++ level. With ICS, we will have a fully-thought-through application-level API running on Dalvik, so you can access it with ordinary Java-language application code.

The old C++ API will no longer be supported, but we’ll have a compatibility layer that you can use to bridge from it to the new API. We think it should be easy to update for ICS with very little work.

Doing the Right Thing

We recognize that this means some work for developers affected by these changes, but we’re confident that Android programs in general, and both Calendar and TTS apps in particular, will come out ahead. And we also think that most developers know that when they use undocumented APIs, they’re making a commitment to doing the right thing when those APIs change.