Google Geo Developers Blog

Introducing Google Maps Platform

noreply@blogger.com (MapsDevrel) — Wed, 02 May 2018 19:00:00 +0000

Posted by the Google Maps Platform team

It’s been thirteen years since we opened up Google Maps to your creativity and passion. Since then, it's been exciting to see how you've transformed your industries and improved people's lives. You’ve changed the way we ride to work, discover the best schools for our children, and search for a new place to live. We can’t wait to see what you do next. That’s why today we’re introducing a series of updates designed to make it easier for you to start taking advantage of new location-based features and products.

We’re excited to announce Google Maps Platform—the next generation of our Google Maps business—encompassing streamlined API products and new industry solutions to help drive innovation.

In March, we announced our first industry solution for game studios to create real-world games using Google Maps data. Today, we also offer solutions tailored for ridesharing and asset tracking companies. Ridesharing companies can embed the Google Maps navigation experience directly into their apps to optimize the driver and customer experience. Our asset tracking offering helps businesses improve efficiencies by locating vehicles and assets in real-time, visualizing where assets have traveled, and routing vehicles with complex trips. We expect to bring new solutions to market in the future, in areas where we’re positioned to offer insights and expertise.

Our core APIs work together to provide the building blocks you need to create location-based apps and experiences. One of our goals is to evolve our core APIs to make them simpler, easier to use and scalable as you grow. That’s why we’ve introduced a number of updates to help you do so.

Streamlined products to create new location-based experiences
We’re simplifying our 18 individual APIs into three core products—Maps, Routes and Places, to make it easier for you to find, explore and add new features to your apps and sites. And, these new updates will work with your existing code—no changes required.

One pricing plan, free support, and a single console
We’ve heard that you want simple, easy to understand pricing that gives you access to all our core APIs. That’s one of the reasons we merged our Standard and Premium plans to form one pay-as-you go pricing plan for our core products. With this new plan, developers will receive the first $200 of monthly usage for free. We estimate that most of you will have monthly usage that will keep you within this free tier. With this new pricing plan you’ll pay only for the services you use each month with no annual, up-front commitments, termination fees or usage limits. And we’re rolling out free customer support for all. In addition, our products are now integrated with Google Cloud Platform Console to make it easier for you to track your usage, manage your projects, and discover new innovative Cloud products.

Scale easily as you grow
Beginning June 11, you’ll need a valid API key and a Google Cloud Platform billing account to access our core products. Once you enable billing, you will gain access to your $200 of free monthly usage to use for our Maps, Routes, and Places products. As your business grows or usage spikes, our plan will scale with you. And, with Google Maps’ global infrastructure, you can scale without thinking about capacity, reliability, or performance. We’ll continue to partner with Google programs that bring our products to nonprofits, startups, crisis response, and news media organizations. We’ve put new processes in place to help us scale these programs to hundreds of thousands of organizations and more countries around the world.

We’re excited about all the new location-based experiences you’ll build, and we want to be there to support you along the way. If you're currently using our core APIs, please take a look at our Guide for Existing Users to further understand these changes and help you easily transition to the new plan. And if you’re just getting started, you can start your first project here. We're here to help.

The real world as your playground: Build real-world games with Google Maps APIs

noreply@blogger.com (MapsDevrel) — Wed, 14 Mar 2018 16:02:00 +0000

Posted by Clementine Jacoby, Product Manager, Google Maps APIs
The mobile gaming landscape is changing as more and more studios develop augmented reality games. In order to mix realities, developers first need to understand the real world — the physical environment around their players. That’s why we’re excited to announce a new offering for building real-world games using Google Maps’ tried-and-tested model of the world.

Game studios can easily reimagine our world as a medieval fantasy, a bubble gum candy land, or a zombie-infested post-apocalyptic city. With Google Maps’ real-time updates and rich location data, developers can find the best places for playing games, no matter where their players are.

Completely customize your games

To make it easy to get started, we’ve brought the richness of Google Maps to the Unity game engine. We turn buildings, roads, and parks into GameObjects in Unity, where developers can then add texture, style, and customization to match the look and feel of your game. This means that they can focus on building rich, immersive gameplay without the overhead of scaffolding a global-scale game world.

“With Google Maps data integrated into Unity, we were able to focus our time and energy on building detailed virtual experiences for our users to find virtual dinosaurs in the real world.” - Alexandre Thabet, CEO, Ludia

Create immersive experiences all over the globe

Game developers will now have access to a rich, accurate, and living model of the world to form the foundation of their game worlds. With access to over 100 million 3D buildings, roads, landmarks, and parks from over 200 countries, they can deliver rich engaging game play across the globe.

"We are excited to partner with Google to provide the most up-to-date and rich location data to enable us to create an immersive experience tied to your location. When new buildings or roads are built, we’ll have access to them in our game. Google Maps’ unrivalled location data, covering world-famous landmarks, businesses and buildings, like the Statue of Liberty, Eiffel Tower, London Eye, Burj Khalifa, and India Gate, makes exploring your surroundings a breathtaking experience,” said Teemu Huuhtanen, CEO, Next Games

Design rich and engaging games in the real world

Designing interactions around real-world places at global scale is a huge challenge and requires knowing a lot about a player’s environment. We make it easy to find places that are appropriate, pleasant, and fun to play — no matter where your players are.

"Building game interactions around real-world places at global scale and finding places that are relevant to users and fun to play is challenging. Google Maps APIs helped us incorporate the real-world, user relevant locations into our game. Users from all over the world can experience the Ghostbusters virtual world through our game, leveraging Google's location data." - HAN Sung Jin, CEO, FourThirtyThree Inc.(4:33)

Deliver game experiences at Google-scale

Building on top of Google Maps’ global infrastructure means faster response times, the ability to scale on demand, and peace of mind knowing that your game will just work.

We're excited to be bringing the best of Google to mobile gaming. All our early access partners leveraged ARCore to better understand the user's environment and reach over 100M devices across the ecosystem. At Google we have even more products to help developers – from Google Cloud for your game server needs to YouTube and Google Play for promotional help, and more.

We’ll be featuring a live demo at the Game Developer Conference in booth 823 next week in San Francisco. If you’re interested in building real-world gaming experiences, visit our web page or contact sales.

Updated basemap style for Google Maps APIs

noreply@blogger.com (MapsDevrel) — Tue, 13 Feb 2018 22:23:00 +0000

Posted by Rose Yao, Director Product, Google Maps APIs

Google Maps APIs will soon be updated with a new look and feel to provide an experience in line with the recent updates to Google Maps. Late last year, we refined the color, typography, and iconography of the Google Maps basemap to improve focus, clarity of information, and readability.

This means that the maps in your products will eventually get an update as well, with stylistic changes such as:

New basemap with an updated color scheme and typography
An updated pin style marks points of interest on the map in place of the previous circular icons
Different colors and icons reflecting categories of points of interest (Food & Drink, Shopping, Transport, etc.)

Existing design

New design

Timeline
The transition to the new look will happen over time and by individual API, with an opt-in period (defaulting to the previous style) and an opt-out period (defaulting to the new style) before the new style is enforced.

The first APIs to offer the new look are the Google Maps SDK for iOS and the Google Places API for iOS, which we are launching as opt-in today. To get updates on the timelines for each API, star the following issues on the Maps APIs Issue Tracker.

If you experience any issues with the Google Maps APIs new styles please let us know by creating a bug report.

API	Estimated opt-in launch	Tracking issue
Google Maps SDK for iOS	13 February	Issue 72853293
Google Places API for iOS	13 February	Issue 72853629
Google Maps JavaScript API	14 February (version 3.32)	Issue 72848644
Google Static Maps API	Mid February	Issue 72852782
Google Maps Android API	April	Issue 72780606
Google Places API for Android	May	Issue 72970562

The updated style is already live across all Google products that incorporate Google Maps, including the Assistant, Search and Android Auto. Opt-in to the new style to give your users the same consistent experience no matter how or where they see our maps.

With Google Maps APIs, Toyota Europe keeps teen drivers safe and sound

noreply@blogger.com (MapsDevrel) — Tue, 28 Nov 2017 18:43:00 +0000

Posted by Christophe Hardy, Manager of Social Business at Toyota Motor Europe

Editor’s note: Today’s post is from Christophe Hardy, Toyota Motor Europe’s Manager of Social Business. He’ll explain how Toyota used Google Maps APIs to build an Android app to keep teen drivers safe.

It’s a milestone that teenagers celebrate and parents fear: getting that first driver’s license. For teens, a license means freedom and a gateway to adulthood. For parents, it means worrying about their kid’s safety, with no way to make sure they’re doing the right thing behind the wheel.

We know that the risk of motor vehicle crashes is higher among 16-19-year-olds than any other age group, and that speeding and using smartphones are two of the main main causes. So as part of Toyota's efforts to eliminate accidents and fatalities, we worked with Molamil and MapsPeople to build Safe and Sound, an Android app for European teen drivers. It takes a lighthearted but effective approach to help young drivers stay focused on speed limits and the rules of the road, not on their cellphones. And it can be used by anyone, not just Toyota owners.

One way Safe and Sound combats speeding and distracted driving is by using music. Before parents turn over their car keys, parents and teens download and run the app to set it up. The app syncs with Spotify, and uses the Google Maps Roads API to monitor a teen’s driving behavior. If Safe and Sound determines the teen is speeding, it’ll override the teen’s music with a Spotify playlist specifically chosen by the parent—and the teen can’t turn it off. As any parent knows, parents and kids don’t always agree on music. And there’s nothing less cool to a teen than being forced to listen to folk ballads or ‘70s soft rock. (The embarrassment doubles if their friends are in the car.) The parents’ playlist turns off and switches back to the teen’s only when the teen drives at the speed limit.

The app also helps prevent distracted driving. When it detects the car is moving above nine miles an hour, it switches on a “do not disturb” mode that blocks social media notifications, incoming and outgoing texts, and phone calls. If the teen touches the phone, the app will detect that too, and play the parents' Spotify playlist until the teen removes his or her hand. At the end of the drive, Safe and Sound alerts parents to how many times their teen exceeded the speed limit or touched the phone. Parents can also tap a link in the app that displays the route the teen drove in Google Maps.

Google Maps provided us the ideal platform for building Safe and Sound. It has accurate, up-to-date and comprehensive map data, including road speed limits. The documentation is great, which made using the Google Maps Roads API simple. It also scales to handle millions of users, an important consideration as we roll out the app to more of Europe.

Safe and Sound is currently available in English throughout the continent, with a Spanish version launching soon in Spain, and a Dutch and French version coming to Belgium. And we’re looking to localize Safe and Sound into even more languages.

We hope Safe and Sound helps keep more teens safe, and brings more parents peace of mind. Plus, there’s never been a better use for that playlist of yacht rock classics.

Removing Place Add, Delete & Radar Search features

noreply@blogger.com (MapsDevrel) — Fri, 30 Jun 2017 18:43:00 +0000

Back in 2012, we launched the Place Add / Delete feature in the Google Places API to enable applications to instantly update the information in Google Maps’ database for their own users, as well as submit new places to add to Google Maps. We also introduced Radar Search to help users identify specific areas of interest within a geographic area.

Unfortunately, since we introduced these features, they have not been widely adopted, and we’ve recently launched easier ways for users to add missing places. At the same time, these features have proven incompatible with future improvements we plan to introduce into the Places API.

Therefore, we’ve decided to remove the Place Add / Delete and Radar Search features in the Google Places API Web Service and JavaScript Library. Place Add is also being deprecated in the Google Places API for Android and iOS. These features will remain available until June 30, 2018. After that date, requests to the Places API attempting to use these features will receive an error response.

Next steps

We recommend removing these features from all your applications, before they are turned down at the end of June 2018.

Nearby Search can work as an alternative for Radar Search, when used with rankby=distance and without keyword or name. Please check the Developer's Guide for more details, in the Web Service or Places library in the Google Maps JavaScript API.

The Client Libraries for Google Maps Web Services for Python, Node.js, Java and Go are also being updated to reflect the deprecated status of this functionality.

We apologize for any inconvenience this may cause, but we hope that the alternative options we provide will still help meet your needs. Please submit any questions or feedback to our issue tracker.

Posted by Fontaine Foxworth, Product Manager, Google Maps APIs

Get your users where they need to go on any platform with Google Maps URLs

noreply@blogger.com (MapsDevrel) — Tue, 23 May 2017 21:31:00 +0000

Last week at Google I/O we announced Google Maps URLs, a new way for developers to link directly to Google Maps from any app. Over one billion people use the Google Maps apps and sites every month to get information about the world, and now we're making it easier to leverage the power of our maps from any app or site.

Why URLs?

Maps can be important to help your users get things done, but we know sometimes maps don't need to be a core part of your app or site. Sometimes you just need the ability to complete your users’ journey—including pointing them to a specific location. Maybe they're ready to buy from you and need to find your nearest store, or they want to set up a meeting place with other users. All of these can be done easily in Google Maps already.

What you can do is use Google Maps URLs to link into Google Maps and trigger the functionality you or your users need automatically. Google Maps URLs are not new. You've probably noticed that copying our URLs out of a browser works—on some platforms. While we have Android Intents and an iOS URL Scheme, they only work on their native platforms. Not only is that more work for developers, it means any multi-user functionality is limited to users on that same platform.

Cross platform

So to start, we needed a universal URL scheme we could support cross-platform—Android, iOS, and web. A messaging app user should be able to share a location to meet up with their friend without worrying about whether the message recipient is on Android or iOS. And for something as easy as that, developers shouldn't have to reimplement the same feature with two different libraries either.

So when a Google Maps URL is opened, it will be handled by the Google Maps app installed on the user's device, whatever device that is. If Google Maps for Android or iOS is available, that's where the user will be taken. Otherwise, Google Maps will open in a browser.

Easy to use

Getting started is simple—just replace some values in the URL based on what you're trying to accomplish. That means we made it easy to construct URLs programmatically. Here are a few examples to get you started:

Say someone has finished booking a place to stay and need figure out how to get there or see what restaurants are nearby:
https://www.google.com/maps/search/?api=1&query=sushi+near+94043

The query parameter does what it says: plugs a query in. Here we've specified a place, but if you do the same link with no location it will search near the user clicking it. Try it out: click here for sushi near you.

This is similar to our query above, but this time we got back a single result, so it gets additional details shown on the page:
google.com/maps/search/?api=1&query=shoreline+amphitheatre

The api parameter (mandatory) specifies the version of Maps URLs that you're using. We're launching version 1.

Or if a user has set up their fitness app and want to try out a new route on their bike:
www.google.com/maps/dir/?api=1&destination=stevens+creek+trail&travelmode=bicycling&dir_action=navigate

We can specify the travelmode to bicycling, destination to a nearby bike trail, and we're done!

And we can also open StreetView directly with a focus of our choice to give a real sense of what a place is like:
www.google.com/maps/@?api=1&map_action=pano&viewpoint=36.0665,-112.0906&heading=85&pitch=10&fov=75

The viewpoint is a LatLng coordinate we want to get imagery for, and heading, pitch, and fov allows you to specify exactly where to look.

Need more functionality?

Google Maps URLs are great to help your users accomplish some tasks in Google Maps. However, when you need more flexibility, customization, or control, we recommend integrating Google Maps into your app or site instead. This is where our more powerful Google Maps APIs come into play. With our feature-rich range of APIs, you can access full functionality and can control your camera, draw shapes on the map, or style your maps to match your apps, brand, or just for better UI. And if you want to go beyond the map we have metadata on Places, images, and much more.

Learn more

When you're happy to delegate the heavy lifting and make use of the Google Maps app for your needs, Maps URLs are for you. Check out our new documentation.

Thank you for using Google Maps URLs and the Google Maps APIs! Be sure to share your feedback or any issues in the issue tracker.

Posted by Joel Kalmanowicz, Product Manager, Google Maps APIs

Google Maps and Particle partner to bring location-aware capabilities to IoT devices

noreply@blogger.com (MapsDevrel) — Tue, 16 May 2017 18:34:00 +0000

Posted by Ken Nevarez, Solutions Architect for Google Maps APIs

Particle and Google Maps make it easy for IoT devices to identify their location without the use of a GPS. With a single line of code, a device or sensor dispersed across a network (an IoT edge device) can access Google’s geospatial database of Wi-Fi and cellular networks using the Google Maps Geolocation API.

This means you no longer need to invest in expensive and power hungry GPS modules to know the location of their IoT devices and sensors. Alternatively, you can also use Google Maps APIs in conjunction with existing GPS systems to increase accuracy and provide location data even when GPS fails, as it often does indoors.

Particle and Google now provide the whole chain—location aware devices that send context rich data to Google Cloud Platform. When IoT sensors know their location, the information they collect and send back becomes more contextualized, allowing you to make more informed, high-order decisions. By feeding context-rich data back into Google Cloud Platform, you have access to robust set of cloud products and services.

Although asset tracking is traditionally built on a foundation that includes GPS, satellite based GPS often fails in dense urban environments and indoors. In these scenarios, GPS signals are blocked by tall buildings or roofs. The Geolocation API is based on cell tower and Wi-Fi signals that continue to operate where GPS fails. This capability allows you to track your assets anywhere, both indoor and out.

In an IoT driven world, you can track more than just location. Additional signals can be critical to your objectives. For example, in the cold supply chain, temperature as well as location are key pieces of data to track in the factory, on the loading dock and in transit. This enables a holistic view of the supply chain and its ability to deliver a high quality product.

With a Wi-Fi enabled product built on the Particle platform, you can use the Google Maps Geolocation API to offer location aware auto configuration. This creates a seamless setup experience, enhanced operation and valuable analytics. Using geolocation your Particle devices can auto configure timezone, tune to available broadcast bands and connect to regional service providers.

For example, location aware window blinds can reference the number of available hours of sunlight and then make informed decision on how to passively heat a room. A smart coffee machine can report back its location allowing your marketing teams to better understand its market penetration and target demographic.

Visit the documentation for full directions to enable geolocation on your Particle devices. There are four basic steps to complete:

Get a Google Maps API key enabled for Geolocation.
Flash the Google Maps Firmware on your Particle Devices.
Enable the Google Maps Integration in the Particle Console.
Test it Out!

Google and Particle will be demoing the integration at IoT World beginning May 16. Stop by booth #310 near the main hall entrance to see the demo in person or for more information, review our developer documentation and get started today.

About Ken: Ken is a Lead on the Industry Solutions team. He works with customers to bring innovative solutions to market.

Introducing structured menus in the Google My Business API

noreply@blogger.com (MapsDevrel) — Wed, 26 Apr 2017 21:54:00 +0000

Every day, millions of people search on Google for places to eat and drink and many click to see the menu before making a decision. In fact, the Google search interest in "menu" related queries has seen a 30% increase in the last 2 years*. For businesses, this means they need to provide useful and relevant information to their customers in these moments that matter.

Last December, we enabled Menu URL editing in the Google My Business API allowing businesses to control and manage their menu link on Google Maps and Search. Starting today, businesses that use the Google My Business API can publish their entire menu to Google —itemized with descriptions, photos and prices--making it frictionless for their customers to view their menus on Google.

Arby’s, the quick-serve fast-food sandwich restaurant chain, was one of the first to take advantage of this feature and publish their full menu to Google. Now customers who search on Google for Arby’s can find accurate and up-to-date menu information provided by Arby’s as well as photos of those menu items.

"We update our menu every month with new and limited time offers. With the new Google My Business Menu feature we now have control over our menu data. We are able to provide our menu updates directly to Google via the Yext platform, and our updated menu populates on Google almost instantly. We no longer have to worry about old, unavailable menu items from third party sites showing up." said Sonja Uppal, Arby’s Digital Marketing Supervisor.

Developers can now use the Google My Business API to publish menu data to each of their business locations and see it update on Google in minutes. They’ll be able to publish multiple menus (e.g. breakfast, lunch, dinner) with sections (e.g. salads, entrees, dessert, drinks) that include individual menu items, each with a rich description, photo and price. It's easy to get started with our new developer documentation.

Here's a simple JSON request that shows how to publish a simple breakfast menu to a location:

REQUEST:

PATCH
https://mybusiness.googleapis.com/v3/123456/locations/
654321?languageCode=en-US&fieldMask=priceLists

 {
  "priceLists": [
    {
      "priceListId": "Breakfast",
      "labels": [
        {
          "displayName": "Breakfast",
          "description": "Tasty Google Breakfast",
          "languageCode": "en-US"
        }
      ],
      "sourceUrl": "http://www.google.com/todays_menu",
      "sections": [
        {
          "sectionId": "entree_menu",
          "labels": [
            {
              "displayName": "Entrées",
              "description": "Breakfast Entrées",
              "languageCode": "en-US"
            }
          ],
          "items": [
            {
              "itemId": "scramble",
              "labels": [
                {
                  "displayName": "Big Scramble",
                  "description": "A delicious scramble filled with Potatoes, Eggs, 
                  Bell Peppers, and Sausage",
                  "languageCode": "en-US"
                }
              ],
              "price": {
                "currencyCode": "USD",
                "units": "12",
                "nanos": "200000000"
              },
              "photoUrls": [
                "http://www.google.com/images/breakfast_scramble1.jpg",
                "http://www.google.com/images/breakfast_scramble2.jpg"
              ]
            },
            {
              "itemId": "steak_omelette",
              "labels": [
                {
                  "displayName": "Steak Omelette",
                  "description": "Three egg omelette with grilled prime rib, 
                   fire-roasted bell peppers and onions, saut\u00e9ed mushrooms
                   and melted Swiss cheese",
                  "languageCode": "en-US"
                }
              ],
              "price": {
                "currencyCode": "USD",
                "units": "15",
                "nanos": "750000000"
              }
            }
          ]
        }
      ]
    }
  ]
}

RESPONSE:

Response will contain an instance of the updated Location Object.

To learn more about the Google My Business API and to apply for access, visit our developer page. Questions or feedback? Contact the API team on the Google My Business API Forum.

Posted by Aditya Tendulkar, Product Manager, Google My Business

*Google Trends

A new issue tracker for Google Maps APIs

noreply@blogger.com (MapsDevrel) — Tue, 14 Mar 2017 21:39:00 +0000

Posted by Kasia Derc-Fenske, Technical Solutions Engineer Manager, Google Cloud and Jesse Scherer, Technical Program Manager, Cloud Platform Support

Starting today, we’re working on facilitating better collaboration between you and the Google Maps APIs product teams, by upgrading to Issue Tracker, a tool we also use internally at Google. We have migrated all issues from the old code.google.com tracker to the new Issue Tracker hosted at issuetracker.google.com.

New Google Issue Tracker

Old Google Code issue tracker

Getting started with Google Issue Tracker should be easy. Check out our documentation for more information about how to create, edit, search, and group issues. By default, Google Issue Tracker only displays issues assigned to you, but you can easily change that to show a hotlist of your choice, a bookmark group or saved searches. You can also adjust notification settings by clicking the gear icon in the top right corner and selecting settings. For more information, check out the discussion of notification levels in the developer documentation.

The Google Maps APIs bookmark group

Searching for product-specific issues

Opening any code.google.com issue link will automatically redirect you to the new system. You’ll be able to find all of the issues from code.google.com in the Issue Tracker, including any issue you have reported, commented on, or starred. If you feel like anything is missing, let us know (how meta!) -- we have backups available!

Google Issue Tracker organizes issues into a component hierarchy. Starting at the Google Maps APIs bookmark group, you can drill down to a particular product's issues. And because each product (and some product features) have their own component, you can easily search for them. For example, you can view all Google Maps JS API v3 or Places API reports, which correspond to the old tracker’s full list for Maps API JS v3 and Places API. You can find the full list of Google Maps APIs components in the support section of our developer documentation. To search within those issues, leave the component ID in the search bar; removing it will search public issues from all Google products.

For detailed instructions on how to create issues check out this guide, Still have questions? Take a peek at our FAQ. If you can’t find the answer please let us know by commenting on this post.

The Google Maps APIs team wants your feedback!

Your feedback is important to us and makes a big difference! Make sure to take advantage of the starring feature for any issues you’re interested in to help us prioritize. As an example, after reviewing your feedback, we recently implemented Styled Maps for Google Maps Android API (received 365 stars) and Google Maps SDK for iOS (received 245 stars).

Please continue helping us improve our products by reporting issues and feature requests!

Google Maps APIs sessions at Google Next ‘17

noreply@blogger.com (MapsDevrel) — Tue, 07 Mar 2017 16:22:00 +0000

Next 2017 is just a few days away and we’re looking forward to three days of insightful conversations, amazing technology and, of course, beautiful San Francisco. This year, Google Maps APIs business leaders, engineers, product managers, technical writers, and developer advocates are traveling from Sydney, New York and Mountain View to spend time with our customers and partners. We’re looking forward to sharing how our APIs help build the best location-based experiences for your customers.

Here are our sessions at Google Cloud Next ‘17:

Day 1 (March 8)

Make better business decisions with Google Maps, Dave McClusky (Global Head of Customer Engineering), Adam Evans (Head of Field Sales, US/Canada).
11:20am room 2010

Location as a force multiplier: redefining what's possible for enterprises, Gayathri Rajan (VP Product Management).
1:20pm room 3018

Development best practices for Google Maps mobile and web service APIs, Dave McClusky (Global Head of Customer Engineering), Emily Keller (Technical Program Manager).
2:40pm room 3014

Flexible development with the Google Maps APIs, Ankur Kotwal (Developer Advocate).
4:00pm room 3018

Day 2 (March 9)

The power of Geolocation, Laurence Moroney (Developer Advocate).
11:30am room 3018

Location-powered, on-demand economy: providing value with Google Maps APIs, Vishal Goenka (Group Product Manager).
1:30pm room 3018

Real world gaming: using location data to build immersive mobile experiences, Clementine Jacoby (Associate Product Manager).
2:40pm room 3018

The primary key to location intelligence, Ankur Kotwal (Developer Advocate), Laurence Moroney (Developer Advocate).
4:00pm room 3018

We hope you’re able to attend these sessions to learn directly from the Google Maps APIs team. In the Application Development Showcase, we will also have a number of innovative demos built on the Maps APIs. And, don’t forget to stop by the Meet the Experts zone on Level 1 of Moscone West to chat. If you’re not able to join us in person this year, you can always keep up with our activities via Twitter or Google+.

Posted by Ankur Kotwal, Developer Advocate at Google

Do you like the new look of the Maps APIs tutorials?

noreply@blogger.com (MapsDevrel) — Mon, 20 Feb 2017 16:33:00 +0000

Until recently, our docs have focused on describing features rather than telling a story. We chatted to some developers and came up with a new design for our tutorials. We’d love to know what you think of them.

Developers tell us they want quick, straightforward guides on how to integrate the Google Maps APIs into their app. The most common thing people want to do is to add a map with a marker. Just show me how to do that.

Developers are also looking for complete, step-by-step tutorials for the most common use cases. Guides that go all the way from a to z, with no deviations.

And they want code. Front and foremost. All the code.

Here are some examples of the new-look tutorials:

Adding a map with a marker - web, Android and iOS.
Styling your map - web, Android and iOS.
Showing the business or other point of interest at the current location - Android and iOS.
All the redesigned tutorials for the Google Maps JavaScript API.

Each tutorial provides the entire development project, especially useful for the native mobile APIs. The doc page goes hand in hand with a new sample app on GitHub. For example, here’s the code for the current place tutorial on Android.

Each page includes a visual illustration of what you’ll achieve by following the tutorial. A working demo is ideal (such as the visualizing data tutorial for the Google Maps JavaScript API), otherwise a screenshot (as we’ve done for the native mobile APIs).

We want to make it easy for developers to find the guides. So, we’re adding tutorial showcases to the API overview pages. To date we’ve created the showcases for Android, iOS, and JavaScript. We’re also collecting together all the tutorials for the Maps JavaScript API in one place.

We’ve made a good start, but there’s plenty of change still to come. What would you like to see more of? Are we on the right track? The tech writing team would love your ideas—please add comments to this post.

Posted by Sarah Maddox, Technical Writer, Google Maps APIs

Styling and custom data for polylines and polygons in the Google Maps Android API

noreply@blogger.com (MapsDevrel) — Thu, 16 Feb 2017 00:04:00 +0000

Polygons, polylines and ground overlays are useful tools to make your maps work for your users. Today we are rolling out even more custom styling and data object association features in the Google Maps Android API to further help you customize your maps.

Style your shapes: polygons and polylines

We brought custom map styling to mobile platforms last year to help you match your map styles to your brands, apps, and more. We've seen hot pink, cool silver (shown in screenshots below), and everything in between, helping users feel at home and see what's relevant in your maps. Now we're expanding styling options for polygons and polylines, allowing you to use new stroke patterns for outlines, different caps and joints, and more, on Android devices.

Your shape, your style. Now on Android

Now you have plenty of options to customize your shapes. You can change the stroke patterns in polylines and polygon outlines from solid lines to custom dashes, dots, or gaps. In polylines and polygons, you can use a bevel or round joint type rather than fixed miter joints. You can also change the cap at each end of a polyline to a square or round cap, or even specify a custom bitmap for the cap. Have a favorite fancy arrowhead you've always wanted to put in? Do it–let your imagination run wild!

Get your styles in line. Now on Android.

Learn how to set and customize these new styles in our new polyline and polygon tutorial or dive straight into the documentation to get started—check out the stroke patterns, for example. Note that these new styling features are available in the full Google Maps Android API only, not in lite mode.

Store custom data with polygons, polylines, and ground overlays

Until today, you could only store data objects with markers. We're extending this functionality to polygons, polylines, circles, and ground overlays. This means you can extend your geometry objects to have any kind of data or properties you want. You no longer need to manage your data associations to your mapping visualizations–nobody enjoys writing that code anyway. For example, if you supply a set of ground overlays showing home floor plans you could store a database reference with each one. The database can contain anything! It could hold real estate listings, and you could open one of those listing URLs on click.

For further information, review our release notes.

Thank you for using the Google Maps Android API! Be sure to share your feedback or any issues in the issue tracker.

Posted by Joel Kalmanowicz, Product Manager, Google Maps APIs

Open-Sourcing Google Earth Enterprise

noreply@blogger.com (MapsDevrel) — Mon, 30 Jan 2017 16:08:00 +0000

Editors Note: Google Earth Enterprise (GEE) launched on GitHub on March 23, 2017. You can also get more information on the GEE project site created by our partners.

Posted by Avnish Bhatnagar, Senior Technical Solutions Engineer, Google Cloud

We are excited to announce that we are open-sourcing Google Earth Enterprise (GEE), the enterprise product that allows developers to build and host their own private maps and 3D globes. With this release, GEE Fusion, GEE Server, and GEE Portable Server source code (all 470,000+ lines!) will be published on GitHub under the Apache2 license in March.

Originally launched in 2006, Google Earth Enterprise provides customers the ability to build and host private, on-premise versions of Google Earth and Google Maps. In March 2015, we announced the deprecation of the product and the end of all sales. To provide ample time for customers to transition, we have provided a two year maintenance period ending on March 22, 2017. During this maintenance period, product updates have been regularly shipped and technical support has been available to licensed customers.

Feedback is important to us and we’ve heard from our customers that GEE remains in-use in mission-critical applications. Many customers have not transitioned to other technologies. Open-sourcing GEE allows our customer community to continue to improve and evolve the project in perpetuity. Note that the implementations for Google Earth Enterprise Client, Google Maps JavaScript® API V3 and Google Earth API will not be open sourced. The Enterprise Client will continue to be made available and updated. However, since GEE Fusion and GEE Server are being open-sourced, the imagery and terrain quadtree implementations used in these products will allow third-party developers to build viewers that can consume GEE Server Databases.

We’re thankful for the help of our GEE partners in preparing the codebase to be migrated to GitHub. It’s a lot of work and we cannot do it without them. It is our hope that their passion for GEE and GEE customers will serve to lead the project into its next chapter.

Looking forward, GEE customers can use Google Cloud Platform (GCP) instead of legacy on-premises enterprise servers to run their GEE instances. For many customers, GCP provides a scalable and affordable infrastructure as a service where they can securely run GEE. Other GEE customers will be able to continue to operate the software in disconnected environments. However, we believe that the advantages of incorporating even some of the workloads on GCP will become apparent (such as processing large imagery or terrain assets on GCP that can be downloaded and brought to internal networks, or standing up user-facing Portable Globe Factories).

Moreover, GCP is increasingly used as a source for geospatial data. Google’s Earth Engine has made available over a petabyte of raster datasets which are readily accessible and available to the public on Google Cloud Storage. Additionally, Google uses Cloud Storage to provide data to customers who purchase Google Imagery today. Having access to massive amounts of geospatial data, on the same platform as your flexible compute and storage, makes generating high quality Google Earth Enterprise Databases and Portables easier and faster than ever.

We will be sharing a series of white papers and other technical resources to make it as frictionless as possible to get open source GEE up and running on Google Cloud Platform. We are excited about the possibilities that open-sourcing enables, and we trust this is good news for our community. We will be sharing more information when we launch the code in March on GitHub. For general product information, visit the Google Earth Enterprise Help Center. Review the essential and advanced training for how to use Google Earth Enterprise, or learn more about the benefits of Google Cloud Platform.

Introducing insights in the Google My Business API

noreply@blogger.com (MapsDevrel) — Tue, 10 Jan 2017 22:38:00 +0000

Posted by Aditya Tendulkar, Product Manager, Google My Business

Today we are introducing business location insights in the Google My Business API to make it easier for third-party application developers and large multi-location brands to programmatically access location insights such as total number of searches, views and actions that let business owners track and analyze where and how people are finding them on Google.

Developers can now use the Google My Business API to request up to 18 months worth of data for each of their business locations and build applications that aggregate and visualize these insights in actionable ways. For example, a coffee shop with hundreds of locations can now easily compare and understand trends across their different locations such as number of user views, click requests for directions, phone calls, and more. They can use these insights to better allocate resources across locations and track how marketing activities affect their business.

This new API functionality brings the features from our Google My Business dashboard into your own data analysis tools. Web interface users might generate a chart of the last 90 days of Google My Business information:

Example data visible via the Google My Business web dashboard

Now the underlying data is available via the API. It's easy to get started with our new developer documentation. Here's a simple HTML request that provides a breakdown of how many searches a business listing is getting on Google Search and Google Maps:

REQUEST:

POST https://mybusiness.googleapis.com/v3/123456/locations:reportInsights
{
  "locationNames": [
    “accounts/110714876951578713336/locations/14372810722634034850”,
  ],
  “basicRequest” : {
          "metricRequests": [
             {
               "metric": QUERIES_DIRECT,
             },
             {
               "metric": QUERIES_INDIRECT,
             }
          ],
          "timeRange": {
               "startTime": 2016-10-12T01:01:23.045123456Z,
               "endTime": 2017-01-10T23:59:59.045123456Z,
          },
    },
}

RESPONSE:

{
  "locationMetrics": [
    {
      "locationName": "accounts/110714876951578713336/locations/
                       14372810722634034850",
      "timeZone": "America/Los_Angeles",
      "metricValues": [
        {
          "metric": "QUERIES_DIRECT",
          "totalValue": {
            "metricOption": "AGGREGATED_TOTAL",
            "timeDimension": {
              "timeRange": {
                "startTime": "2016-10-12T04:00:00Z",
                "endTime": "2017-01-10T04:00:00Z"
              }
            },
            "value": "36738"
          }
        },
        {
          "metric": "QUERIES_INDIRECT",
          "totalValue": {
            "metricOption": "AGGREGATED_TOTAL",
            "timeDimension": {
              "timeRange": {
                "startTime": "2016-10-12T04:00:00Z",
                "endTime": "2017-01-10T04:00:00Z"
              }
            },
            "value": "81770"
          }
        }
      ]
    }
  ]
}

Here is an example that captures insights on the places from where customers request driving directions to a business:

REQUEST:

POST https://mybusiness.googleapis.com/v3/123456/locations:reportInsights
{
     “locationNames": [
             “accounts/110714876951578713336/locations/14372810722634034850”,
       ],
      "drivingDirectionsRequest”: {
            "numDays": NINETY,
      },
}

RESPONSE (truncated to show first 3 results):

{
  "locationDrivingDirectionMetrics": [
    {
      "locationName": "accounts/110714876951578713336/locations/
                       14372810722634034850",
      "topDirectionSources": [
        {
          "dayCount": 90,
          "regionCounts": [
            {
              "latlng": {
                "latitude": 37.789,
                "longitude": -121.392
              },
              "label": "94105",
              "count": "2980",
            },
            {
              "latlng": {
                "latitude": 37.779,
                "longitude": -122.421
              },
              "label": "94102",
              "count": "887",
            },
            {
              "latlng": {
                "latitude": 37.773,
                "longitude": -122.410
              },
              "label": "94103",
              "count": "886",
            }
          ]
        }
      ],
          "timeZone": "America/Los_Angeles"
    }
  ]
}

Example data visible via the Google My Business web dashboard

With this new feature, Google My Business API users can optimize their listings to drive customer actions through understanding key insights about how customers are searching for their business on Google, and what actions they are taking once they find it. These insights are also available on Google My Business web and mobile, allowing users to keep track of key trends from anywhere.

To learn more about the Google My Business API and to apply for access, visit our developer page. Questions or feedback? Contact the API team on the Google My Business API Forum.

Geolocation and Firebase for the Internet of Things

noreply@blogger.com (MapsDevrel) — Wed, 21 Dec 2016 17:48:00 +0000

Posted by Ken Nevarez, Industry Solutions Lead at Google

GPS is the workhorse of location based services, but there are use cases where you may want to avoid the cost and power consumption of GPS hardware or locate devices in places where GPS lacks accuracy, such as in urban environments or buildings.

We've seen recent growth in Internet of Things (IoT) applications using the Google Maps Geolocation API instead of GPS for asset tracking, theft prevention, usage optimization, asset servicing, and more. As part of my 20 percent project at Industry Solutions, I created a prototype IoT device that can locate itself using surrounding WiFi networks and the Google Maps Geolocation API. In this post, I’ll discuss some interesting implementation features and outline how you can create the prototype yourself.

I built a device that scans for local WiFi and writes results (WiFi hotspots and their signal strength) to a Firebase Realtime Database. A back-end service then reads this data and uses the Google Maps Geolocation API to turn this into a real-world location, which can be plotted on a map.

Set up the Device & Write Locally

For this proof of concept, I used the Intel Edison as a Linux-based computing platform and augmented it with Sparkfun’s Edison Blocks. To build the device, you will need an Intel Edison, a Base Block, a Battery Block and a Hardware pack.

Developing for the Edison is straightforward using the Intel XDK IDE. We will be creating a simple Node.js application in JavaScript. I relied on 3 libraries: Firebase for the database connection, wireless-tools/iwlist to capture WiFi networks, and macaddress to capture the device MAC. Installation instructions can be found on the linked pages.

Step 1: get the device MAC address and connect to Firebase:

function initialize() {
    macaddress.one('wlan0', function (err, mac) {
        mac_address = mac;
        if (mac === null) {
            console.log('exiting due to null mac Address');
            process.exit(1);
        }
        firebase.initializeApp({
            serviceAccount: '/node_app_slot/<service-account-key>.json',
            databaseURL: 'https://<project-id>.firebaseio.com/'
        });
        var db = firebase.database();
        ref_samples = db.ref('/samples');
        locationSample();
    });
}

The above code contains two placeholders:

The service-account-key is a private key you create in the Firebase Console. Follow the gear icon in the upper left of console, select “settings”, and click Generate New Private Key. Place this key on your Edison in the directory /node_app_slot/. See this Firebase documentation for more information.
The project-id in the database URL is found in the Firebase console database page after you have linked your Google project with Firebase.

Step 2: scan for WiFi networks every 10 seconds and write locally:

function locationSample() {
    var t = new Date();
    iwlist.scan('wlan0', function(err, networks) {
        if(err === null) {
            ref_samples.push({
                mac: mac_address,
                t_usec: t.getTime(),
                t_locale_string: t.toLocaleString(),
                networks: networks,
            });
        } else {
            console.log(err);
        }        
    });
    setTimeout(locationSample, 10000);
}

Write to the cloud

The locationSample() function above writes detectable WiFi networks to a Firebase database that syncs to the cloud when connected to a network.

Caveat: To configure access rights and authentication to Firebase, I set up the device as a “server”. Instructions for this configuration are on the Firebase website. For this proof of concept, I made the assumption that the device was secure enough to house our credentials. If this is not the case for your implementation you should instead follow the instructions for setting up the client JavaScript SDK.

The database uses 3 queues to manage workload: a WiFi samples queue, a geolocation results queue and a visualization data queue. The workflow will be: samples from the device go into a samples queue, which gets consumed to produce geolocations that are put into a geolocations queue. Geolocations are consumed and formatted for presentation, organized by device, and the output is stored in a visualizations bucket for use by our front end website.

Below is an example of a sample, a geolocation, and our visualization data written by the device and seen in the Firebase Database Console.

Processing the Data with Google App Engine

To execute the processing of the sample data I used a long running Google App Engine Backend Module and a custom version of the Java Client for Google Maps Services.

Caveat: To use Firebase with App Engine, you must use manual scaling. Firebase uses background threads to listen for changes and App Engine only allows long-lived background threads on manually scaled backend instances.

The Java Client for Google Maps Services takes care of a lot of the communications code required to use the Maps APIs and follows our published best practices for error handling and retry strategies that respect rate limits. The GeolocateWifiSample() function below is registered as an event listener with Firebase. It loops over each network reported by the device and incorporates it into the geolocation request.

private void GeolocateWifiSample(DataSnapshot sample,  Firebase db_geolocations, Firebase db_errors) {
    // initalize the context and request
    GeoApiContext context = new GeoApiContext(new GaeRequestHandler()).setApiKey("");
    GeolocationApiRequest request = GeolocationApi.newRequest(context)
            .ConsiderIp(false);
    // for every network that was reported in this sample...
    for (DataSnapshot wap : sample.child("networks").getChildren()) {
        // extract the network data from the database so it’s easier to work with
        String wapMac = wap.child("address").getValue(String.class);
        int wapSignalToNoise = wap.child("quality").getValue(int.class);
        int wapStrength = wap.child("signal").getValue(int.class);
        // include this network in our request
        request.AddWifiAccessPoint(new WifiAccessPoint.WifiAccessPointBuilder()
                .MacAddress(wapMac)
                .SignalStrength(wapStrength)
                .SignalToNoiseRatio(wapSignalToNoise)
                .createWifiAccessPoint());
    }
    ...
    try {
        // call the api
        GeolocationResult result = request.CreatePayload().await();
        ...
        // write results to the database and remove the original sample
    } catch (final NotFoundException e) {
        ...
    } catch (final Throwable e) {
        ...
    }
}

Register the GeolocateWifiSample() function as an event handler. The other listeners that process geolocation results and create the visualization data are built in a similar pattern.

ChildEventListener samplesListener = new ChildEventListener() {
    @Override
    public void onChildAdded(DataSnapshot dataSnapshot, String previousChildName) {
        // geolocate and write to new location
        GeolocateWifiSample(dataSnapshot, db_geolocations, db_errors);
    }
    ...
};
db_samples.addChildEventListener(samplesListener);

Visualize the Data

To visualize the device locations I used Google App Engine to serve stored data from Firebase and the Google Maps JavaScript API to create a simple web page that displays the results. The index.html page contains an empty <div> with id “map”. I initialized this <div> to contain the Google Map object. I also added “child_added” and “child_removed” event handlers to update the map as the data changes over time.

function initMap() {
    // attach listeners
    firebase.database().ref('/visualization').on('child_added', function(data) {
        ...
        data.ref.on('child_added', function(vizData) {
            circles[vizData.key]= new CircleRoyale(map,
                                vizData.val().lat,
                                vizData.val().lng,
                                vizData.val().accuracy,
                                color);
          set_latest_position(data.key, vizData.val().lat, vizData.val().lng);
        });
        data.ref.on('child_removed', function(data) {
            circles[data.key].removeFromMap();
        });
    });
    // create the map
    map = new google.maps.Map(document.getElementById('map'), {
      center: get_next_device(),
      zoom: 20,
      scaleControl: true,
    });
    ...
}

Since the API returns not only a location but also an indication of accuracy, I’ve created a custom marker that has a pulsing radius to indicate the accuracy component.

Two devices (red and blue) and their last five known positions

What’s next?

In this post I’ve outlined how you can build an IoT device that uses Google Maps Geolocation API to track any internet-connected device - from robotics to wearables. The App Engine processing module can be expanded to use other Google Maps APIs Web Services providing geographic data such as directions, elevation, place or time zone information. Happy building!

As an alternative, you can achieve a similar solution using Google Cloud Platform as a replacement for Firebase—this article shows you how.

About Ken: Ken is a Lead on the Industry Solutions team. He works with customers to bring innovative solutions to market.

Address Geocoding in the Google Maps APIs

noreply@blogger.com (MapsDevrel) — Tue, 22 Nov 2016 23:43:00 +0000

Forward Geocoding is the process of converting addresses (like a street address) into geographic coordinates (latitude and longitude), which you can use to place markers on a map or position the map. The Google Maps APIs have several services that you can use to convert addresses into coordinates - the Geocoding API, the Place Autocomplete service in Places API, and the Place Search service in Places API. What are the differences between them and when should you use each one? Here’s where to start.

Note that while this blog focuses on the server-side Places and Geocoding APIs, these best practices also apply to the client-side Places and Geocoding services in the Google Maps JavaScript API.

Geocoding API

The Geocoding API is best for handling unambiguous queries: complete postal address strings (for example, “48 Pirrama Rd, Pyrmont, NSW, Australia”). Compared to other Google APIs, the Geocoding API provides the best quality matching of addresses globally for these types of complete, unambiguous queries. However, Geocoding API is not recommended if your application handles ambiguous or incomplete queries, such as “123 Main St”, or if it handles queries that may contain non-address information such as apartment numbers or business names.

Geocoding API is best used for unambiguous complete addresses, such as "48 Pirrama Rd, Pyrmont, NSW, Australia"

Places API

The Places API allows users to discover both addresses and semantic locations, such as cafes or parks, by name or type. In contrast to the Geocoding API, it handles ambiguous or incomplete requests in a more robust way. If your application handles user interaction, or addresses that are ambiguous or incomplete, consider the following services.

Place Autocomplete service

For applications that respond in real time to user input, we recommend using the Place Autocomplete service in the Places API. This service is designed to return multiple possible addresses and allow the user to choose between them. The autocomplete lookup function can also be biased to return results specific to a location, enabling high quality results to be returned for incomplete queries such as “123 Main St”. Since the Place Autocomplete service is optimized for responding to user input, it also has very low latency, usually at least 10x lower than the Geocoding API. It’s also good at handling misspelled queries, or queries containing non-address information, since as the user types, they can see suggestions and correct their spelling if needed.

Typing "123 Main St" into a Place Autocomplete search box lets the user choose from multiple results. Results can also be biased to prefer those near the area shown on the map or near the current user location

Place Search service

The Place Autocomplete service relies on a user to choose the best option from multiple results. What if you have an application that handles ambiguous or incomplete queries in an automated fashion, with no user able to provide input?

For geocoding ambiguous or incomplete addresses in automated systems, when there is no user to select one of the autocomplete suggestions, we recommend the Place Search service in Places API. Place Search is better at coping with ambiguous queries than the Geocoding API, and lets you restrict your search to a specified area, or rank results by distance, allowing more precise filtering and ranking of results for ambiguous or incomplete queries. Place search is also more robust at responding to queries with additional non-address information such as business names or apartment numbers.

Future Changes to Geocoding API

We plan to roll out an update to the Geocoding API at the end of November 2016 that will increase the difference between Geocoding and Places performance for ambiguous and unambiguous queries. This change will improve the quality of Geocoding results for unambiguous queries, but will be more likely to return ZERO_RESULTS for ambiguous or incomplete queries where the Geocoding API was unable to find a high quality result.

If you are already using the above best practices, you should see an improvement in your Geocoding API results. If you are currently using the Geocoding API for incomplete or ambiguous queries, or for queries that may contain non-address information such as business names or apartment numbers, we recommend that you switch to the Places API instead, as it is likely to give better quality results for your use case.

You can try the new Geocoding service ahead of launch by adding an optional parameter, new_forward_geocoder=true, to your Geocoding API request. For example:

https://maps.googleapis.com/maps/api/geocode/json?new_forward_geocoder=true&address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=YOUR_API_KEY

If you want to try the new Geocoding service in the JavaScript Maps API Geocoding Service, you can set the new optional parameter newForwardGeocoder: true in the GeocoderRequest object. The new Geocoding service will launch for both the Geocoding API and the Geocoding Service in the JavaScript Maps API at the same time. All of the recommendations in this blog post apply to both the server-side and client-side APIs.

If you have any bug reports or feature requests for the new Geocoding service, please let us know using our public issue tracker.

In Summary

The following table sums up when we recommend you use the Geocoding API, Place Autocomplete service and Place Search service.

	Geocoding API	Place Search	Place Autocomplete
Scope	Addresses only	Semantic locations and addresses, including businesses and points of interest
Strengths	Unambiguous complete addresses	Ambiguous or incomplete addresses in automated systems	Responding to real-time user input

If your application does not yet follow these best practices, you may get worse results from Geocoding API in future, so we recommend you test how your application works with the new Geocoding service and update your application to use the above best practices if required. Try the upcoming Geocoding service by setting new_forward_geocoder=true in your geocoding request.

For more information on the Google Maps Geocoding API, Place Autocomplete in the Places API and Place Search in the Places API, please see the developer documentation. Also see this more detailed best practices guide in our documentation for more details on Geocoding best practices for various use cases, including minimizing latency when querying Directions API with addresses.

Finally, a big thank you to all the developers who use the Google Maps Geocoding API and provide feedback via the issue tracker. Getting feedback from developers is vital for us to be able to keep improving our products, so if you have any bug reports or feature requests, please let us know!

Posted by Elena Kelareva, Product Manager, Google Maps APIs

Smart scrolling comes to mobile web maps

noreply@blogger.com (MapsDevrel) — Wed, 16 Nov 2016 00:23:00 +0000

If you’re building a website today, your users are more likely to view it on a mobile device than on a desktop or laptop. Google has plenty of resources to help developers make their websites stand out on mobile, from a guide to building mobile-friendly websites, to a mobile-friendly testing tool, to promoting new mobile web technologies such as Accelerated Mobile Pages and Progressive Web Apps.

Mobile web users often get frustrated when trying to scroll the page, but an embedded map captures their swipe and pans the map instead. This can even lead to users getting stuck on the map and having to reload the page in order to get back to the rest of the page.

Today we're introducing intuitive scrolling for sites with embedded maps and making the full-screen control visible by default on mobile devices. This should give your users a more intuitive and less frustrating map interaction experience on mobile browsers.

The map trap

We have added a new gestureHandling option to the Google Maps JavaScript API. This setting controls how touch gestures* on the map are handled.

Values:

"cooperative": Two-finger touch gestures pan and zoom the map, as do all mouse gestures. One-finger touch gestures are ignored by the map. In this mode, the map cooperates with the page, so that one-finger touch gestures can pan the page.
"greedy": All touch gestures pan or zoom the map. This was the previous behaviour.
"none": The map cannot be panned or zoomed by user gestures.
"auto": Gesture handling is automatically set to either cooperative or greedy, depending on whether the page is scrollable or not (defined by a comparison of the page body dimensions and the window dimensions).
If the page is scrollable, “auto” sets the gesture handling mode to cooperative.
If the page is not scrollable, “auto” sets the gesture handling to greedy.
If the map is in an iFrame, “auto” sets the gesture handling to cooperative because the API can’t determine whether the page is scrollable.

*Note that there is currently no way to change the gesture handling mode for Street View; these options only affect the way gestures are handled by the map. If you’d like to see this extended to Street View in future, please let us know on our public issue tracker.

You can enable any of these four gesture handling modes by adding the corresponding field to the MapOptions object. For example:

map = new google.maps.Map(document.getElementById('map-div'), {
gestureHandling: 'cooperative',
center: {lat: -34.397, lng: 150.644},
zoom: 8
});

If the gestureHandling option is not set, the default value is auto, since that automatically chooses what we expect to be the best behavior based on what the browser can detect about the placement of your map in the page. If you prefer to always use the old map gesture handling mode for users viewing your site on mobile devices, change the value of gestureHandling to greedy, which sends all user gestures to the map.

Maps viewed within a scrollable website on a mobile device will display this overlay on touch

The option draggable: false has now been superseded by gestureHandling: 'none'. The old option draggable is now deprecated, but we’ll maintain backwards compatibility. Developers who previously turned off map interaction by setting draggable to false will keep their existing non-interactive maps.

Maximizing the map when you need it

Many users in our user studies said they found small embedded maps on mobile devices hard to interact with and they preferred to interact with a larger map. To address this request, we've made the fullscreen control visible by default on mobile devices. The fullscreen control allows the user to make the map larger. When the map is in fullscreen mode, the user can pan the map using one finger. As a developer, you can enable or disable fullscreen control, by setting the fullscreenControl option to true or false in the MapOptions object. When the map is in fullscreen mode, one finger will always pan the map, since there is no surrounding page to pan.

The default setting of fullscreenControl is true on mobile browsers, and false on desktop browsers, since the problem of maps being too small for interaction usually only occurs on mobile devices.

The fullscreen control allows the user to make the map larger for easier interaction

View this demo on a mobile device to see how the fullscreen button and cooperative gesture handling mode (or auto gesture handling mode on a scrollable site) will look to your users.

For more information on the Google Maps JavaScript API, please see the developer documentation or review the latest release notes.

A big thank you to all the developers who use the Google Maps JavaScript API and provide feedback via the issue tracker. Getting feedback from developers is vital for us to be able to keep improving our products, so if you have any bug reports or feature requests, please let us know.

Posted by Elena Kelareva, Product Manager, Google Maps APIs

Key Improvements for Your Maps API Experience

noreply@blogger.com (MapsDevrel) — Tue, 04 Oct 2016 20:31:00 +0000

Originally posted on the Google Developers blog.
Posted by Israel Shalom, Product Manager

Here at Google, we’re serving more than a hundred APIs to ensure that developers have the resources to build amazing experiences with them. We provide a reliable infrastructure and make it as simple as possible so developers can focus on building the future. With this in mind, we’re introducing a few improvements for the API experience: more flexible keys, a streamlined 'getting-started' experience, and easy monitoring.

Faster, more flexible key generation

Keys are a standard way for APIs to identify callers, and one of the very first steps in interacting with a Google API. Tens of thousands of keys are created every day for Google APIs, so we’re making this step simpler -- reducing the old multi-step process with a single click:

You no longer need to choose your platform and various other restrictions at the time of creation, but we still encourage scope management as a best practice:

Streamlined getting started flow

We realize that many developers want to get straight to creation and don’t necessarily want to step into the console. We’ve just introduced an in-flow credential set up procedure directly embedded within the developer documentation:

Click the 'Get a Key' button, choose or create a project, and then let us take care of enabling the API and creating a key.

We are currently rolling this out for the Google Maps APIs and over the next few months we'll bring it to the rest of our documentation.

API Dashboard

We’re not just making it easier to get started, we’re simplifying the on-going usage experience, too. For developers who use one or more APIs frequently, we've built the new API Dashboard to easily view usage and quotas.

If you’ve enabled any APIs, the dashboard is front and center in the API Console. There you can view all the APIs you’re using along with usage, error and latency data:

Clicking on an API will jump to a detailed report, where you’ll see the traffic sliced by methods, credentials, versions and response code (available on select APIs):

We hope these new features make your API usage easier, and we can't wait to see what you’re going to build next!

A sizzling open source release for the Australian Election site

noreply@blogger.com (MapsDevrel) — Tue, 27 Sep 2016 16:58:00 +0000

One of the best parts of my job at Google is 20 percent time. While I was hired to help developers use Google’s APIs, I value the time I'm afforded to be a student myself—to learn new technologies and solve real-world problems. A few weeks prior to the recent Australian election an opportunity presented itself. A small team in Sydney set their sights on helping the 15 million voters stay informed of how to participate, track real-time results, and (of course) find the closest election sausage sizzle!

Our team of designers, engineers and product managers didn't have an immediate sense of how to attack the problem. What we did have was the power of Google’s APIs, programming languages, and Cloud hosting with Firebase and Google Cloud Platform.

The result is a mish-mash of some technologies we'd been wanting to learn more about. We're open sourcing the ausvotes.withgoogle.com repository to give developers a sense of what happens when you get a handful of engineers in a room with a clear goal and a immovable deadline.

The Election AU 2016 repository uses:

Go from Google App Engine instances to serve the appropriate level of detail for users' viewport queries from memory at very low latency, and
Dart to render the live result maps on top of Google Maps JavaScript API using Firebase real time database updates.

A product is only as good as the attention and usage is receives. Our team was really happy with the results of our work:

406,000 people used our maps, including 217,000 on election day.
We had 139 stories in the media.
Our map was also embedded in major news websites, such as Sky News.

Complete setup and installation instructions are available in the Github README.

Posted by Brett Morgan, Developer Programs Engineer

Custom map styling with the Google Maps APIs on Android and iOS

noreply@blogger.com (MapsDevrel) — Wed, 21 Sep 2016 21:49:00 +0000

Your app, your map style. For iOS and Android.

Cross-platform custom map styling is here—change the color palette of your maps, hide labels, vary road density and toggle points of interest. Your maps can now match your brand and style across your website and your apps!

The Google Maps APIs now support you in creating beautiful styled maps for your Android and iOS apps as well as your website using the same JSON style object.

Easily create your style

The new Google Maps APIs Styling Wizard helps you to create a map style in a few clicks. Use one of our pre-built styles or create your own style from scratch.

Access advanced options for further control over every available aspect of your map style including visibility, fills & stroke weight.

Use the styling wizard for point and click custom style creation.

Show what’s important, hide the rest

Custom map styling provides you with ways to tailor your map for a particular use case. Got your own transit stops and want to turn the Google ones off? We’ve got you covered. Want to hide highways and highlight water features? Done. You can control the visibility of labels, landscapes, transit icons, points of interest, roads and more to create the look that reflects your brand and purpose. See the samples for Android, iOS and JavaScript.

Both the iOS and the Android SDKs now support business points of interest as well; this means you’ll now see hotels, restaurants and shops on your maps. They’ll only be visible when you compile with the latest SDKs and you can control their visibility via styling.

Style once, use on any platform

When you’re happy with your new map style, you can export & use the same JSON styling object in our iOS, Android and JavaScript Maps APIs. The Styling Wizard also provides the URL for you to use with the Google Static Maps API.

To enable a custom style in your app or website, take a look at the code samples: Android, iOS & JavaScript.

You can distribute the styles with your app, fetch them dynamically, and even change them at runtime.

Custom styles now work on native iOS and Android apps as well as the web.

The Android and iOS release notes contain details of bugs fixed as well as the custom basemap styling features mentioned in this post. Read the Maps APIs styling guides for Android, iOS and JavaScript, and watch the Styling your Maps Geocast (embedded below).

A big thank you to Android and iOS developers everywhere for using the Google Maps Android API and the Google Maps SDK for iOS and submitting feedback via the issue tracker. We heard you!

Share your styled basemaps on Twitter and G+ via #mapstyle and show us what you’ve done!

Posted by Megan Boundey, Product Manager, Google Maps Mobile APIs

Making the most of the Google Maps Web Service APIs

noreply@blogger.com (MapsDevrel) — Thu, 15 Sep 2016 16:31:00 +0000

When it comes to app development, there can be a disconnect between the robust app we intended to build and the code we actually get into a minimum viable product. These shortcuts end up causing error conditions once under load in production.

The Google Maps API team maintains client libraries that give you the power to develop with the confidence that your app will scale smoothly. We provide client libraries for Python, Java, and Go, which are used by thousands of developers around the world. We're excited to announce the recent addition of Node.js to the client library family.

When building mobile applications, it is a best practice to use native APIS like Places API for Android and Places API for iOS where you can, but when you find that your use case requires data that is only available via the Google Maps APIs Web Services, such as Elevation, then using these client libraries is the best way forward.

These libraries help you implement API request best practices such as:

Requests are sent at the default rate limit for each web service, but of course this is configurable.
The client libraries will automatically retry any request if the API sends a 5xx error. Retries use exponential back-off, which helps in the event of intermittent failures.
The client libraries make it easy to authenticate with your freely available API Key. Google Maps APIs Premium Plan customers can alternatively use their client ID and secret.
The Java and Go libraries return native objects for each of the API responses. The Python and Node.js libraries return the structure as it is received from the API.

The client libraries can help you in a variety of ways. One of them is exposing the result sets in a format that makes most sense for the language in question. For example, the Java and Go client libraries include object hierarchies that are type-safe representations of the potential results for each API. This allows you to write code in the comfort of your editor with the knowledge that the compiler will catch any mistakes.

With 3 million apps and websites using Google Maps APIs, we have an important tip for ensuring reliability when using web services: call APIs from a server rather than directly from Android or iOS. This secures your API key so that your quota can't be consumed by a bad actor, along with being able to add caching to handle common requests quickly.

A server instance acts as a proxy that takes requests from your Android and iOS apps and then forwards them to the Google Maps Web Service APIs on your app’s behalf. The easiest way to create a server side proxy is using the Google Maps Web Service client libraries from Google App Engine instances. For more detail, please watch Laurence Moroney’s Google I/O 2016 session “Building geo services that scale”.

You can learn more about the Google Maps API web services in our documentation. The easiest way to use these APIs and follow best practices is to use the Client Libraries for Google Maps Web Services. Download the client libraries for Java, Python, Go or Node.js from Github to start using them today!

Posted by Brett Morgan, Developer Programs Engineer

New JavaScript Street View renderer brings rendering improvements and better mobile support

noreply@blogger.com (MapsDevrel) — Thu, 18 Aug 2016 00:05:00 +0000

Street View is one of Google Maps’ most loved features, providing users with a way to explore and experience the world around them. Developers all over the world use Street View in the Google Maps JavaScript API to make their apps more unique and exciting, giving their users a sense of what it’s like to visit a place in real life.

Today we’re making Street View even better, especially on mobile devices, by launching a new Street View renderer in the Google Maps JavaScript API. Read on for the full details of what we’ve improved!

Better display

Smoother Transitions

Transitions from one point to another in Street View now include more animation frames, creating the effect of gliding smoothly to the next location. Transitions in the old renderer looked like jumping from one location to another.

Old renderer	New renderer

Smoother Loading Animations

The old renderer repeats images while loading new content, resulting in a stuttering effect. The new renderer uses lower resolution imagery while loading, resulting in a smoother animation when rotating an image in Street View.

Old renderer	New renderer

Object modeling improvements

Objects in Street View look better in the new renderer because it builds a 360-degree model that considers all possible perspectives. For example, this high rise building has wavy lines in the old renderer, as opposed to crisp lines in the new renderer.

Old renderer	New renderer

In another example: for imagery on an incline, such as a street with a steep hill, the new renderer corrects the objects to be vertical, whereas the old renderer would have shown the objects at an angle.

Old renderer	New renderer

Better mobile support

WebGL imagery

The new renderer uses WebGL (on browsers that support it) which results in a higher frame rate and better rendering, especially on mobile devices. On mobile devices, the old renderer would display a fish-eye projection of the image, whereas WebGL allows us to present a rendered sphere that looks as it would in reality. For example, the street in the image below is straight, but the old renderer made it look curved on mobile devices.

Old renderer	New renderer

Touch support

As mobile web usage grows, users expect familiar touch-based interactions to work everywhere. The new renderer supports the same natural touch-based gestures on mobile which have been available in the Google Maps Android app: pinch-to-zoom and double-tap-to-go. In the old renderer, zooming was only available through the +/- buttons, and movement was only possible by clicking the arrows on the ground.

Motion tracking on mobile devices

Mobile devices give developers the opportunity to provide their users with more natural ways to explore and interact with their applications. We’ve enabled support for device orientation events on Street View so that users on mobile devices can look around in Street View by moving their phone. Developers have the option to turn this off if they prefer. Please see the developer documentation for more details, or open the documentation link on a mobile device to see motion tracking in action.

Better controls

X Forward

When using a desktop device with a mouse or trackpad, users will see a small "X" at the cursor location that indicates the next camera location if they choose to move forward. Arrows indicate the direction of movement. Wall rectangles identify the direction the camera will point towards.

Next image targets	Next centered image target

Cleaner street names, labels and targets

Street names and labels are now separated from controls, removing overlap issues and allowing for clean display in right-to-left and left-to-right languages.

Old renderer	New renderer

We hope you enjoy using the new and improved Street View renderer! Also a big thank you to all the developers who use the Google Maps JavaScript API and provide feedback via the issue tracker. Getting feedback from developers is vital for us to be able to keep improving our products, so if you have any bug reports or feature requests, please let us know!

For more information on Street View in the Google Maps JavaScript API, please see the developer documentation.

Posted by Elena Kelareva, Product Manager, Google Maps APIs

Keep users focused on what's important with the latest Google Maps Android API

noreply@blogger.com (MapsDevrel) — Mon, 01 Aug 2016 23:44:00 +0000

Released today, the latest version of the Google Maps Android API includes more developer requested features: you can now track camera movements more accurately via our new camera listeners, set the minimum & maximum zoom levels on your map, and restrict the user’s panning to particular lat/lng bounds of the camera target. In addition, we’ve added a new marker Tag property so you can now associate your own data object with a marker.

Track camera movements more accurately

As one of our top requests, developers have been asking for a better way to track camera movements and the ability to see why the camera is moving, whether caused by user gestures, built-in API animations or developer controlled movements [Issue 4636]. Our new camera change listeners support you in doing this. Your app can now receive notifications for camera start, ongoing, and end events.

See the developer’s guide to camera change events and take a look at this code sample which shows you how to detect when the user drags the map, and draws a line to track this movement when it happens.

Control the zooming, panning and scrolling experience

Have you ever wanted to be able to control how much your user can zoom in and out and pan around on your map so that you can more tightly control the experience? Or have you got tile overlays only for zoom levels 15 through 20 and wish you could limit the zooming capability of both the map and your tile overlays to those particular levels?

You can now set the min and max zoom levels on your map by using GoogleMap.setMinZoomPreference() and GoogleMap.setMaxZoomPreference() [Issue 4663]. These zoom levels will also apply to any tile overlays you have on your map.

In addition, you can also constrain the lat/lng center bounds of the focal point of the map (the camera target) so that users can only scroll and pan within these bounds using GoogleMap.setLatLngBoundsForCameraTarget(). This is awesome if you want your users to stay within the map area of your tile overlays, or you wish to confine the map in your app to a particular local area.

Pan and zoom limits on a map for Adelaide, a beautiful city in South Australia

See the developer’s guide to learn more about setting boundaries on the map as well as this code sample.

Marker tags

Does your app cater for different types of markers and you want to treat them differently when a user taps on them? Or do you want to assign priorities to your markers? The new marker Tag property allows you to associate whatever data object you like with a marker, supporting you in doing this and more [Issue 4650].

A big thank you to Android developers everywhere for using the Google Maps Android API and submitting feedback via the issue tracker.

Our release notes contain details of bugs fixed as well as the features mentioned in this post. Take a look and start using our new features today!

Posted by Megan Boundey, Product Manager, Google Maps Mobile APIs

Google Places API for iOS & Google Maps SDK for iOS are now in separate CocoaPods

noreply@blogger.com (MapsDevrel) — Tue, 26 Jul 2016 00:27:00 +0000

In today’s release, the Google Places API for iOS 2.0 and the Google Maps SDK for iOS 2.0 are now in separate CocoaPods. For developers who only use the Google Places API for iOS, this will significantly reduce the binary size of their app.

What does this mean for me? What do I have to do?

Nothing immediately for your current implementation, but we strongly suggest that you upgrade within the next year to the new Google Maps SDK for iOS 2.0 and Google Places API for iOS 2.0. The Google Maps for iOS SDK Version 1.x will become unsupported in one year’s time.

If you are using the Standard Plan Google Maps SDK for iOS 1.x, and haven’t specified a version in your podfile, you will be automatically upgraded to the new Google Maps SDK for iOS 2.0 when you run ‘pod update’. If you use any Places functionality, we’ve created this migration guide for the Places API to step you through the process of migrating to the new Google Places API for iOS 2.0.

In addition, we’ve documented how to extract all the frameworks (Maps, Places) from the relevant CocoaPods so you can manually include the SDKs in your project rather than using CocoaPods if you wish. [Issue 8856]

What does this mean for Premium Plan Maps SDK customers?

There is no longer a separate Google Maps Premium Plan SDK. Instead it has been replaced with the new streamlined Google Maps SDK for iOS 2.0 for both Standard and Premium Plan developers.

We’ve created a Premium Plan migration guide that will step you through the process of migrating to the new Google Maps SDK for iOS 2.0. We’ve also documented how to extract the frameworks from the CocoaPods so you can manually include the SDKs in your project if you’d prefer that. Your Enterprise Maps key will continue to work, as will your Premium Plan.

Please note:
The Google Maps SDK for iOS Premium Plan SDK 1.13.2 (current version) will be supported for one year during which time we suggest you upgrade to the new streamlined Google Maps SDK for iOS 2.0.

Take a look at our release notes and start using version 2.0 today!

Posted by Megan Boundey, Product Manager, Google Maps Mobile APIs

I/O session: Location and Proximity Superpowers: Eddystone + Google Beacon Platform

noreply@blogger.com (MapsDevrel) — Mon, 25 Jul 2016 15:05:00 +0000

Bluetooth beacons mark important places and objects in a way that your phone understands. Last year, we introduced the Google beacon platform including Eddystone, Nearby Messages and the Proximity Beacon API that helps developers build beacon-powered proximity and location features in their apps.

Since then, we’ve learned that when deployment of physical infrastructure is involved, it’s important to get the best possible value from your investment. That’s why the Google beacon platform works differently from the traditional approach.

We don’t think of beacons as only pointing to a single feature in an app, or a single web resource. Instead, the Google beacon platform enables extensible location infrastructure that you can manage through your Google Developer project and reuse many times. Each beacon can take part in several different interactions: through your app, through other developers’ apps, through Google services, and the web. All of this functionality works transparently across Eddystone-UID and Eddystone-EID -- because using our APIs means you never have to think about monitoring for the individual bytes that a beacon is broadcasting.

For example, we’re excited that the City of Amsterdam has adopted Eddystone and the newly released publicly visible namespace feature for the foundation of their open beacon network. Or, through Nearby Notifications, Eddystone and the Google beacon platform enable explorers of the BFG Dream Jar Trail to discover cloud-updateable content in Dream Jars across London.

To make getting started as easy as possible we’ve provided a set of tools to help developers, including links to beacon manufacturers that can help you with Eddystone, Beacon Tools (for Android and iOS), the Beacon Dashboard, a codelab and of course our documentation. And, if you were not able to attend Google I/O in person this year, you can watch my session, Location and Proximity Superpowers: Eddystone + Google Beacon Platform:

We can’t wait to see what you build!

About Peter: I am a Product Manager for the Google beacon platform, including the open beacon format Eddystone, and Google's cloud services that integrate beacon technology with first and third party apps. When I’m not working at Google I enjoy taking my dog, Oscar, for walks on Hampstead Heath.