Thursday, June 28, 2012

Google Maps API, now with even more style!

At Google I/O two years ago we launched Styled Maps in the Google Maps API, which allows you to customize the look of the map in your applications. Today we’re rolling out a number of enhancements to Styled Maps that offer more precise control over both the selection of map features to style, and the ways you can style them:

  • You can now specify a precise color for features as an RGB value in addition to the existing adjustment filters for hue, saturation, lightness, and gamma.

  • You can now style the outline stroke of features separately from the interior fill, and the label text separately from any icon.

  • You can now adjust the width of line features such as roads and rivers, and also the width of feature outlines.







If you would like to try designing a map that would suit your site we recommend that you start with the updated Styled Maps Wizard. Once you are happy with your style you can apply it to your Maps API v3 application as detailed in the Styling section of the Maps API documentation.



Web sites like the Submarine Cable Map and the NY Times already use Styled Maps to simplify or soften a map in order to draw more attention to the data provided. Map of the Dead and The Global Transition to a New Economy restyle their maps to fit the house style or theme of their respective websites. There have also been a few maps that are just a little unusual, such as Fata Morgana.



If you need assistance in using Styled Maps for your site, or have any other Maps API related question, we recommend consulting our developer community and support channels. We look forward to seeing how you take advantage of these new Styled Maps features to make even more beautiful and engaging new Maps!




Announcing v201206 of the DFP API


Today we’ve released the newest version of the DFP API, v201206, which adds a significant number of reporting improvements. The new release also fully supports OAuth 2.0 as the authentication mechanism of choice and we encourage you to switch to OAuth 2.0 from ClientLogin or OAuth 1.0a. A full list of improvements from today’s release can be found on our release notes page.




Reporting improvements



In a few of our recent hangouts, we received the feedback that while our reports were great for generating important performance metrics, the CSV files that you downloaded were not always easily machine readable. To make it easier for you to consume reports, we’ve created a new ExportFormat - CSV_DUMP. Below is a list of the features of this new format:




  • Columns are now shown as Dimension.ENUM_VALUE or Column.ENUM_VALUE

  • All money values are now displayed in micro format in the currency of the network

  • All dates are now displayed as YYYY-MM-DD

  • All date-times are now displayed as YYYY-MM-DDThh:mm:ss±hh:mm

  • There is no "pretty printing" of values (i.e. commas) and there is no total row


You may also notice that the v201204 CSV export format has been replaced by CSV_EXCEL, which can be imported into Excel-like products.




As an important note to some of our developers, after upgrading to v201206, you will most likely need to update your code; many column names have changed to reflect a more accurate description of what metrics they are indeed pulling. For example, the column TOTAL_IMPRESSIONS has been changed to TOTAL_INVENTORY_LEVEL_IMPRESSIONS because the v201204 column could only be used with dimensions like AD_UNIT_NAME on the inventory level, i.e. it could not be used with line items, orders, companies or creatives. Alternatively, TOTAL_LINE_ITEM_LEVEL_IMPRESSIONS in v201206 should now be used with dimensions like LINE_ITEM_NAME and ORDER_NAME for instances where you need to include dynamic allocation impressions from AdSense or Ad Exchange line items. To determine how each column should be updated, visit the old column’s reference page and look for the phrase that begins with “Replaced with …”, e.g.



    Replaced with TOTAL_INVENTORY_LEVEL_IMPRESSIONS beginning in v201206.





Lastly, we’ve improved formatting for inventory reports that don’t use top level ad unit views. Most importantly, the duplicate columns clicks and impressions issue for hierarchical views has been fixed and the flat view report will now match how the report is downloaded from the UI.



OAuth 2.0



If you are an eagle-eyed developer, you may have noticed that we recently added OAuth 2.0 information to our authentication page. OAuth 2.0 is now fully supported in the DFP API and we are progressively adding support in our client libraries; Java, Python, .Net , and Ruby currently have full support, while PHP will very soon. In fact, our DFP test playground already uses OAuth 2.0 with the Java library. Please stay tuned to the project sites or the forum for announcements regarding future support.



Our next hangout is July 18th and we’ll be taking your report questions or anything else you might have on your mind. As always, let us know if you have any questions on our forum.




 - , DFP API Team

Google Compute Engine launches, expanding Google’s cloud offerings

Today at Google I/O we were pleased to announce a new service, Google Compute Engine, to provide general purpose virtual machines (VMs) as part of our expanding set of cloud services. Google App Engine has been at the heart of Google’s cloud offerings since our launch in 2008, and we’re excited to begin providing developers more flexible, generalized VMs to complement our fully-managed, autoscaling environment. App Engine has been growing rapidly since leaving preview, and we’re excited about the benefits that Google Compute Engine brings to developers who want to combine the advantages of App Engine’s easy-to-use, scalable, managed platform with the flexibility of VMs.

If you are interested in using VMs with your App Engine applications in the future, let us know by signing up here.


- Posted by Peter S Magnusson, Engineering Director, Google App Engine Team

Speeding up the ad experience: updating ad click referral


If you analyze your own traffic logs, or develop web analytics software, we have some news for you: we’re making a change to how some clicks coming from Google appear in your logs. We're writing this mostly as an industry FYI, because Google Analytics reports will not be affected by this change.



Up to now, referrers for clicks on ads for the term "flowers", for example, would be one of the following:



http://www.google.com/search?...&q=flowers&...

http://www.google.com/aclk?...&q=flowers&...



We’re adding a third possible referrer:



http://www.googleadservices.com/pagead/aclk?...&q=flowers&...&ohost=www.google.com&...



This new referrer is on a different domain named ‘www.googleadservices.com’, and has a new path of ‘/pagead/aclk’. The query is still there as the GET parameter ‘q’ and the originating host for the click is there as the GET parameter ‘ohost’. For example, if the click came from google.ca, the new referrer format would be http://www.googleadservices.com/pagead/aclk?...&q=flowers&...&ohost=www.google.ca&...



We’re making this change because we’re trying to improve the experience of clicking on an ad for our users. For historical reasons, Google currently uses two redirects on two different domains for many of the ads on our site. We are streamlining our infrastructure to remove one of these redirects, which brings users to ad landing pages faster, leading to a better user experience for our users and a better return on ad clicks for our advertisers.



The new referrer format ensures that advertisers will still get the relevant bits of information about a search that drove traffic to their site, but without the extra redirect.



In order to give everyone enough time to change any referrer log parsing software, we’ll be keeping the number of affected searches at a low percentage through July. In August, we’ll be increasing the number of affected queries to 100%. When we’re done, you should expect to see all three forms of the URLs.




Wednesday, June 27, 2012

Go offline with Google Maps for Android


[Cross-posted from the Google Lat Long blog]




Having an Internet connection has always been a key requirement for using Google Maps for Android... until now.



A few weeks ago we told you that offline Google Maps for Android was coming. Now, you can download the latest version of the app in Google Play, then select and save a region of a map from more than 150 countries (including India) for use offline. Whether travelling internationally, carrying a WiFi-only device, heading underground on the subway or restricting your mobile data usage, you can now save up to six large metro areas (e.g., Greater London, or New York City and surrounding area) and use Google Maps for Android to find your way.








Let’s say you find yourself traveling to London this summer. Before you head off on your trip, simply find the area that you’ll be visiting. Then select “Make available offline” from the menu and verify the area that you would like to save.



Below the map, you’ll see we estimate the file size for you, so you know how much space it will take on your device. Once you confirm your selection the map will immediately start downloading.






Save an area and go to My Places to see all your offline maps

If you have GPS enabled on the device, the blue dot will still work without a data connection so you know where you are, and if your device has a compass you can orient yourself without 3G or WiFi connectivity.



So whether you’re traveling internationally or underground, we hope offline maps will help you get around.



Today we’re also releasing a smoother and faster Compass Mode for Street View within Google Maps for Android. It’s the next best thing to being there, because your device becomes a window into a 360-degree, panoramic view of the outdoor or interior location through Business Photos. To experience the improved qualities of this feature you need a device with Google Maps for Android, Android 3.0 or higher and a gyroscope sensor plus version 1.8.1 of Street View on Google Maps.



To learn more about Google Maps for Android features, start here.



Powerful data visualization with Symbols and Heatmaps in the Google Maps API

The Google Maps API provides a robust platform in which you can add geographical context to your data in a variety of ways. Data visualization is therefore one of the elements at the heart of the Maps API, and today we’re introducing two new techniques for visualizing your data in flexible and dynamic ways.



Symbols



At SXSW Interactive in 2011, I attended a session on geotemporal data visualization that made me keen to make it easier for Maps API developers to build visualizations similar to those discussed. For this reason I’m particularly excited to introduce a simple, yet powerful, new concept to the Maps API v3 that we call Symbols.



Unlike the image icons currently used for marking locations on a map, a Symbol is defined as a vector shape. The size, stroke width, color, and opacity of the shape, are all set by the Maps API application and can be dynamically modified. A small number of shapes, such as a circle, are provided by the Maps API, and custom shapes can be expressed as an SVG path.



Symbols open up a wide range of compelling new possibilities for data visualization and visual effects. For example, the below map illustrates the expansion of the Walmart chain of stores between 1962 and 2006:







In addition to using symbols to represent point features you can also decorate polylines with Symbols. One or more symbols, such as an arrowhead, can be placed at fixed positions on the polyline or repeated along the polyline. Because the polyline that has been decorated does not need to be visible, this feature can also be used to created dotted or dashed polylines, and just as the style of the symbols can be dynamically modified, so too can their location on the polyline:







Heatmaps



Developers often ask how they can represent large amounts of data on a map. Improvements in web browser technology have increased the number of markers that can be rendered by a Maps API application, but above a certain threshold the density of markers can overwhelm the user.



An alternative approach is to use a heatmap, and to enable this approach we’re launching support for browser rendering of heatmaps by the Maps API using the new Heatmap Layer. Your Maps API application can define the colour spectrum, intensity range, and behaviour of the heatmap when the map is zoomed. Here’s the Walmart example from above, but this time visualized as a heatmap:





If you have any technical questions about these new features, we recommend engaging with our developer community online, or joining our regular Google Maps API Office Hours. If you’re at I/O come see us in person at Office Hours in the Google Maps developer sandbox. We’d love to to meet you, hear how you’re using the Maps API, and answer any questions you may have!



Google App Engine 1.7.0 Released at Google I/O

Each release is special in its own way, but this time we can’t help but be extra proud. From San Francisco to Sydney we’ve taken an extra week to pack in some of our most widely requested features and prepare a host of talks and announcements for Google I/O.

We’ll be bringing you more information about this release and the future of Google App Engine platform, as well as some exciting announcements from our I/O YouTube live stream. We’ll also be posting highlights from I/O on our blog and Google+, so tune in here for updates the rest of this week.

Without further ado, here are the highlights from our 1.7.0 release:

App Engine SSL for Custom Domains
Starting today, developers can serve their applications via HTTPS on custom domains. We’re offering both SNI and VIP based SSL, which provide both a low cost and universally supported option, respectively.

Server Name Indication (SNI)



  • This allows multiple domains to share the same IP address while still allowing a separate certificate for each domain. SNI is supported by the majority of modern web browsers. SNI is priced at $9/month which includes the serving of 5 certificates.



Virtual IP (VIP):



  • A dedicated IP address is assigned to you for use with your applications.  VIP is supported by all SSL/TLS compatible web clients and each VIP can serve a single hostname, wildcard or multi domain certificate.  A VIP will cost $99/month.




Google App Engine’s additional location - the EU
For the past four years, App Engine applications have been served from North America. However, we understand that every ms of latency counts so we’ve turned up an App Engine cluster in the European Union so that our developers with customers primarily in Europe can have confidence that their site will look as fast as they’ve designed it.

Initially, the Google App Engine cluster in the European Union will be limited to Premier Accounts only. If you are interested in signing up for a Premier Account to get access to our European cluster, as well as Premium Support and invoice billing, please contact our sales team at appengine_premier_requests@google.com.

PageSpeed - Making the Google App Engine Powered Web Faster
At Google we’ve had an ongoing commitment to making the web faster and for almost a year the PageSpeed Service team has been enabling websites to optimize their static content for delivery to end users at lightning fast speed. Today we’re making this service available to our HRD applications with just a few clicks. Use of the PageSpeed Service is priced at $0.39 per GB of outgoing bandwidth, in addition to standard App Engine outgoing bandwidth price.

GeoPoint Support in Search
Our Search team deserved a break after releasing the Search API a month and a half ago, but instead they’ve worked hard to announce exciting improvements at Google I/O. You can now store latitude and longitude as a GeoPoint in a GeoField, and search documents by distance from that GeoPoint.

Other Service Updates
Here are some other amazing updates we have this release:



  • Blob Migration Tool now Generally Available - Since the deprecation announcement for Master/Slave Datastore (M/S), we’ve been continually improving the experience for apps migrating from M/S to HRD. We’re happy to announce that the Blob Migration tool is now generally available, so you can migrate both your Blobstore and Datastore data in one easy step.

  • Application Code Limits Raised from 150MB/version to 1 GB/application - For those of you biting your fingernails every time you update your application, wondering if today will be the day you finally reach the 150MB application version limit, fret not! We’ve updated the application size limit to be 1GB total for all versions of your application. You can check your app’s Admin Console to see the total size of all your application versions. In the future, you’ll be able to purchase more quota to store additional files.

  • Logs API Updates - Paid applications will now be able to specify a logs retention time frame of up to 1 year for their application logs, provided that the logs storage size specified is sufficient for that period. Additionally, we’re introducing some Logs API billing changes so that you can pay to read application logs after the first 100MB. Reading from the Logs API will cost $0.12/gigabyte for additional data over the first 100MB.

  • Go SDK for Windows - We’ve published an experimental SDK for Windows for the Go runtime.




Don’t think these are all the new features we’ve introduced with 1.7.0; we’ve got so much more than just the highlights above. Make your way to our release notes for Java, Python, and Go straightaway to read about 1.7.0. If you have any feedback, we’d love to hear it in our Google Group. We and the whole Stack Overflow community for App Engine have been working hard to answer all your technical questions on the App Engine platform.


- Posted by the Google App Engine Team


Windows is a registered trademark of Microsoft Corporation in the United States and other countries. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Python is a registered trademark of the Python Software Foundation.