Alami: Hello, everybody, and welcome
to "Secrets and Surprises of the Google Geo APIs".
My name is Ossama Alami. I'm a developer advocate
on our Geo Developer Relations team,
and I'm here today presenting with Aaron Jacobs,
who is a software engineer on the Maps API team.
So what do I mean when I say
"Secrets and Surprises of the Google Geo APIs"?
Well, what I want to do--
what we want to do in today's session is give you,
firstly, an overview of your options as a developer
when you think about Geo, Spatial,
and Geospatial APIs at Google,
and then go into some specific features of the Maps API,
the Earth API, Fusion Tables, our web services,
and the Static Maps API, to highlight some features
that you may not know about, some features
that you may have seen but don't know how to use,
and give you an idea of what's new,
and some exciting features.
So we'll start with the overview.
When you think of Geo at Google, people typically think of
the Maps API Version 3, or the Maps API,
the JavaScript Maps API.
Our JavaScript Maps APIs are now active on over 600,000 sites,
and it is our primary mapping API,
and what you typically think of when you think of Maps at Google
as a developer.
But we have more than just these,
what I'll call user-facing APIs, these mapping APIs.
There's the Earth API, which we'll talk about today.
This lets you embed Google Earth and a web page
and has a JavaScript API you can work with.
There's a Maps API for Flash,
for any action script developers in the audience.
We have a Static Maps API, which we'll also talk about today.
And then for Android and IOS devices,
we have a native SDK, that you can use for mapping
if you're building a native application.
But there's more than just these user-facing APIs.
There's a suite of developer tools,
supporting APIs within Geospatial at Google,
that support you as a developer in building these applications.
There's our web services, Fusion Tables,
both of which we'll talk about, KML, which is an open standard
for representing geospatial data,
SketchUp, which is a tool for 3D modeling,
and you can then take those models
and put it on Google Earth,
and then Earth and Earth Pro themselves,
which are client applications that you can use
to visualize your data
as well as work with certain data formats.
But there's more to it.
Google has over 100 different APIs and developer products,
and lots of them that you may not immediately think of
actually have a notion of place,
a notion of location or some geospatial aspect to them.
You can get a user's location using the Latitude API,
geotag imagery using Panoramio and Picasa,
or geotag videos with YouTube API,
updates using the Buzz API,
and then there's some developer tools,
if you are an organization or a developer
that has lots of geospatial data, you know,
satellite images yourself, you can use Earth Builder
and Earth Enterprise to work with and visualize that data,
and then tools like Refine and BigQuery,
that don't necessarily have a specific geospatial application,
sorry, a specific geospatial feature--
but they are tools that you can use to work
with geospatial data sets, and then query them,
or refine that.
So that's sort of a very quick, broad overview
of what is available to you as a developer
when you think of Geospatial at Google.
And we'll go right now into some really exciting features
of Maps API Version 3--
again, some features you may not know about
and some features that are brand-new.
First, I'll start with an overview of the Maps API.
We released Maps API Version 3 at last year's I/O, out of labs.
Now if you're-- and we deprecated Version 2.
Now if you have an active Version 2 site,
I don't want you to worry.
We have a 3-year deprecation policy.
But I hope some of the things you see today encourages you
to switch to Version 3,
because that's where our active development is,
and that's where all of our new features are built upon.
The advantage of Version 3 is also that it was built
from the ground up to be both a desktop
and a mobile web-mapping API.
So in addition to support and the mobile browsers
for Android and Safari, we also support Blackberry 6 devices,
and the Samsung Bada browser,
and then the standard desktop browser support as well.
You'll notice IE 6 isn't listed here.
While we--while the maps-- thank you.
While the Maps API will work in IE 6 and will not break,
there are certain features that will--
they'll degrade well, but they won't be available to IE 6.
But you can rest assured that your map will continue to work
and function with Internet Explorer 6.
I said "loads of features". Here are just some of them.
The things in blue are some of the things
that we're going to talk about today.
As you can see, there's more to it than just a map and markers.
You can do so much more with the Maps API.
And the first thing I want to talk about
is 45-degree imagery.
So this 45-degree imagery, you'll notice
I'm looking at an angle, an oblique angle.
If I zoom out-- this, by the way,
is Google's headquarters in Mountain View, California,
which is about 40 miles south of us here--
if I zoom out, I have the standard satellite imagery.
Now, I have the smooth transition as a user
when I zoom in to switch to a 45-degree imagery,
and right now I'm looking north, which we'll call 40--
which we'll call, sorry, zero degrees.
I can look east at 90 degrees, 180, 270, and back to zero.
And this is really high-resolution imagery,
so you can see as I zoom in, you get a lot--
a lot of detail, more than what you would get
with just satellite maps.
And as a user, I can turn off 45-degree imagery,
or go back and add labels.
We have an ever-increasing list of cities
that's available worldwide.
So I was gonna show you Santa Cruz,
which is just further south of us here,
and we also have Venice, Italy,
as well as a large, ever-increasing amount of cities
available globally.
And so what's the code look like
to enable this 45-degree imagery?
It's not enabled by default for the Maps API,
but it's really, really simple, and this will be a common theme
in this presentation.
The code to enable these features
is actually really, really simple, really easy.
Only a couple lines of code, and you can have a world
of new possibilities and features in the Maps API.
So I simply set the map to-- set, on the map,
call "set tilt," pass in "45" for 45 degrees,
and this enables 45-degree imagery,
so when a user zooms in at an appropriate zoom level,
it'll naturally switch to that 45-degree imagery.
And then to reset it,
if I want to disable satellite imagery,
I just call "map.set tilt to 0."
And if I want to programmatically
set the heading,
I just call "map.set heading," and pass in one of those--
one of those degrees.
Another feature that is unrelated to 45-degree imagery,
but I do like to demo with 45-degree imagery,
because it really gives you an idea of the surrounding area,
is this overview map control.
So this, I can move the box either in here,
or as I pan, the overview map control will update,
and if I go back to map, it'll switch to map.
This gives me a higher perspective,
a zoomed out perspective of where I am looking at,
so the user can really understand the location,
and this will collapse or expand.
So the code to this is, again, very, very simple.
When I create a map, I pass in "map options."
If I want the overview map control,
I just pass in "overview map control true,"
and if I want it open by default,
I pass in an overview map control option,
and I say "opened equals true."
A new feature in the Maps API which I really like
is marker animations.
We have two animations that we support.
You can see those markers dropping.
There's the drop animation, and there's--
as I move this marker, we have draggable markers as well.
You can see the marker drops and animates.
This makes it a little bit more of an interactive experience
for the user, feel like they're actually performing an action,
and confirmation that it worked,
because they see the animation.
And then we also have the ability
to make all the markers bounce.
I really urge you to use this feature with caution,
because a little bit is fun.
Too much is a little annoying.
We'll leave those bouncing.
When I create a marker, if I want to pass in an animation,
or if I want to animate it, during creation of the marker,
I just pass in the animation option here
and I set the animation that I want.
In this case, "drop."
The other animation we support is "bounce."
If I've already created a marker and I want to set an animation,
I just call marker--
on the marker I call "set animation"
and I pass in the animation that I want.
And then if I want to clear the animation,
just call "set null"-- sorry, "set animation,"
"pass," and "null."
So there's been lots and lots of improvements to markers
in Version 3 of the Maps API very recently,
including many speed improvements.
If you want to learn more about this stuff,
you should go to the session entitled "Speedy Maps"
which is 10:45 A.M. tomorrow.
Layers is another feature of the Maps API
that you may not know about.
This enables you to very easily add additional data
on top of the map.
We support various types of layers.
The first UM I'm going to demo-- Geo RSS--
let's you consume a Geo RSS file or a service
and then easily display that on the map.
In this case, we're hitting the Flickr API
to get geotagged imagery of our tech writer's dog
across North America.
And then the other way that you can get your data
on top of it, on top of the map very easily
is to use KML.
And in this example,
I'm just loading KML for transit lines in Chicago.
So the other examples here are more using Google's data
and showing that on top of the map.
In this case, I'm showing traffic in Chicago.
Every time I practice this,
this highway has always been red,
so I don't know what's going on there.
And then, bicycling-- this changes the view of the map
and then highlights bicycling routes,
roads that are known to be good for biking,
and roads with bike paths.
You can see, as a bicyclist, I can get a really good idea
of what's easy to bike through in Chicago.
And then, Panoramio--
I talked about Panoramio briefly earlier.
Panoramio is an image-hosting site
that has exclusively geotagged imagery,
and we've added a Panoramio layer,
and it's more than just pulling in imagery.
You can see here, I get a good idea
of user-contributed images of Chicago,
but I can also filter by either a specific user--
so if you have a Panoramio account
and only want to show your photos on the map,
that's very easy to do-- or I can filter by a tag.
So here I'll search for Wrigley, and you see,
the stadium shows up here and there are various images
that I can pull up.
And then down south,
there's actually a Wrigley Building in Chicago as well,
and that's coming up.
So all these layers work pretty similarly.
It's very easy to instantiate them
for both KML and RSS.
I use the google.maps KML layer.
It understands both formats,
and I pass in the path to that file or that service
that's returning either KML or Geo RSS.
Traffic layer and bike layer and Panoramio layer,
I just instantiate it.
And then, for the Panoramio layer,
if I want to filter by user or by tag,
I just call "Panoramio layer.set tag"
or ".set user ID" to filter by those.
And then in all cases, to add it to the map,
I just call the set map property of the layer,
and I pass in the map that I want it to appear on.
If I want to remove it from the map,
I just call "set map, null." I talked briefly about KML.
If you want to learn how to create highly performant KML
for both consumption in the Google Maps API
and Google Earth, you should go to the session
titled "High Performance KML for Maps and Earth"
which is this afternoon at 3:45.
Draggable directions is one of my favorite features.
It was a highly requested feature for the Maps API,
because people saw this on maps.google.com.
They saw that they could drag directions,
and now whenever they see directions,
they want to drag it, right?
The user sometimes knows a better path
to get to a location.
Here, I'm mapping from Moscone to our headquarters
in Mountain View, and you know, maybe I know that 101
is really terrible this time of day,
and I'd rather take 280.
I can very quickly click and drag that over,
and it'll update the textual directions
on the right automatically.
Another feature that you may not know about is
these text directions actually link up directly to the map,
so as I click, a user can see that individual turn.
Draggable directions, again very easy to add to a map.
This example shows you how to add directions to a map.
The things I want to highlight are the top,
these renderer options.
I'm setting draggable to true, and I'm passing this
into a directions renderer.
Directions renderer is the object
that manages rendering the directions,
both in textual format and on top of the map.
Now, since the user has an ability to drag directions,
you as a developer may want to know
when they've interacted with that
and when the directions have changed.
You just need to listen to directions changed event,
which we now expose.
And then you can perform some action.
Street View is another very, very popular feature.
We have a huge Street View coverage around the globe,
and when we implemented Version 3 of the Maps API,
we wanted to implement it in such a way
that it was usable on all mobile devices.
So we can't rely on Flash being installed, for example.
So Street View in V3 of the Maps API
is implemented purely in HTML and JavaScript,
and this gives us the ability to support you as the developer
adding overlays on top of the Street View,
so markers and info windows,
as well as completely custom Street View,
which is a really exciting feature that I'll demo.
And then, we've also exposed the Street View service,
the data service, which lets you query us
to find out where Street View imagery is available
and some other data about that Street View imagery.
Here's an example of overlays.
In this case, these overlays are just markers.
I have just a cafe, and a bank,
and here I'm programmatically going to switch to Street View
using this button.
And you can see, the marker shows up here,
and so does the info window on top of the Street View.
Meanwhile, I'm panning, and everything updates.
As I move down the street,
you can see there's another marker here
that gets larger as I get closer.
Naturally, it's a Starbucks.
And that works fine as well.
So this gives you more options when you're working
with Street View in displaying data on top of it.
Another feature I'm going to demo is custom Street View.
Here we have Street View imagery--
our Google Street View imagery-- outside of our Sydney office.
There's a bunch of buses parked in front
because it's across the street from a casino.
As I move down the street, you can see this is
the standard Street View imagery.
If I move up the street, I've added a link,
for this demo, to the Google Sydney office.
This is not part of our Street View imagery
that we provide to you,
but something that you can do as a developer.
And here, I've taken a panoramic image of the interior
of the Sydney office, the lobby, and I can view this,
and then, again, link back out into the street.
It's a great way to do indoor mapping,
and so that the imagery for Street View doesn't end
on the street, but rather takes you into a building.
If you want to learn how to do this, you should go to
the "Map Your Business Inside and Out" session,
which is at 1:45 P.M. tomorrow.
So I said V3, we optimized it for mobile.
We are also very concerned about keeping speed up
and latency down.
So when we wanted to add features to the Maps API,
we didn't want to bulk up the JavaScript that the user
has to download and then the browser has to parse,
but we wanted to add some new and exciting features
and keep the load time down.
So we've introduced this concept called libraries.
And using a library is very simple.
When you load the Maps API, there's just a script tag
to load the Maps API.
I specify a libraries parameter.
I pass in a comma-separated list of libraries.
In this example, you see Panoramio,
which I demoed earlier, is actually a library
that I loaded for that demo.
And here I have Geometry, AdSense and Places,
which I'll demo right now.
Geometry is a library that lets you compute angles,
distances, and areas from latitudes and longitudes.
So if you want to do some spherical geometry queries,
you can use it-- load this library and use it.
And it also comes with an encoding library
that lets you encode a path,
so encode an array of latitudes and longitudes
into a string representation of that,
as well as decode that back into latitudes and longitudes.
AdSense.
I imagine most of you are familiar with AdSense, yeah?
Okay.
AdSense is a way for you, as a developer or a publisher,
to monetize your site by placing relevant ads on your site,
and then there's a revenue-sharing model.
What we found was that a lot of web pages have just a map,
or a map is the core component of it.
That's what the user is interacting with.
And AdSense only displays relevant ads
based on the context, the textual content of your website.
So it wasn't getting the relevancy
of where the user was looking at to display relevant ads.
Well, we fixed that with the AdSense library
for the Maps API Version 3.
This is a library that you can use to monetize, now,
your mapping application.
And it takes what the user is looking at
and serves relevant ads for that.
So if a user is looking in wine country,
north of us in San Francisco, they'll likely see ads
about hotels, or winery tours, or things like that.
So it becomes much more relevant ads
that a user is likely to click on.
It's very easy to add this to your map as well.
All you do is create arbitrary div for the Ad Sense ad
to live in, pass in the format of the ad,
which is a standard AdSense format,
and then if you want the ad to live on top of the map,
you can pass in a control position for the ad,
but the ad can also live off the map
and still be tied to the context of the map--
your publisher ID, so we know where to send the checks,
the map that it's tied to,
and then whether it's visible by default.
And then I just create the ad unit "new google.maps.adsense,"
add unit, pass in the div that it's living on,
and the ad unit options that I just described.
And this is what it looks like.
This is an example of an ad showing up on top of the map.
Here you can see, I'm looking in Monterey,
which is south of us, another tourist destination,
has a famous golf course nearby, so I'm seeing ads for hotels
and a golf course.
Oh, man.
Okay.
So you can see, I'm moving.
This moves to the bottom left.
Let's see if this works.
Sorry about this, guys. This moves to the right.
Apparently if I use a drop-down box three times,
it'll fix itself.
[indistinct chatter]
[laughs]
So very, very easy to-- so that sort of shows you
where it can live on the map and then the format will change,
the actual format of the ad--
I'm not going to click on that right now--
to either--any of the standard AdSense formats.
So you know, one of them is a long bar,
one of them is a bigger box,
one of them is a smaller box, et cetera.
And then Places-- Places we announced
that we launched out of developer preview
in the session earlier today.
There's also a Places library that you can load
for the Maps API Version 3.
It supports two services: auto-complete,
which, if you're familiar with maps.google.com,
when you start typing, you see a list of possible results,
auto-completion of addresses
or auto-completion of business locations.
We're giving you the ability to have that same feature
on your sites,
using the auto-complete functionality and Places.
And then we have a Places search service,
which given a bounting box or a latitude and longitude
and a radius,
will let you search for local business listings
and points of interest.
If you want to learn more about how to use Places,
including the web services we're launching with Places,
you should go to the "Location-Based Development
Using Google APIs" session,
3:00 P.M. tomorrow.
And so I talked about libraries,
but what we also make available are utility libraries.
These aren't loaded through the libraries tag in the Maps API,
but are instead open-source utilities that you can download,
modify, and then use in conjunction with your map.
They are developed by the Maps API team,
and we do actively develop them and support them.
You'll find utilities that do clustering,
that do custom markers and info windows,
that do root boxing, and then a very highly requested feature,
Google Earth integration,
we recently released as an open source library.
So you can download this library
and get the Earth button on Maps.
You know, it's Map, Satellites, Earth,
and it'll transfer all the items that you have on your map
to the Earth instance and sync the two.
So a user can now view the map-- view your content
using Earth as well--
which leads me into discussion about the Earth API.
Again, the Earth API is a way for you to embed Earth
in a web page, and it has a JavaScript API around it,
so that you can define the user experience
and what content is displayed on top of it.
It does require a browser plug-in, the Earth plug-in,
which has support on both Windows and Mac.
And what does this look like?
There we go. So here's Google Earth.
I can turn on borders.
There are various options for what I can do.
I programmatically set a button
that just jumps to San Francisco.
I can pan down here and turn on or off terrain.
One of my favorite features is the buildings layer.
This gives you a really good idea
of what a city looks like in 3D
as opposed to a top-down view of a map.
Excuse me.
And as this loads,
you'll see more and more detail will come in,
in San Francisco and the Bay Bridge.
And then, we recently added trees to Google Earth.
We have over 80 million trees mapped.
We get this data from a variety of sources.
A lot of it is actually from satellite imagery now,
so it's where we pick up trees
and add the specific type of tree to that location.
Let's see.
Here we have trees, and if you don't believe me,
we have also enabled Street View.
If I click and drag this here,
there are all the trees.
Another thing I'll show you in Street View--
we'll jump to Moscone here--
is, as opposed to Street View
on Google Maps and the Maps API,
Street View in Earth is actually continuous.
It does interpolation of the imagery, between panoramas,
and so it's a much more fluid experience
going up and down the streets.
So that's a very cool feature, only available in Google Earth.
I must say though, my favorite feature in Google Earth
is historical imagery.
This gives you access to Google's historical imagery,
satellite imagery.
Google is a relatively young company.
We've been around for about a decade,
and Keyhole, the company that was acquired,
that then built Google Earth, is even younger than that,
but we've been actively acquiring historical imagery
and adding it to Google Earth,
which you can access through the API.
This enables you to build really new types of applications
that deal with history and the context of a place.
Here I'll show you.
I'll enable historical imagery.
I've got a slider-- which as a developer,
you can show or not show.
And then, I can disable it, re-enable it,
and I'll jump to San Francisco in 1988
to show you a cool demo that I like to show.
So there was an earthquake in San Francisco in 1989
that collapsed this freeway here
that led sort of through the heart of the city.
I'll show you. This is the city.
So we can actually see that.
This is prior to the earthquake,
and if I move the historical imagery forward to 1993,
you can see that the earthquake--
or, sorry, the highway collapsed,
and then they took down the freeway.
But there's still a freeway here, and as I move forward,
you can see that they actually tore down that entire freeway
and built this ground-level promenade.
And then, jumping to the current time,
you can see that they've added trees
and it actually looks quite pretty.
But what I love to show about this demo
is that, even 20 years later, there is a scar
that runs through the city.
Where the freeway used to be is now all parking lots.
In fact, this is the only new building that's been developed,
and if I jump back to 2008,
you can see it's a parking lot as well.
So 20 years later, after the earthquake,
there is still a visible scar that you can see
through the city, that you can now--
you can tell these stories
using our historical imagery in the Earth API.
And then I want to talk about Fusion Tables.
Fusion Tables is basically a tool for storing,
collaborating, and sharing large amounts of data.
You can think of it as a cloud-based database,
with tight integration with the Maps API,
spatial query support,
and a sequel-like query syntax and API.
The best way to show you Fusion Tables
is to actually do a quick demo.
So here I have Fusion Tables.
I have a list of tables that I own,
and I'm going to show you two examples.
First is this table of roughly 2,000 Brazilian beaches.
I have the name of the beach, latitude, and longitude.
One of the most difficult-- one of the most common questions
I get is, you know, "I have 10,000 points
"that I want to show on the map.
What's an easy way to do this?"
Well, creating an individual marker for those points
gets quite cumbersome and very slow,
can be very slow in a browser.
So Fusion Tables supports a very easy way
to visualize this data.
I can just click "visualize map," and you see,
it's rendered out all these 2,000 markers
on top of 256-pixel square tiles,
which is the same tiling scheme that the Maps API uses,
so it's a transparent tile with just the markers,
and then through JavaScript, it does the hit testing
to determine where a marker is and then pull that data through.
So this is a very quick map.
There is no lag.
I very quickly added these 2,000 points.
And then if I want to display a heat map,
I just click a check box.
Now, it's very easy to display a heat map.
A heat map is, in case you don't know,
not a map of temperature.
It is a map of density.
So there is a high density of beaches located down here,
and it's not quite as dense with beaches over here.
And then the other demo I'll show you is this.
So I downloaded a CSV from the American Community Survey,
which is this government organization
that puts out demographic data every year.
So it's broken down by congressional districts,
and it has some demographic data,
like what's the median age of this congressional district.
And then, using Fusion Tables, I merged this CSV.
I uploaded the CSV to a fusion table,
and then I merged that fusion table
with a fusion table of all the U.S. Congressional districts,
the shapes of the U.S. congressional districts,
which I found on Fusion Tables.
We have a set of public tables that you can download from,
and you can make your data public as well.
So you can see, you know, here is a shape of--
or various shapes of the first Alaskan Congressional district.
Maybe there's only one.
There's only one.
And I can visualize this on a map,
so it supports more than just points.
It supports polylines and polygons.
This is not a particularly interesting map, because,
you know, I can click on this and I get all the data,
but it doesn't really tell me anything.
I can very quickly click on configure styles.
Let's say I want to color this map
based on the median age of the population--
let's say from green to red
and 25-50.
And you see now I get a thematic map,
a map that I can very quickly look at
and see which Congressional districts trend older
and which Congressional districts trend younger.
And then if you're done, if this is all you want to show,
I can actually just get an embeddable link here,
copy and paste into my web page, and I get a map.
But there's more.
I mentioned tight integration with Fusion Tables
in the Maps API Version 3.
Well, that's exposed through another layer
called the Fusion Tables layer.
You can see this is a Maps API site,
not an embedded I-frame from Fusion Tables.
It is in fact styled,
which is a feature Aaron will talk about in a little bit,
and here I'm displaying the Brazilian beaches
on top of my Maps API site,
so I can just define the experience however I want.
And I can enable heat map through the Maps API.
Maybe I need to click this two more times.
Yay, that worked.
And so I'm also going to show you
the Congressional districts maps that I just made.
And it supports arbitrary queries, so here,
I'm selecting the shape of the congressional district
from my table ID, where the median age
of the total population is over 30,
but I can very quickly switch this to 40,
and very quickly I get dynamic results back,
so you can build really
lots of exciting applications this way.
Okay.
There we go.
Fusion Tables layer works like the other layers.
You just create a new Fusion Tables layer.
In this case, I pass in a query.
If all I want to show is my fusion table
without refining or filtering the query at all,
I can just provide the table ID.
Otherwise, the sequel-like syntax,
where you can say average age is above 40, and then
if I want it to be a heat map or not,
I just set heat map to true or false.
If I want to set it, it's the same as other layers.
Just call "set map," or call "set map," "pass,"
and "null" to clear it.
So that's just a tiny bit of the features of Fusion Tables.
If you want to learn more about Fusion Tables,
how it integrates with the Maps API,
and some new features we're launching,
you should go to the "Managing and Visualizing
Your Geospatial Data with Fusion Tables" session,
which is today at 1:15.
With that, I'll bring up Aaron.
There you go.
Jacobs: Thanks, Ossama.
Is this on? Yes.
Thanks, Ossama. And, hi, everybody.
I'm here to talk about Maps API web services
and the Static Maps API.
What is the Maps API web service?
Well, in contrast to the user-facing APIs
that Ossama discussed-- the JavaScript, Flash,
Static Maps API and so on-- this is a database service
for you to call from your native code or backend server
and to consume information in JSON or XML.
It lets you benefit from Google's expertise
in geospatial data, so you can do geocoding to find out
where a street address is on Earth,
in latitude/longitude, and other information about it.
You can do directions queries and more,
which I'm going to talk about here.
I do remember that we have a terms of service
that requires you to eventually do something with this data
on a Google map, through the JavaScript,
Flash, Static Maps API, Earth API, so the idea here
is you can do further computation with your server
or your application and eventually display a map
to a user doing something intelligent
based on the results of that computation.
Oh, also, I should mention, most of the services
I'm going to talk about here are also available
in the JavaScript API, so look at the documentation
for that to see that you can also use it from the client
if that's appropriate for your app.
So the first one I'm going to talk about
that you may have missed is the Elevation API.
Now this is exactly what it sounds like.
It allows you to give us a line or a set of points
and to find out the elevation of those points on earth.
That's both elevation above sea level
and below sea level for points that are underwater
in oceans and lakes.
This uses our cool bathymetry data that we have
that you can see on Google Earth, previously.
Now you could use this to visualize elevation profiles
or do intelligent things for bikers or walkers
and other stuff that I haven't thought of.
You guys are the creative ones.
It's really easy to use.
For example, here I have sort of a trivial request that says,
"Given a path from lat. long. 0-0 to 0-10--"
this is from the Atlantic Ocean to the shore of Africa--
"sample this path three times."
You could use a much larger number.
This is for my example.
"And tell me the elevations of the points along that path."
So you get back a JSON or XML response
that looks something like this.
You see we sampled it at 3.00010 and one in the middle,
and you can see that you go from approximately
5 kilometers under the ocean to a little bit shallower,
to about sea level as you hit the coast of Africa.
It's that easy to use.
Check out the documentation.
It has a couple other clever features,
like you can specify points as addresses
if that's helpful for you.
Another service I'd like to talk about
that we launched last week is called the Distance Matrix API.
This is where you have a set of origins and destinations,
and you want to find out for each pair of origin/destination
how far they are from each other.
Now, this is in terms of drive time and drive distance
or walk time and walk distance, not as the crow flies,
so this can be pretty useful to you.
It uses our Directions API data.
So for example, if you want to find out how far it is
from L.A. to San Diego and--
sorry, from L.A. or San Diego to San Francisco or Sacramento,
you would make a request that looks like this--
you see it's very easy-- and get back this information.
Now what's this good for? You could, for example,
use this to make an advance store finder app,
which given a set of your stores or locations
or whatever it is that you are displaying,
and the user's location, or a couple of users' locations,
home and work,
you can do intelligent things based on this,
much smarter than getting the closest store as the crow flies,
which might involve a heavily trafficked road
or something like that.
Yes.
Another directions related service is route optimization.
Now, if you've used the Directions API,
you know that you can give an origin and a destination.
Say the user wants to go from A to D, via B and C,
so that means you need to hit points B and C in the middle.
Previously, if you tell us this, we'll just naively follow
the set of points that you specify,
but this may not be optimum.
What we allow you to do is, in your way point list,
you can say "optimize true," and what we'll do is
we'll reorder those intermediate way points for you
so that the user, or whoever's traveling,
has the most efficient route through all these points.
This is known as the traveling salesman problem,
for those who are familiar from computer science.
As with all of the things I've mentioned so far,
it's very easy to use. You just say "optimize, true."
We hold the origin and destination fixed
because we assume that's where the user wants to start
and wind up, and we do the magic for you.
We'll give back the right directions
based on the optimum order, and if your application
needs to know how they were reordered for some reason,
we return the field called "way point order"
that tells you that.
So for example, with this query here,
I've generated a few maps using aesthetic Maps API--
or one map actually-- so this is from L.A. to New York
via these intermediate cities.
The red path is what you'll get if you do it in the naive order,
and you can see that it crisscrosses
all over the country.
It's very inefficient and probably takes a few days.
Whereas the green path, you see it's been reordered
to do this in an efficient way.
So yeah, it's exactly what it sounds like.
Another directions-related feature
is bicycling directions.
So previously in the Directions API,
we only supported driving and walking,
and you guys are probably familiar with these
from maps.google.com,
which allows you to get directions, as you know.
We've added support for bicycling directions,
and all you do is say "mode equals bicycling,"
and we'll use what we know about bike paths and local roads
and that sort of thing to find routes
that are suitable for biking.
So for example,
here's a trip from--sorry,
from Santa Monica to Hollywood in L.A.,
and if you're familiar with L.A., you see this red path,
which is the driving path-- takes a couple of freeways
that you really don't want to take on a bike.
But the green path takes bike paths and local roads,
and it's probably quite a bit more pleasant.
We also of course adjust all of the drive--sorry, ride times
and that sort of thing according to biking speed.
Moving on, another announcement that we're making--
or have made recently, excuse me--
is that now everybody is allowed to use SSL for our web services
and JavaScript requests.
If you're not familiar with SSL, this is a way
to encrypt the data that the browser
or your code sends to Google so that nobody in between
can snoop on it.
You can use this if you have sensitive user application data
that you don't want anybody in the middle to see.
And it's just kind of a good idea for the Internet,
for users' data.
Previously this was a feature that was only available
to Maps API Premier customers, but now you can all use it.
Everybody can use it.
It's very easy.
All you do is make sure you're sending your request
to maps.googleapis.com, and change your URLs
to use HTTPs, and it's that simple.
You don't need to make any other changes.
Right, so moving on to the Static Maps API.
The Static Maps API is an alternative to the JavaScript
and Flash and Earth APIs, which are for interactive maps
that are sort of immersive for the user.
They can drag them around and zoom in and out
and do what they like.
If you're in an environment where you don't have JavaScript
or Flash available, or where latency is absolutely critical,
what the Static Maps API allows you to do
is create an appropriate URL
that will return a map image that can contain markers
and polylines and custom icons,
but is not otherwise interactive.
And you simply stick that in an image tag,
and now you have a map on your site, or in your mobile app,
or whatever environment you're in.
I should mention, there is a requirement
that if you're in a mobile app or anything like that,
you need to link back to maps.google.com in some manner.
But it's very easy to use.
You simply give a size, and you can say--for example,
if you want to show a map of Australia
with these cities highlighted with markers,
all you do is make a URL like this.
You get back a map like this. Isn't that beautiful?
I have a couple Static Maps API features to discuss.
The first one is high-resolution static maps.
So for example, if you are on a mobile device
with a high DPI screen or you need a map for printing purposes
or anything like that, what you can do is tell us
to upscale the map by 2x or 4x.
And what we'll do is we'll give you a map back
that has twice or four times as many pixels in each dimension,
and more rendering detail.
So when you show that map at the same physical size
on the mobile screen or printed, it will look better.
It will look less fuzzy.
It's pretty easy to use.
You just say "scale equals two," "scale equals four."
If you have custom icons for your markers,
there's a way to specify that these are
the appropriate resolution, and we will render them correctly.
So for example, here's a map of Sydney at our usual scale,
and I will show you one at 2x scale which--
imagine it has gotten twice as large
and is now outside the bounds of the slide.
It's kind of hard to show on a projector,
but you see that all of the labels have gotten larger,
the road detail has gotten larger,
there's more rendering detail there.
So now if you shrunk this back down to the same physical size,
it would look better for your user.
See the documentation for more explanation of how this works.
Finally, one other feature is custom static map styles.
Now, this is also available in the JavaScript and Flash APIs.
But it's this really nifty feature
that allows you to change the default styling of Google Maps
to fit the branding of your application or product,
or to emphasize particular data by de-emphasizing other data,
or coloring it or however you like.
It's based on a set of style parameters
in the Static Maps API,
where you give a list of features
that you'd like to restyle-- for example, roads or water
or anything like that--
elements you'd like to restyle,
like their labels or their geometry or both,
and then a way to restyle them--
for example, changing their color
to something that's bluish here.
Let me give you an example.
This is a map of the area around the Moscone Center
where we currently are.
You can see it's in the Google style
that we all know and love, hopefully.
And if you change it,
you can change it relatively significantly.
I've re-colored the roads to be blue,
done some desaturation.
I've turned off some labels,
for example the P and the-- I can't read it from here,
but these labels.
And you see it's all gone.
You've significantly changed the look and feel of the map.
Now we have a--if you Google for "styled map wizard,"
we have this nifty tool that will let you interactively
create these styles.
And you can see that it's pretty powerful.
So for example, here's a map of San Francisco.
I can easily change the water to red, say add style,
and for example, change the roads to green,
and now I have a map that seems quite a bit different.
It's also very ugly. Please be careful with this,
but it's up to you to make things that look nice
and emphasize what you want to emphasize.
Excuse me, I need to go back to my slides.
So in summary, Geo APIs at Google.
There are a lot of them.
It's not just the JavaScript Maps API.
We have Flash, we have Earth,
we have all of the other products
that have geo-integration that Ossama mentioned.
The Maps API itself has a ton of features.
You often just see maps that are a base map
and markers and that's it. Go beyond that.
You can make great user experiences.
Fusion Tables is a powerful platform for storing your data
and visualizing it in even more advanced ways.
We have the Earth API
for all these interactive awesomeness and trees.
And we have secure web services that you can talk to
from your back end,
make sure user data doesn't go out from the browser,
optimize for latency, whatever you need.
And we have the static map.
The Static Maps API,
when JavaScript and Flash aren't an option,
or you need to optimize for latency again, as I said.
With that, I'm going to say thank you.
I'm going to invite Ossama up for Q&A,
and I'm going to mention,
if you'd like to give us some feedback on this talk,
please do.
Here's a short link that you can visit
to give us feedback. Thank you.
Alami: Thanks very much.
Jacobs: Does anybody have any questions?
Alami: Go ahead at the mic.
man: So a couple quick questions
in relation to Fusion Tables.
For one, how large of a fusion table
do you guys support, and like, could I upload a million points?
Alami: I believe we support up to 150 megs.
man: Okay.
Alami: But you can purchase larger amounts.
man: Okay.
And then the second question is, I know they come back as images.
Is there a special on-click event where I can hook in
and have first priority on getting the data
of where the point is?
And I'll give you my specific use case.
Really nice to have all those as an image
because it's less-- Alami: Right.
man: It's more performant, there's no DOM elements.
But if I have a user that hits a mouse down
and clicks on the actual point,
I'd like to be able to inflate it
as a regular DOM element.
Is that something I can hook into
through an event
and get back the dimensions of the place?
Alami: Yes. man: Okay.
Alami: So we do expose events based on clicks,
and you could also query Fusion Tables API separately,
but we do expose that through the Fusion Tables layer.
man: Okay, so I just take that and I can drop it
into a new mount marker, sort of, its own parameters
and it'll just create one at that point?
Alami: That's right. man: Cool.
Alami: We'll take the front.
man: So last I checked the-- sorry, the Maps API for GWT
is stuck on Version 2. Is that still the case,
and do you have plans to update that?
Alami: I don't know the answer to that.
I know there are-- sorry.
The question was, the Maps API for GWT
is currently on Version 2.
I know there are a couple of open-source Version 3
implementations of the Maps API.
I don't know what the current plan is for Version 2,
the GWT implementation.
We'll--back mic.
man: I've got two quick questions.
One is, I saw you color-code various states on the USA map.
Do you actually ship political boundaries that we could use,
or do we have to get it ourselves?
Alami: So the question was, on the U.S. map
for the Fusion Tables example,
I showed U.S. Congressional district boundaries.
Where did I get that data?
I actually pulled that data from Fusion Tables.
We have a large set of public tables
that we've made available as well as users
who have contributed data and made that available publicly.
So in Fusion Tables, all you have to do--
all I searched for, in fact, was U.S. Congressional districts,
and it's the first table I found.
man: I see, I see.
I have two more quick questions.
One is, in a typical map, is there an upper limit
to how many markers I can display--
like, can I display 20,000 markers?
Alami: Yes, so there is an upper limit.
The question was--
Jacobs: How many markers can you show on a map?
We do pretty well these days with lots of them,
with thousands even,
but if you have, like, a truly ridiculous number,
you can use something like Fusion Tables
or a KML layer or two to offload some of that work
to the server side and save the browser from doing it,
and it's even more performant. Alami: Yeah.
Specifically, there is no hard limit.
You can continue to add as many markers as you like.
Your browser performance will suffer.
man: I see. Alami: Yeah.
man: And the last question is, say I have a database
that has like 1 million addresses, customer addresses.
Is there a tool Google offers
to convert them into lats and longitude?
Alami: So the question was, if you have a database
full of addresses, and you wanted to geocode
all those addresses-- so if you upload them
to Fusion Tables,
Fusion Tables will take care of the geocoding.
Jacobs: There also is the opportunity
to use the geocoding web service,
which is one of those web services I mentioned.
You do need to make sure that you're within
the terms of service, using this with a map eventually.
I'm not sure of the details. Sorry, I'm not a lawyer.
But you can use either of these methods.
man: Thank you. Great presentation.
Jacobs: Thank you.
man: I had a small question regarding the Sun Cells input.
Is there anything for, for example, compass,
gyroscope, or any accelerational movement?
So basically, in the API, if the compass moves around,
do you have any simple input or do you need to use a 0,
90, and 180 and so on?
Alami: So the question was if there's any tie-in
to sensors on the phone, for instance, gyroscope.
There isn't anything specific in the Maps API.
You'd have to code that yourself.
Jacobs: You can of course get it from the HTML5,
support for it, or I think there are other technologies--
I'm not too familiar with this-- but no, we don't have
anything canned for you, sorry.
man: Okay. Thanks.
Alami: I will do the back mic.
man: Yes. Is it possible to work in offline mode?
No Internet?
Alami: The question was, will the maps work in offline mode?
The answer is no. Jacobs: Yeah.
Alami: We load map tiles from our servers,
as well as if you use services like geocoding,
or you rely on any of those.
It requires an Internet connection to make that work.
man: What if we have Enterprise database?
Alami: It would still require Internet connection
to make that work.
The one--sorry, the follow-up question,
I've been told by everybody to repeat the questions.
The follow-up question was what if you have
an Enterprise database or something.
There is a product called Google Earth Enterprise,
which will let you--
man: That's what I was talking about.
Alami: Yeah.
So I actually don't know the specifics about that,
but if you visit us in office hours,
or in the sandbox, I can find somebody
to answer that question for you.
Jacobs: Maybe at the front here?
man: Do you have any integration with Google Latitude?
Alami: The question was,
are there any integration options with Google Latitude?
There are no canned implementations.
There is no canned integration,
so you would have to write that on your own.
man: Okay, great, thank you.
Alami: Sure.
Jacobs: In the back?
man: The Fusion Tables-- you mentioned there was
a 150 data point limit on that.
Is there a way to layer multiple ones of those?
Jacobs: It's actually 150 megs, I think.
man: Oh, 150 megs?
Jacobs: So you can put a lot of data in there.
man: Okay, I've got more than that easily.
Is there a way that you can layer multiple layers
on top of each other-- to, let's say,
do a northwest region or southwest region--
and then put those layers
and generate heat maps based on that?
Alami: Yeah. The question was,
can I layer multiple Fusion Tables layers on top of the map,
and the answer is yes.
man: Excellent.
Alami: I believe you can do up to five?
Jacobs: You might need to be clever about what to do
with the boundaries,
especially if you're doing heat maps,
but I'll leave that up to you.
man: Great. Thank you very much.
man: My question is on metadata and coverage information.
For example, when you set the tilt to the 45 degrees, to 45,
what happens if the data is not available for the area?
And in general, I want to ask
about coverage information, like,
given the latitude and longitude of a city,
do we have historical data the area--for the area?
I wish you can create like a Google Maps API
database offline, manual UI base, to give that information.
That would be very valuable.
Alami: So a couple of questions.
The first was what happens if you call "set tilt"
on 45-degree imagery
and we don't have that imagery available.
It'll simply just show the satellite mode and--
Jacobs: More generally, do we have information available
about where we have various types of imagery,
and I don't know the answer.
Alami: You can query for imagery within the Earth API,
but we do not have a web service
that you can hit, or something within the Maps API
that you can query for historical imagery.
man: Okay.
man: A few questions on other layers you might have.
Do you have U.S. ZIP codes?
Alami: The question was on additional layers.
You can just search Fusion Tables.
I don't know off the top of my head
what we have loaded in there, and in fact,
people have made layers available
that I don't know about,
so simply go to google.com/Fusion Tables
and search for whatever you want,
or you can browse public layers.
man: And so this is relatively new, and--
Are you expecting a lot of user-contributed data?
Jacobs: Please contribute, yes.
Alami: Yeah.
Fusion Tables-- when did we--
so Fusion Tables came out of lab several quarters ago.
It is now not only--
man: Formally part of the API?
Alami: It is--
Jacobs: It's sort of an independent product,
but we have a little bit of, you know, nice integration here
in the Fusion Tables layer that Ossama described.
man: Okay. Alami: Yeah.
And we are, to answer your question,
yes, we are seeing quite a bit of usage of Fusion Tables
since we launched.
man: Thanks. Jacobs: Up front.
woman: Do you provide any documentation
on the heuristic that you use for the optimization,
for the routing? Jacobs: No, we don't.
And I personally don't know, but I could speculate with you
if you grab me later.
woman: Okay.
man: So we all have these Android tablets
with beautiful Vector Google maps.
Are you planning on bringing that to the browser
and opening the Vector Maps API to developers
on browser and mobile?
Alami: The question was about vector maps on the browser,
and the answer is, we typically don't comment
on our future product plans.
man: Okay.
Jacobs: Agreed that it would be sweet though.
man: Right. Jacobs: Yeah.
man: Hi. The Maps API that returns the JSON objects--
I've tried that with Google App Engine,
and I've, like, been immediately confronted with--
I guess it's like a 403 or something, you know, forbidden.
I've exceeded my quota.
And I assume it's just because someone else on that node
exceeded it.
I was wondering if there's a way to use a key for that.
Jacobs: So yes, so this is a difficulty
that we run into in shared hosting environments.
Sorry, the question was, I'm on App Engine
or something with a shared IP, and I get lots of quota denials
in the web services, geocoding or whatever.
This is a problem that we run into because of shared IPs.
It's hard to tell who's a user, who's not.
There is of course Maps API Premier
that you could sign up for and get a key,
if you have, like, a big project.
Otherwise, maybe you can try to do it on the client
where we have a more clever strategy for telling
who's an independent user, that sort of thing.
I don't have a good answer for you right now,
but grab me afterward.
Twenty seconds, if that's a quick question back there.
man: I'll try to make it quick. Jacobs: Yeah.
man: So let's say that I wanted to generate
a heat map off of private data,
say the last seven days of sales,
and it's rapidly changing.
I wouldn't want to upload that into Fusion Tables
before I make the render request, right?
So how would I integrate that kind of live feed
for my own private book of record, basically,
and generate a heat map on top of this stuff?
Alami: The question was about generating heat maps
using a live data feed.
Ultimately you do have to upload this into Fusion Tables.
You can keep the table private,
so you're not required to make this data public.
Jacobs: Unfortunately, it's a relatively computationally
expensive process in general,
so we're reliant on that at the moment anyway.
man: Right. If I could do a quick one.
Alami: Yeah.
man: So one thing that we talked with some of your guys about--
Alami: Sorry.
I'm getting a signal from the back,
but if you do have a follow-up question,
we'll meet you afterwards. Jacobs: Grab us outside. Sure.
Alami: Thank you.
Jacobs: Thank you. Thanks for coming.