Tip:
Highlight text to annotate it
X
Mano Marks: >> Hi, everybody.
My name is Mano Marks.
I'm here to talk to you about building scalable geo web applications.
With me is Keith Golden and Jeffrey Sambells and they are going to be handling different portions of it.
Normally when I give these kinds of presentations I like to encourage questions during and I'm not going to do that
this time.
We have a lot of -- a lot of area to cover and so we're gonna save questions for the end.
So, please, if you want, there's a -- you know, there's a moderator page for questions if you'd like, if you have a
question and you don't wanna forget it.
Put it in there and we'll get to those.
And also at the end we'll have, uh, questions for the microphones.
So, I'm gonna go ahead and get started.
Okay.
So, I'm gonna spend a little bit of time talking about what it means to be scalable.
The main problem with building a web application these days is that from my point of view people end up actually using
it.
And the danger in people actually using it is then your application might go down.
I think everybody here has heard the term "slash dotted" where your application gets posted to Slashdot, or Digg, or
some other -- some other popular web site and then a whole bunch of people go to it and then it overwhelms your
servers.
So, what we're gonna talk about today is how you can take that load off of you and your servers and put them onto us.
So, we have three basic approaches to that which I'll mention.
But let me just quickly run through some of these difficulties.
Well, the big one in the center is the users.
The users are the main problem, as I said.
If you have to build your own application infrastructure, if you have to build your own servers, you have to
load-balance, maintain your machines, you have to invest a lot of time, energy, and money.
You have to shard your databases.
You have to spend all this time doing things that are not building web applications but really maintaining it and
making sure that it stays up.
Now, some people really love doing that and a lot of them work for us.
I'm guessing that a lot of you don't like doing that and would rather just focus on the content creation.
And that's where we're gonna talk about.
Okay.
So, a few things to think about in terms of building scalable Geo applications in particular you want multi-format
output.
That is, you wanna be able to serve it in Google Maps, in KML, in open layers and whatever -- in whatever formats that
you can.
You wanna be able to do specialized spatial queries.
So, uh, be able to do bounding box queries at least. You know, radial searches, that kind of thing.
You want it to be highly customizable.
That is, I'm guessing the vast majority of you wanna do your own applications, run your own applications, and have it
be special to you.
And, you know, as programmers you have your own quirks and things you wanna do.
And sometimes you wanna rely on open Geo standards, like KML and GRSS.
So that goes along with the multiple format output.
So, here I'm gonna -- here's the handy dandy little matrix where you see I cleverly highlighted in blue, the answer.
But basically we're gonna talk about App Engine, the Google Maps Data --the Google -- I'm sorry, the Maps Data API and
Google Base.
I'm gonna talk about the advantages and disadvantages of them.
And you'll see that for the most part we have a very good coverage and we're gonna talk about some of the weaknesses
as we go along as well.
Okay.
I'm gonna talk about Google Base and I'm doing this first because I kinda wanna get it out of the way.
There's a number of people who just want to give data to Google and have Google store it and then do something with
it.
And we have this giant -- what I think of as this giant XML repository called Google Base, the back end of a lot of
services that you might have used like the Google product search, which I still wanna call Froogle, and various other
things.
It's got -- it's the back end, like a said, for a lot of our services.
If you put data into it, it becomes easily discoverable in search and it supports bounding box and radius searches.
It's got a Google Data API. It's got a lot of things that you want.
One of the things I wanna point out in the end is the upload times can be Kind of long.
So, fundamentally, when we're talking about the Google Data API for Google Base, Google Data -- Google Data is one of
our basic protocols for accessing Google services -- data and Google services.
So, I wanna mention that for Base.
It's got a lot of Google Data API which means it supports a lot client libraries that we've already good for that.
There's a lot of support in general for the Google Data API's but there's not a ton specifically for Base so this is
one of the reasons we don't encourage people to use it a lot.
I wanna point out here, just give you some code samples here.
This is how you put an item into Base.
This is a personal ad.
A surprising number of personal ads in Google Base, actually.
I think that's to increase their discoverability.
A lot of the search engines like Hot Or Not put their data into Google Base.
You'll see here there's an atom entry it's got a title, it's got an item type, location, gender, marital status.
You see, there's a lot of sort of customizable but also a lot of standard attribute data.
I'm gonna just mention this briefly.
I'm an XML head.
AtomPub, which is the basis for Google Data API's uses this term "attribute" and, of course, in XML, attribute means
something completely different.
But basically an attribute is like you see here, location, gender, marital status.
So, to repeat what I said earlier, there's a number of standard attributes and then there's also you can customize
your own personal attributes.
So, you can basically treat it as a big schema-less data store.
And then here's a sample spatial query.
So, of the products I'm gonna talk about at the moment, Base actually has the best spatial query support built in.
That's important, that phrase "built in."
And that's that it will allow you to do bounding box and radius searches based on a straight up query.
So, you'll see here, this is one long URL that I've broken out into these three lines here.
So, you've got your basic snippets.
You've got the query, which tells the type, and then the location, and that's how you get a -- that's how you get all
the personal ads within a certain -- within a radius of that, those latitude and longitude coordinates.
Okay.
I'm gonna talk now about App Engine.
So, Google App Engine is one of our premier developer platforms right now.
I think you probably have seen the number of different sessions that are available on Google App Engine.
You'll have seen -- during keynote they announced that we've now opened up the Java Runtime to anybody who wants to
sign up for it.
So, we're putting a lot of energy and effort into App Engine which we're not doing quite as much for Base.
So, what you have in it is a high-performance, high-availability, easy development server.
You can use Python or Java on it.
It's free to get started and it's built on Google infrastructure.
And when I say that, they're all built on Google infrastructure but you're actually building applications in a way
very similar to the way that we build applications at Google.
And, in fact, a number of our applications, like Google Moderator, are actually built on top of Google App Engine.
So, basically with Google App Engine, you run your own applications but you're running them on our servers and we
handle all the issues on scaling and denial of service attacks, and all those kind of things, and backups.
So, here are the advantages of it: It's built for scaling, it's replicated in data centers around the world, you can
use standard Python or Java libraries, although I will point out that you can't use anything that relies on C
libraries which unfortunately takes out a lot of the standard Geo -- Geo libraries like GDAL, OGR from use.
We have easy authentication.
You can authenticate using Google accounts very easily, and it's highly customizable.
Anybody running the application would have no idea that they were – they were running it unless you told them.
Disadvantages for spatial Applications is that it's very limited spatial support in queries.
And particularly it has limitation on inequality queries.
So, you build a model and put it into the -- of something -- you put an entity into the data store, it has a number of
properties.
When you do a query on that, analogous to a relational data base but not the same, you do a query on the different
properties, and you're only allowed one inequality on one property.
Sorry.
You're only allowed inequality on one property.
So, what you could do is you could say, give me everything with a latitude between X and Y.
So, that's an inequality on one property greater than X less than Y.
But you couldn't then do an inequality on longitude.
And the reason for this is that's it's built on top of a highly distributed database.
These things -- you're creating an index which might span multiple machines and there's no way to keep track of two
properties in that query -- in that index.
And that's just fundamentally we're giving -- we're exposing to you one of the limitations that we also work with in
building applications.
It's also a very different way of building applications than most people who start out developing a -- an app -- a
spatial application to start out with.
It's not -- you can't use post AIS, you're using our data store.
You can't use any of the standard spatial databases or libraries.
You're really creating a kind of cooler way of doing things.
But you're working within these limitations and you're doing it in a way that would be unfamiliar to most of you.
So, let me show you a few code samples from Google App Engine and then talk about approaches that people have made to
get beyond these limitations.
So, this is a very simple model.
You see it, you've got the import, class myLocation, you give it a name, and a location.
You'll see right there it's got this Geo point property that sounds very exciting.
When I first saw that I got very -- I was very excited and I thought great!
We're gonna have great spatial queries.
Unfortunately, you don't get very much for that.
So, here's a simple query to the data store.
After you've put any item into a data store, you use a GQL data query, a language and you would just say
MyLocation.gql where name equals something.
And that -- that colon one and "foo", that's a substitution process.
So, let's see, did I put in a slide out of order?
No, I did not.
Okay.
So, the only thing that this geo point property gets you is ordering.
So, if you order your query by the location property you'll get things in order from north to south, and then east to
west. North to south, east to west.
Okay.
All right.
So, let's talk about some of the approach -- I'm gonna talk about two approaches that people use to get around this.
One -- the first one is Geohashing.
This is a fairly common approach right now.
I was talking with people just last week at Ware Camp.
Somebody was saying they built on this.
It's -- Geohashing is you take the latitude and longitude and you hash them together to create a single value.
So, in one inequality query, you can query based on a string match on this hash and you use only the one inequality
query -- inequality in your query.
So, it's built on an open source library which is available in Python which means it's easy to use and very easy to
plug in and basically allows you to do a simple radius search on your properties.
I'm not gonna show you an example of it 'cause there's a few places where it falls down, particularly around the
International Date Line and the disadvantage is it still uses your one inequality query.
So, the idea is to allow you to do an inequality query on some other property.
Say you're doing a real estate search.
You wanna get all houses within a certain radius but you also want to get them at costs between a hundred thousand and
$250,000 which precludes you from getting a place in the Bay Area but you know, that's my point.
Okay.
So, let me talk to you a moment about Geo Model.
This was actually developed by Roman Nurik, who is sitting in the audience today. We can all cheer him.
This is a -- the approach here is to pre-confute something's location, essentially, dividing the world into a 16 by 16
grid and then each of those things into a 16 by 16 grid.
Basically it's a quad-tree, but it's a 16-tree instead of a four, whatever that would be.
And then you assign your entity to a cell at each different zoom level.
So, that's a basic approach. And then when you're doing a query you basically figure out which zoom you're at and pick
out the individual -- the individual cells that are appropriate for your bounding box and then you have -- then you
find everything that matches that.
And the advantage is that it places -- you're doing equality queries instead of inequality queries.
You're saying give me everything in this cell, and that cell, and that cell, and that cell, and that way you build up
a result set that you can then return to the user.
So, the advantage is it doesn't use the inequality query, and it's customizable different zoom levels, resolutions,
and grids.
It's also, by the way, an open source library so you can customize the library however you want, develop your own
algorithms for assigning cell numbers.
The disadvantage is it's kind of complex and it also doesn't scale as well with other geometry types.
Right now it's optimized for -- for point data.
So, it's hard to give it to somebody and say, here, get started with this.
There's a learning curve that's involved.
So, I've got some code in here and I don't have a ton of time because I wanna give Keith and Jeffrey the bulk of this
time to talk about the Maps Data API.
But just to give you some -- give you this and then when these slides go up and they're published then you can go
through some of the code.
Or you can go directly to look up Geo Model on Google Code site.
And let me -- I just wanna give you a short example of this work here.
This is geomodeldemo@appspot.com.
And what Roman did is he took Geo names, took the database from Geo names and took a whole bunch of locations, I think
just in the United States, and uploaded them to App Engine. I think they had a hundred thousand-ish records, something
like that.
So, we'll do a search center of San Francisco, California, and do a search.
So, you'll see that it's -- it kinda chews through quite a big data store and comes up with top ten results or so and
then also puts the center in there.
And now we're gonna do an inequality query, the minimum population, so something greater than 50,000.
And so here it finds the locations and the Geo name database that have populations of 50,000 or more within a radius
of San Francisco – setting the center at San Francisco, and displays it on the map.
And you'll see that his demo also very nicely then figures out what the bounds are of that search and resets the map
to it.
Okay.
And I think that is it for Google App Engine.
So, I'm gonna hand this over to Keith.
Keith Golden: >> Hi, I'm Keith Golden. I'm a tech lead of the -- of Google My Maps team
and more generally more user generated content efforts within Google.
And I'm very pleased to say that a few weeks ago we launched publicly the Google Maps Data API.
So, what exactly is this?
Mano talked about the -- how Google Base has a Google Data API.
So, this is a Google Data API specifically for Google Maps.
So, specifically, it's designed for storing geospatial content and it works closely with a number of maps capabilities
so in particular it works with My Maps.
Anything that you create using the My Maps editor within Google My Maps you can access using the Google Maps Data API
and vice versa.
Anything that you create using the Data API is accessible via My Maps.
Now, all Google Data APIs are essentially AtomPubs.
So, this is an atom, you know, it's basically a standard XML representation for both getting and modifying data.
We currently support three types of geometry: point, polyline, and polygon geometry.
Basically what we support right now is effectively limited to what you can actually display in Google Maps with My
Maps but we don't intend to stop there.
And anything that you create that you indicate as public will be searchable on Google Maps so we index it all for you
and we make it searchable for people who go to maps@Google.com.
We do provide a few capabilities that are not currently part of the My Maps user interface.
So, for instance, we support user-defined attributes which can have some structure to them.
You can define a type for your data, for instance, and units. We support efficient batch operations, and we also
support efficient, kind of incremental operations if you have an application.
So, for instance, you know, you all have one of these little toys.
We have a couple of applications written for the Android.
That's My Maps editor and an application called My Tracks.
Both of these applications use the Google Maps Data API.
And one of the problems with a mobile application is you might have a very large amount of data but you don't wanna be
sending a very large amount of data continuously over very limited bandwidth.
But you want -- always want your data to be fresh.
So, I might have, you know, thousands -- hundreds of thousands, you know, perhaps millions of points, but maybe only a
few of them have been updated recently and so I only want the few that were updated.
And similarly if I make a few edits on my phone, I just wanna send those edits over. The latter is something that
works very naturally with AtomPub and the former is something, you know, we support updated min and show deleted
parameters which basically say, I can say give me everything that's been updated in the last minute and also let me
know about things that were deleted.
And, finally, one advantage of Google Data API is there are client libraries in a variety of languages.
We have some custom libraries specifically for the Maps Data API.
So, in AtomPub, you know, all the world is represented in terms of feeds and entries within those feeds.
And so in the Google Maps API there are two types of feed, what we call maps feed and a features feed.
In maps feed it's a list -- it's essentially a list of all your My Maps.
A map is essentially a collection of features and a feature is some particular element that you put on the map.
So, when I -- you know, if I request from the API My Maps feed, what that's giving me is a list of all the maps I own,
very simple, some metadata, some access to your control information, title, and then the main thing that's of interest
is in the content element of the entry there's a source attribute which is -- references a features feed.
And the features feed lists all of the individual features within that map.
So, it actually lists your maps, you use the maps feed, and to list the content of a map then you load the features
feed.
And the features feed also is fairly straightforward.
There's not much in the way of kind of non-standard AtomPub attributes.
Via the bulk of the information is specified in the content tag of the feature entry and the content is simply -- it's
KML.
So, KML is an open geo spatial consortium standard that was originally written for Google Earth and we don't currently
support all of KML.
We're actually working on supporting all of KML.
Right now, as I said, we basically deal with the subset that you conveniently display in Google Maps.
But we're working on kind of more 3-D geometry for Google Earth and some of the more interesting structure that KML
supports.
So, currently, we support three kind of geometry: line, polygon, and point geometry.
All requests using the Maps Data API currently require authentication.
We need to know who you are to know if you actually have the right to do what it is you're trying to do.
So, for instance, editing a map that you own or that you have rights to edit.
And there are three different choices for how you can do the authentication.
There's AuthSub, OAuth, which is kind of open standard, and then ClientLogin which is appropriate for non-web
applications like Java programs and useful for other purposes as well.
And one just other important bit of useful information if you use ClientLogin it asks you for a service name and the
service name for that is "local."
So, this URL here is -- this is kinda the top-level entry point.
If you send an authenticated request for this URL, this will list all of your My Maps, basically all the maps that you
own, rather created through the API or in the My Maps user interface.
And then from there you can drill down, you get other links that reference individual maps and then features within
maps.
In Google Data APIs we actually use four different HTTP actions. So, in addition to the normal "GET" and "POST"
there's also "PUT" and "DELETE".
So, if you send a "GET" request with this map’s URL this says give me a list of all my maps.
If I do a "POST" to that URL, then that is used to create a map, to add a new map to the feed.
If I do a "PUT" to the URL for a particular entry, so you get an entry URL back whenever you do a “POST,” then you can
use that to edit the metadata of the map, and finally if you wanna delete a map just do an HTTP "DELETE".
And you can also -- among the metadata you can specify the access control specifically whether it's, you know, public
or unlisted.
So, similarly, there's a feature feed.
And, again, we support GET, POST, PUT and DELETE.
GET will list all the features within a map, POST can be used to create a new feature, PUT to edit an existing
feature, and then DELETE to remove a feature.
And we -- in addition to the KML, we support a custom property element which allows you to define custom attributes
for -- and again, as Mano said, there's confusion with XML terminology versus, you know, Google Data terms -- but you
can define custom attributes for your features.
So, here's an example.
So, the interesting thing to note here is that actually most of this is just KML.
So, basically what we're doing is taking a KML placemark and we're wrapping it up in an atom entry.
And so, as I mentioned, anything that is public -- and public is the default -- anything that's public is going to be
potentially searchable, you know, findable, on Google Maps.
And you may not want that for everything.
So, if you want your map not to be indexed you can use a app:draft tag which has to be wrapped up in an app:control to
specify that this is something that's unlisted, that it is not for public consumption.
Now, another important thing is attribution.
Now, as I said, all these requests were authenticated.
Whenever you add -- you create a new map, create a new feature, we know who you are.
Or at least we think we know who you are.
And so by default we always try to attribute any feature that was created to who the user is who uploaded that
feature.
But that might not be correct.
Okay?
Maybe you wanna create a Maps API site, community site for, say, bicycling maps.
So you want everyone to go to your site and upload their bike route and you want everyone to be editing the same data.
Right?
And a logical way to do that is you have a single account and you've got some, you know, server running, some proxy,
that is authenticating all of the users under that account.
Right?
So, the user isn't logging in as herself, you know, the user's logging in as you, basically.
And then -- but you may have your own account management.
You may know something about your users that we don't know.
So, if you want to override the default attribution you can do so and there's a standard way to do that in KML.
KML accepts is atom:author and atom:link tags.
atom:author can be used to specify who the real author of something is and atom:link can be used to specify a web URL
for this particular resource.
'Cause by default we'll just -- if something shows up in search, we'll just, you know, point someone to the My Map
that contains that data displayed in Google Maps but maybe you don't want that.
Maybe you have your own API site to display that data in a more reasonable way using, you know, the custom attributes
that you've defined.
And so you can use these tags to customize that.
Now, the examples, you know, I've shown you we're all HTTP and XML but you don't need to talk HTTP directly.
There are our client libraries in a number of languages.
Right now we have custom libraries in Java, Javascript, and as of yesterday we have Objective-C and other custom
libraries are in the works.
There's also generic libraries that also work.
So, for instance, if you wanna do something in Python on App Engine, of course you can use the Java libraries in App
Engine but if you wanna use
Python there's a generic Python library.
We don't yet have custom Python libraries but the generic ones will work.
And Jeff is gonna be talking about a custom library for PHP that his company wrote.
And finally right now all of the data is expressed in KML.
We do intend to support other formats in the very near future but right now it's just KML.
If you want code to help you parse the KML, we have that also available for download.
There's something called live KML.
The code is written in C++ but there's SWIG bindings for a variety of different languages.
And here's just an example, a very simple kinda stupid program written in java just to show you how the client
libraries work.
So, the first thing we're doing is we're constructing a URL for a particular feed.
This is a feature feed for a particular map.
We're specifying what the name of our service is and then we're using the set user credentials to do a client login,
just manually specifying the user name and password rather than doing something to have the user type that in.
We then get the feed.
Now, all these requests are synchronous.
So, when we get a feed, when we come back with the result, the feed is actually immediately available.
We have Java objects for all those things.
So, then we can immediately go in and it rate over all the entries in the feed.
And so all we're doing here is we're adding a new custom property for each entry.
And just to kinda make this example really simple, all we're doing is defining the custom property to be what we call
annotation property.
It's just something that I made up, and we're setting that up into the title of the entry.
So, then you just call the My Service update.
Again, this is synchronous, so we're gonna have this synchronous operation once per entry.
This isn't gonna be fast.
If you really wanted to do this in practice it would make much more sense to use the batch operations.
And there's information available on pro.google.com, you know, slash I think API/G data that tells you how to use
batch operations.
So, that's it, you know, for right now.
We are furiously working on getting new capabilities added.
There are a lot of things, you know, gaps that we know exist and that we know are important to all of you, and we're
also interested in hearing anything you have to say, any suggestions you have on how to improve this.
So, certainly, we need to do better with search, we're working on -- so, all this stuff is searchable but it's not
right now searchable through the Data API.
We're working on richer content, better integration with the maps Java script API and new kind of feeds are in the
works.
So, that's it.
>> [applause].
>> [whispering]
>> Everyone, I'm Jeff Sambells, director of research and development at We-Create and co-author of PA Google Maps API.
I've been asked to talk a little bit about the Google Maps.API and how we've used -- integrated it into our site and
how it benefits our users and developers.
So, to begin with, We-Create's developed a site called ConnectorLocal.com.
It's a site focused on delivering high-quality, hyper local information.
Let's pull it up here.
Okay.
As you can see here, we've integrated places into our site and ... here are a few places in ConnectorLocal.com around
the Moscone Center that I've added previous to here and there are -- it's all information based on our central
location here at the center.
And we've chosen to integrate Google Maps because it allows our users to easily share their information back and forth
between ConnectorLocal and the Google Maps.
If we take a quick look at the Google Maps page we can easily create a map.
We can quickly create a map.
Let's call it "Google IO -- " and using some of the places that we've already defined in ConnectorLocal, we can pick
from, so, let's say a few hotels in the area and export them to our Google My Maps account.
Now, as we've already discussed, these maps -- these items now become available in my account and if we login, we can
see that -- here we go.
The map is now available and it create -- contains the few places that are -- that I selected previously.
So, this gives our users a great opportunity to take the information that they've assembled in local and share it with
other users who may not be part of the ConnectorLocal system.
So, this also brings me to another point that ConnectorLocal had a problem with how to get all the information in its
site into the search index.
'Cause if you think about it, the search engine has a hard time understanding geographic relevance of the of the
information as its presented through standard web crawler.
Search engine doesn't really have solid location or any underlying desire when it visits the site.
So, we needed to find some solution to take that geographic relevance and submit it to the search engine.
Well, the Maps Data API take -- is perfect for this because we can take all the underlying information, package it up
with geographic relevance, and submit it right to the search engine for indexing.
So, we can also, as well as create -- as well as our users sharing information with local -- with Google Maps, they
can also take their existing Google Maps information -- so, here I've got a few other maps -- and import those right
directly back into ConnectorLocal.
As you see, in my Google Maps area of the site, I have a few maps including the one we just created available for
import.
I'll take the previous map that I've created and import it with just a few simple clicks.
And now a lake -- actually two lakes that were in that map are now added to My Places.
So, this lets me easily retrieve the information from my My Maps account and now includes with my ConnectorLocal
information.
So, if we take a -- flip back.
So, if we take a look at the bit of code that we're using to do this, We-Create has developed a library wrapper for
PHP to access the Google Maps Data API.
It's free to download.
You can download it at the link there and we're working on including it directly in the Zend framework itself.
To -- here we see -- oh, sorry.
All the examples that I'm going to be showing in a moment assume that you've already authenticated with the service
and have substantiated the object.
To authenticate, as we previously discussed, you can use AuthSub or the client login if you already know the user name
and password.
Here is the quick example of retrieving the map feed which lists the existing maps in my Google My Maps account.
So, we just simply substantiated a new query, passed that query into the maps feed, and we can retrieve a nice PHP
formatted object with the ID, title, and summary action resub map.
So, retrieving the attributes in the map are okay but you're probably gonna want a little bit more information, which
is where feature feed comes in.
Again, fairly simple.
Create the new feature query, pass it into the new feature feed, and you can retrieve your features.
But feature feed actually can use a lot of more interesting information in the placemarks.
And the -- our PHP library wraps the KML entries into a nice object format so instead of dealing with the KML itself
and parsing it, you can just simply retrieve it through the object.
So, if we wanted to create a new map, again, very simple.
Create a new map entry, assign it a title and a summary, and insert a map.
When the map's inserted at this point, it becomes part of the my maps account, as you saw earlier, and -- but at this
point it has no features or anything interesting in it besides the title and the summary.
So, you're gonna wanna sad some new features to it.
To add a new feature, you have to start working with those KML placemarks.
So, the placemarks example here, I'm just creating a very point for the
Moscone Center and this is a very simple example that we could extend to include additional points, lines, polygons,
as well as style attributes for things like colors, the line width, icons for this points and all that kinda thing.
So, that's just a quick introduction to the PHP library.
You can feel free to use it and I'll hand the talk back over to Mano and open up for questions.
>> [applause]
>> Thank you.
>> [applause]
Okay.
So, we're gonna open up for questions now if you have any questions come up to the microphones.
We'll go over to Google Moderator where we have ... no questions so far.
Let me refresh that.
So, any questions anybody has?
>> umm, you talked about having polygon support.
Do you have holes in the polygons that are supported?
>> As I said, so, short answer is -- short answer is no.
[Laughing] As I said, we currently are limited to what the My Maps editor supports and we're furiously working on
erasing that limit.
But right now there's no support for multi-boundary polygons.
>> And you mentioned search by locations will be coming.
What sort of searches will be possible?
>> Well, certainly you know, radius and bounding box type searches as well as keyword and attribute search.
>> You're hoping to do a search by arbitrary polygon rather than just bounding box?
>> That was actually searched by arbitrary polygon was the most frequently-requested feature capability that I've
heard, you know, from developers.
And so yeah, that's definitely on our list.
I can't tell you exactly when, you know, I men, certainly probably do release radius and bounding box engine and, you
know, polygon search.
But that's certainly something we'll work on.
>> Thanks.
>> Other questions?
All right.
Normally at this point I would say I would go out and ask you questions but it's late in the day.
Oh, go ahead.
>> So, your talk was about scalability with geo applications.
So, when you talk about storing data in My Maps, what are the scalability limitations?
I mean, can I throw millions of points into My Maps?
You know?
>> Yes.
So, first the good news.
There are no intrinsic limits.
You can have millions of placemarks in a map.
However, we do currently have quota limits and the quota limits – right now the default per user limits are low just
because we don't really know what to expect and we wanna, you know, we don't wanna get an unpleasant prize.
But, if you have specific requirements and you need higher quotas, you know, talk to us and we can easily accommodate
that.
Our intent is not to limit the developers out there, you know, the intent is just to make sure we can provide the
level of service that, you know, we need for as many users as possible.
Now, you may find that certain things, you know, maybe don't perform quite as well when you have a large numbers of
points or small number of points.
We -- There are things, you know -- So, in particular right now, given that the way you can access is feed is load the
feed, maybe kinda page after page.
That's not gonna give you a very good experience for, you know large number of features.
In addition to the search, which certainly addresses part of that, there are other things that we're working on that
unfortunately we're not yet in a position to announce anything about but I think we'll definitely give you a good
experience for large collections.
>> Yes?
>> Everything's done over HTTP; right?
No SSL?
Is there any possibility that'll change?
>> Yeah.
Currently it's all HTTP.
That's something if there's a really compelling need for it, you know, talk to us and, you know, maybe we can add it
to the to-do list.
>> So, the no My Maps for My Domain ready to announce right now?
>> No, no.
Not at this time.
That's certainly something that we're very aware of the need for that.
And it's on our road map.
But we don't have it currently.
So, currently, it's only your normal Google account.
No apps for your My Domain accounts.
It's basically the same limit that, you know, applies to really all --everything under Google Maps right now.
We just don't have that support yet.
But, you know, it's on our road map.
>> Any more questions?
All right.
Well, enjoy the -- enjoy the party tonight and I hope to see you there.
If you have any more questions for us we'll hang around here for probably another ten minutes if anybody's still here.
So.
Great. Thanks a lot, everyone.
>> [applause]