Tip:
Highlight text to annotate it
X
SEAN ASKAY: Hi there.
Thanks for coming out.
My name is Sean Askay, and I'm a developer advocate here at
Google, as well as the tech-lead for KML.
I'm here with Mano Marks today, who's
also a developer advocate.
And we're going to be talking about KML--
high-performance KML, and some other cool things.
So on the screen, this is an embedded Google Earth plugin,
and this is actually a KML Tour that I'm using to animate
some polygons.
We'll talk more about that in a second.
So a quick overview of what we're going to talking about.
I'll give a very brief intro to what KML is, then I'll
start talking about data visualization using KML.
And then Mano will take over and talk about developer
environments for KML authoring.
And then KML rendering and maps API and using KML with
Fusion Tables.
So a really brief intro to KML.
Keyhole Markup Language was developed at Keyhole before
the company was acquired by Google.
It's basically a data language that represents spacial data
and styling.
Kind of loosely like HTML and CSS is to the web.
KMLs can be static files that you can serve off of your
server or run locally on your machine.
It can also be generated dynamically via web services
and served to Google Earth and Maps.
Google gave KML to the Open Geospacial Consortium in 2008.
It's now an open standard used by Google's Geo Tools and a
bunch of other third-party tools as well.
And at last count, there's well over a billion KML files
out there on the internet.
They're not all necessarily interesting.
Unfortunately, most of the ones out there look like this.
Basically, this is my house.
So here's the KML for a very simple placemark, rocket ship,
description "goodbye world" and some coordinates.
And this is what it looks like in Google Earth.
I want to talk about a lot more exciting things than just
point placemarks, specifically data visualization.
I'm going to speak to thematic mapping--
how to take data and visualize it on the globe.
And then also talk about things like GPS data and
tracking objects through time and space.
So in a little more detail, I'll be talking about 3D
extruded polygons, using a new KML tag called altitude
offset, which makes it a lot easier to create these
three-dimensional polygons.
Then we'll talk about animating those polygons with
Google Earth Tours.
And then I'll switch to the objects in motion GPS stuff,
and talk a little bit about gx tracks and then finally talk
about bringing in a real-time data feed to update GPS tracks
on a client.
The basic things here are interesting new ways of
visualizing data, and then how to keep it updated and fresh,
and then how to animate it.
So thematic mapping is basically taking information
with a geographic context, like Census population data or
demographics, and then visualizing it on a map.
So here we have two examples.
One is showing some 3D spheres using 3D sketchup models that
are scaled in proportion to some data value, and the other
one here are these 3D extruded polygons, which I'll be
talking about first.
So basically before we introduced the gx altitude
offset tag, you had to specify an altitude for every single
for vertex in the polygon, which is kind of redundant.
It wastes a lot of space and makes it very difficult to do
animations and updates on those features.
Now with the altitude offset tag, altitude is globally set
for the entire feature.
So here's a little code to show you what a placemark with
a polygon looks like.
This is way we used to do it, where you had the altitude
values after the longitude and latitude for
every single vertex.
Now we basically can specify, like I said, altitude offset
at a global level, and that cascades down to all of the
placemarks underneath.
So I'm going to give you a little demo of what you can do
with these types of animations.
And the question here is what can you do with Google Earth?
I basically spent the weekend digging through Census
records, American Community Survey records, state and
county polygon maps, and then used Fusion Tables, Google
Refine, Google Charts API, Python, using a
library called pyKML.
And a weekend I would rather spend outside to
do some cool stuff.
So we're going to essentially show you some live demos that
look a little bit like this.
So here's Google Earth.
I'm going to load the KML that I made.
It's enormous.
It's about 40 megabytes uncompressed, because there's
so much data.
This is pretty simple.
Mouse over.
You can see polygons for each state.
As you zoom in, we fade to county borders, so I can mouse
over and get each of the county names.
Zoom in further and then those will fade out and I'm left
with these white lines undermarking the
edges of the counties.
So this isn't all that interesting by itself, but I
can use a Google Earth Tour to do some animations with it.
A Google Earth Tour is basically a set of camera
flight pads and animations that alter the content.
So I'm going to start off one of these.
The first data set we're going to look at are the percentage
of kids in each state that are lacking health care, health
insurance, from 1987 to 2009.
And as you can see, these are all moving around.
I can pause the tour.
When I mouse over it, I now have the name of the state,
and it's a little hard to read, but the percentage of
kids in that state for that year that
don't have health insurance.
I can click on it, and then using the Charts API, I'm
rendering this out over time.
So here we're looking at 2003 and the value is 19.4.
I can hit play and we'll continue with the tour.
I can pause it, I can play with the time slider, drag it
back and forth to any particular date and then zoom
around and check things out.
And I'll note that Massachusetts is the best
state in the nation for health care for kids, so go
Massachusetts.
It'd be interesting to do a mash-up with the red and blue
states on this as well, I kind of wonder
if you'd see anything.
So that's this tour.
Let's take a look at another one.
We're going to look at percentage of houses that are
lacking complete indoor plumbing.
Going back to the 1940s, a lot of people in the states didn't
have indoor plumbing.
Here, Texas has 62% of the households
without household plumbing.
I hit play.
And then each year, as you might imagine, that drops.
Alaska popped up in the background because we didn't
have data for Alaska in 1940.
And then we finish in 1990, where almost the entire
country now has indoor plumbing.
And then there's the graph.
One last data set I'll show is looking at population data on
a county level.
So I'm going to zoom in to California and I'm going to
hit play on that.
This is the biggest tour.
There's a lot of polygons, so my little laptop has trouble
with this sometimes.
I also decided to take out the smooth transitions with the
extruded polygons and just snap them to different
altitudes, which helps improve in performance.
So again, surprise, surprise, Los Angeles is growing like
crazy, and you can also see the Bay Area
picking up here as well.
I can zoom out, I can pick one, check out
the data for it.
There's LA.
Or fly anywhere else in the country and check
out the data there.
Whoops.
Let's go to Chicago.
So one of the interesting things I noticed about this
data set with Chicago was maybe suburban
sprawl popping up.
So I'm going to restart this animation.
This is Cook County, I believe, which is where
Chicago is.
And this will come online.
So as you imagine, Chicago, a big city, lots of people.
It keeps going up and up and up and up.
But I think in the '60s and '70s it actually starts to
drop a little bit.
And you'll notice that as it's dropping, these other counties
around it are starting to pick up.
So I'm not an expert in the region, but this might be an
example of suburban sprawl.
So maybe you can see with a data set like this when you're
viewing it in three-dimensional space.
So let's turn this off and head back to talk about how
this is done.
So we basically want to animate a polygon in the
context of a tour using the animate update tag.
So here's a very simple placemark.
We specify a polygon.
There's that altitude offset and a bunch of coordinates
which I'm not showing you.
And elsewhere in the same file I have a KML Tour, which
defines these animations and these camera motions.
And here you can see, over the course of three seconds, we're
going to change that altitude--
well, to 1,000.
That should be 100.
So what you'll see in the next slide is--
that was actually supposed to be 10,000--
that the polygon now gets raised higher.
We add an extra zero here, and off we go.
So this is basically how you would do an animated update to
extrude that polygon to a different altitude.
You can do more than just extruding polygons and making
them taller.
You can actually interplay between any values in KML.
So let's check out another demo.
So this is just kind of a visual--
no particular data attached to it.
But it's kind of cool-looking.
We're going to fly in, and here we have these circle
polygons that are expanding in time.
So the original polygon is a small circle, and then I'm
saying over three seconds, changed to these coordinates,
which are a bigger set of coordinates, a bigger ring.
So that's going to basically make these
animate and expand out.
And again, this time, you notice the camera was moving
with the tour because I have recorded a flight
path with it as well.
All right?
Another way of doing somatic maps-- and I'm going to rush
through this a little bit so we can
get to the GPS session--
is to use 3D sketchup models instead.
So here's sketchup.
We've got a model of a cell phone.
This screenshot comes from thematicmapping.org, an
awesome website.
They have an API for creating thematic maps, although the
animations aren't done quite the same way
as I'm showing here.
Basically you have a placemark.
You specify the location, the scale, and the model file.
Just like with the previous example,
here's my original model.
I can bring in that KML Tour, and I can say, hey, scale, I
want to extrude you.
I want to make you bigger in the y-dimension
by a factor of 10.
So our new cell phone gets a lot bigger.
The value here changes to 1,000, and off we go.
So the next thing I'm going to talk about is GPS-type data
and what you can do with that in Google Earth.
So let's do a couple quick demos to show you what that
looks like.
I'm going to load some data.
So the entire Geo Team at Google took an off-site field
trip not too long ago.
We all went to Lake Tahoe and we all went skiing.
And we had a bunch of people run around with GPS units,
which was pretty cool.
Which means that I can drag the time slider, and you can
see all kinds of Googlers running around the slopes,
skiing, snowboarding, et cetera.
In addition to manipulating the time slider manually, I
have a tour that will do it for me.
And it'll do a camera path and it'll do a nice advancement of
the times slider so we can get a visualization here.
So this is me on a dogsled ride.
So I'll fast-forward through a bit of this and then you can
watch everybody going up the ski slopes
and then skiing down.
One other example of this is taking a 3D model and actually
showing that in the context of a GPS track.
So a couple of years back, I made a tour for the Apollo 11
landing on the moon.
And now is when I regret--
OK.
The internet is fine.
I was worried there for a second.
I created a tour that basically shows the path of
the Apollo 11 lander coming in to land on the moon.
Let's turn off some other layers here, keep the imagery,
keep the terrain.
So back then, we didn't have this GX GPS track feature.
So I basically had to create animated updates to move that
model segment-by-segment along the path.
Now, fortunately, I don't have to do that.
I can actually just drag the time slider if we know when
and where that model was.
We'll zoom out a little bit, like that, and you
can bring it in.
So I can make a tour animating the lander a lot easier now
just using this GX track feature.
So let's talk about how that's done.
The way this used to be done is people would basically take
a bunch of placemarks or a bunch of lines, they put a
time stamp or a time span feature on it, and you would
play with the time slider.
And you're essentially duplicating this same object
over and over and over and over again to animate it.
Now we have a single placemark, a single feature
through time and space.
It's the GX tag we'll show in a second.
This currently only works in Google Earth 5.2.
So you're not going to be able to do this in Google Maps--
obviously, you can't do 3D stuff or tours in Maps either.
As I said, you can use 2D models or 3D models, and as
I'll talk about in a second, you can add extended data,
additional attribute data, correlated to the time and the
path of the object.
Like if you're riding a bike, heartbeat, or if you're
driving car, RPMs.
So basically the way this looks in the KML-- it's a set
of parallel arrays.
You've got a bunch of when statements that define time
stamps for each segment along the path.
You've got coordinates that say where you
were at that time.
And if you're using a 3D model, you specify the
different rotations of that model, the
orientation of that model.
This can be a little hard to author because it's a parallel
array, and if you're writing code, it'd be nice to kind of
iterate through each different time step.
So as long as you don't tell the Schema Monster, you can
basically interleave these.
As one schema validates, but Google Earth will read it just
fine, and if you save it back out, it will put everything in
its proper order.
So let's take a look at a little bit of
demo, another demo.
Looking at a bike track of a coworker who took heartbeat
data along the way.
So we're going to switch back to Google Earth.
Go, internet.
All right.
And then I'm going to load the bike track.
We're going to fly down here.
So Peter's in the room, actually.
This is his track.
And you'll see that I can click anywhere along the track
and get his heart rate at that particular point.
I can also right click on the track and
show elevation profile.
This will basically show a graph of his speed, the
altitude at the time, and his heart rate, in this case, as
an additional data set.
So here is his heart rate during the course of the trip.
So let's look at how you do that in KML.
So again, this part is the same.
A bunch of when and cord statements defining when and
where the person was, or the object was.
Then you're using the extended data tag and you're specifying
a simple array called heart rate, and another parallel
array that goes and correlates with each of these.
So this is what allows you to basically take any variable
you want and sync it up with the GPS track.
So that's kind of cool, but I want to show
something even cooler.
Which is what if you wanted to stream in real-time data?
Have a data feed come in and basically push the locations
of an object to the client.
So let's take a look at that.
So I was in Kenya some time back and I had the luck of
going in a Cessna with an old, salty pilot, who took us on
this kind of crazy tour around Mount Kenya,
which is north of Nairobi.
So what's happening here is I'm fetching each segment of
this track a piece at a time.
So the initial file only had the initial little piece that
you saw, and each additional network fetch that I make, I
am grabbing additional data, injecting it into the track.
So doing something like this, you could basically pull in
real-time feeds of Google latitude data.
If you have any other devices that are streaming a location,
you could visualize it like this, a segment at a time, and
push out the real-time locations, and the track in
between now and the last update.
So we're going to land here in a second, and then I'll show
you guys how this is done in the KML.
So conceptually what's happening here is we have two
network links.
A network link is a KML feature that basically fetches
from a URL to KML.
So the first network link fetches an initial file that
just contains maybe the first little segment, maybe up to
the current location of the object.
Then there's a second network link that hits the server and
says, well, give me any updates that have happened
since I last checked in with you.
So here you've got Google Earth, here's
your initial request--
this can either be static files, which is what I showed
you a second ago, or it could be a live web service.
And then the update's going to come through that second
connection to your web service.
So here is kind of a zoom of that left panel that I was
showing you a second ago.
Here's the network link to the original file.
That fetched the initial track and then I have underneath it
a second network link that fetches the updates.
So this is how it would look.
This is how you'd make it.
Here's your placemark.
And instead of using a regular track, I'm going to use a
multitrack.
Since GPS data tends to be segmented--
you turn your GPS on or off--
and you want to maybe visualize your entire trip,
you can actually combine multiple tracks into a single
placemark feature.
So I've got a single multitrack here, with the
first segment of data, Sean T1.
And I should mention that we grabbed that from maybe
GPS.py, which is our initial file fetcher,
first network link.
Then I hit web slash feed.py, which gives the updates.
And that's what this looks like.
This is using what's called a network link control.
It's another feature of KML.
It basically says, hey, update this item.
It's a little similar to the animated update
you guys saw before.
This is actually a precursor to Tours.
This was just basically created to basically stream
content to a client and then change it on
the fly like this.
The other thing that we do here is we send with this
second file a cookie, which is appended onto the end of the
URL, which says, hey, this is the last time I got data.
I've been giving you data up to this point.
And you'll see how that's used in a second.
So what's going to happen is this track is going to get
bumped up over here, so now we have track number two, we can
see our track was updated.
That last parameter was appended to the feed URL such
that the next time you fetch, your server can say, hey, OK,
I know that he had everything up through this date, so now
I'm going to update him with everything through this date
and give him a new track that contains all
that additional data.
So anyway, in summary, here's what we talked about.
A little bit about thematic mapping and using these 3D
extruded polygons with the altitude offset tag, which
makes it a lot easier to author the content, and also
allows us to make these time animations using Google Earth
Tours using the animated update tag.
And then I just finished the section on objects in motion--
looking at GS track as a feature to look in GPS data,
and then how to use the updates tag with the network
link control to basically push new data into that track.
So I just launched a new blog today at unchartable.com, and
I'm going to start talking about KML techniques like this
in the future.
And with that, I'm going to hand it over to Mano.
MANO MARKS: Thanks, Sean.
Hi.
Am I on?
I'm on.
OK.
Hey.
Last session of the day, pretty exciting.
I hope you all are having a great day today.
Sean dared me to make this joke.
The Android people are giving out tablets and the Geo people
are giving out free maps.
So.
Yeah.
All right.
Some of you laughed at any rate.
OK, so Sean and I are developer advocates, which
means this is our job, right?
A big part of our job is to go out and talk to developers
about actually doing code and the process of doing that.
And we find that a lot of developers ask us specific
questions about developer environments.
Like what are the kinds of things that you use to
actually do your coding?
So I'm going to toss a whole bunch of ideas and things that
Sean and I do at you, but mostly, again, as all coding
is, it's really going to be questions of personal
preference.
There is no right single development environment for
creating KML.
So the things that I'm going to talk about briefly are
editors, validators, particular programming
languages, and also mention some open-source libraries
that might be really useful for you.
So particularly for the programming editor, this is
something of a personal choice.
Generally, your options are some sort of integrated
development environment or just basic text editors.
And I'm particularly fond of vi, and of course Sean is
particularly fond of Emacs.
So we have the classic, older hacker kind of conflict, even
though he's a lot younger than I am.
And some different ideas of the different things.
They one place that we come together is on Notepad++, it's
a nice Windows environment.
We've got some nice scripts dialing and
some basic text editing.
And if somebody could turn off their phone ringer, thank you.
And then, of course, some people do prefer Eclipse or
Visual Studios, which has some integrated XML editing
environments.
Personally, I just go with the classic VI because it's pretty
much everywhere.
Sorry, that's a little dig.
Anyway so XML validators.
So XML is a document format, right?
And the scale of things that we're talking about here,
you're not really hand-editing KML anymore, right?
High-performance KML, you're generating this KML
programmatically But there are times when you want to check
whether it's a valid output and you want to actually do
that by hand.
And I'm particularly fond of Oxygen, which is a nice
cross-platform Java-based validator.
XMLSpy is something a lot of people are fond of.
jEdit is something that Sean is fond of, and of course,
it's actually, I believe, free.
And Notepad++ has some basic validation stuff built in.
But, of course, you can also directly validate using a
number of different libraries, the classic being libXML.
And then a bunch of language-specific ones.
And then there's some KML-specific specific
libraries that helpful. pyKML, as Sean mentioned, and LibKML.
And then for programming languages, I think Sean and I
are both most fond of Python as a language for doing this
kind of coding.
Easy to get started on your scripting.
And it's got support for libraries like LibKML, pyKML,
GDAL, OGR, those sort of things.
And a couple things that you need to take into
consideration when you're thinking about what
programming languages that you're working on, is think
about what your production environment's going to
actually look like.
So many of you are going to be very comfortable on your
laptop or in your desktop doing some coding in whatever
scripting language you want to be doing.
You've got your Rubys on Rails environment,
or blah, blah, blah.
Whatever your particular kind of thing that you've got, but
you have to think about how that's going to translate into
a hosted environment, how it's going to translate it if
you're going to be pushing that out somebody.
So it's often good to sort of start from that
as a starting location.
Things to think about that might not occur to you right
away are things like Google App Management doesn't
currently allow you to support C++ libraries, anything but
pure Python or Java.
So those are the kind of decisions you're going to need
to look at before you actually get started when you're
creating a large-scale application.
And if you're, for instance, say, pulling from a database
certain programming languages has had better integration
with different databases, so the classics being PHP and
MySQL are pretty closely linked.
There's tons of code that help you pull that data out there.
And if you're doing something like interacting with the data
API, like Fusion Tables, what are the client libraries that
you'll need?
OK.
And just to give a quick call-out out to pyKML.
You may be familiar with LibKML, which was actually
produced by Google engineers and is used in some production
environments within Google.
pyKML is a bit lighter-weight.
It supports primarily the core elements of KML and it's
written in Python, so it's got a very Pythonic interface.
So I just wanted to show you this as an example here.
This is a pretty simple way of creating KML documents, which
is one of those core container elements for KML, adding in
Atom and putting in the links that you're preserving,
attribution, and then creating a placemark.
You may recognize 0, 0 as Null Island in the old Myst game.
It's also where a lot of KML with poorly-configured
latitude and longitude ends up automatically--
this spot off the west coast of Africa.
So if you're always wondering why there's this big cluster
of things--
it like, anything that Google Earth doesn't actually know
how to place, it's going to either place it there or
entirely off-screen.
So I like to use that in my examples.
OK.
So that's just a simple pyKML example.
So I want to switch gears here and talk about the Maps API
because Maps actually deals with KML in a
very different way.
I'm going to start with showing you some
capabilities here.
So this is a USGS KML file overlaid onto a Google Maps
API application.
And you'll see that the earthquakes are styled
different colors based on their intensity.
And I can click here and you'll see to the right here,
I've got the actual data there from the placemark that I
clicked on.
Now, you may notice that it's not actually pulling it into
an info window, and that's because I've done some code to
prevent it from doing that.
So I just wanted to show you this to demonstrate that you
can do something a bit interesting, which is you can
actually load it in as a clickable raster overlay.
So how many of you were in the Fusion Tables talk earlier?
OK.
All of you.
Awesome.
This is like the Geo diehards here, right?
OK.
So in that talk, James McGill described how Fusion Tables
will render all your placemarks into basically 40
tiles and place them onto a map.
Well, KML goes through a very similar renderer.
Basically these are all rendered as a clickable raster
overlay to increase performance.
So you can put in quite a bit more placemarks in KML than
you can if you were loading this up using--
you were creating a Javascript objects.
And it's created using this clickable raster overlay.
But once you click on it, you actually actively get data out
of it that can be captured and then manipulated and used.
OK.
So people often ask me about this process and how it works.
You basically create this KML layer object, and I'm going to
show you the actual code for this in a minute, but this is
the particular process.
Place the KML file on a server.
You create this KML layer object in your Maps API
application, and then the Maps API let's Google servers know
where that is.
Google servers go out, fetch the KML file, and render it
into this right-clickable raster overlay, which they
pass back to your Maps API application.
So this is why--
and the question people always ask me is, why can't I put
this KML file on my computer?
Or why can't I put a password into this to prevent other
people from getting access to it?
It's because you can't pass that password onto Google
server to let it know.
It has to actually go out, fetch the KML, render it, and
then pass it back.
So any KML object used in the Maps API must be rendered onto
a public server.
OK.
I want to go back to the limitations in a second, but I
wanted to show you the actual code, since I actually
talked about it.
It's very simple.
Here you've got this KML layer you just
created, pass it the URL.
Here, I'm passing options to it and here I have the
suppressed info window, it's true, and I set it to the map.
And this should actually have my options in there.
It looks like that got left out.
And then here, I'm adding an event listener to the KML
layer on the click that take the texts
from the KML feature.
So when I click on it, it is able to capture that future
data, get the description, and then it shoves it into a DIV.
So that's just a very simple explanation of what was
happening before and why it wasn't showing up as an info
window, it's showing up in the side.
So let me talk about some the limitations here for
using the Maps API.
So as Sean mentioned, we don't support full KML in
the Google Maps API.
And the reason for this kind of two-fold, here.
One is, it's 2D environment, right?
You don't have a way of representing a 3D model, you
don't have a way of
representing elevation directly--
there's a lot of different things that you don't have.
And the other is that this process of having the server
load the file and then send it back to the browser means that
you've got lots of interaction between servers and clients
and stuff going on.
So there's very big performance considerations.
So we have a relatively small file size for geographic data.
That 10 megabytes, maximum.
And a limitation in the particular KML
that's actually supported.
And in this case, it's primarily the geometry data.
We don't support very many of the extensions
that Google has added.
So the GX tours, and the tracks, and all those things
that Sean was really excited about because they're
incredibly powerful visualization tools, we don't
support those in Maps just because of these limitations.
And also for security reasons and because we're passing this
off to a Javascript application that may be
sitting on a different server-- so you noticed that
file that I actually loaded, the USGS file, was actually
loaded directly from the USGS.com.
So since it's being loaded from a different site, we have
to actually be careful about cross-site scripting and all
that sort of thing.
So it'll scrape out Javascript and Flash that's in the
description balloons.
So these are some of the kind of considerations that you'll
need to think about when you're creating KML for the
Google Maps API.
And of course, it has to be on a public
server with no password.
By the way, that scraping out the Javascript and Flash, you
can put that back in by capturing the click events and
creating a new info window, if you want.
OK.
So those are the major things I wanted to talk about
for the Maps API.
So things to be thinking about in these considerations is--
the primary thing is, think about producing separate KML
that's optimized for Maps when you are producing KML.
You have a set of data that's highly optimized for Earth and
a set of data that's highly optimized for Maps.
And you can do this dynamically, depending on the
client that's querying it.
You can spend parameters to your network links or to
whatever that are loading the data to change them if it's a
Maps API application.
OK.
So most of you were in the Fusion Tables talk, so I'm not
going to actually go as deep into this as I was going to
because it doesn't seem like it would help to repeat it.
But I just want to talk about some basic things that you can
do with Fusion Tables.
So that these are captured.
And anybody who's watching the video, take a look at the
Fusion Tables talk, as well.
So this is a simple Maps API app that I wrote with a very
simple Fusion Table.
I was a historian in a former life.
And the idea here is that the boundaries of Poland have
changed pretty dramatically over the years, and so I just
wrote one that captured that and rendered these on a map.
So you'll see here in 1492, these where the
boundaries of Poland.
In 1650, that was where the boundaries of Poland--
In 1815, it actually goes away when Prussia and
Russia split Poland.
And I believe Austria actually took a piece of it.
And in 1920 these are the boundaries.
And 1945, you see they're the current boundaries there.
So the things to note about this is this is all done with
KML that is loaded into Fusion Tables.
And what Fusion Tables does, as you know from the previous
talk, you load up tabular data and it pushes it into Fusion
Tables, and then you just click on visualize map
and you get a map.
So the point here, though, is Fusion Tables
supports KML in here.
So when you're creating KML and you're uploading it to
Fusion Tables, things to be aware of, that it's a smaller
subset of KML than even the Maps API supports.
It's basically just the geometries.
So what it does is it takes the KML file and it strips out
all of the styling that you've done in your KML.
So any styling that you're producing, you don't bother
with it to create it.
And it just strips out the geometries and then it takes a
look at the extended data elements.
Extended data is where you can create basically name-value
pairs of data for your KML features.
So it then takes those extended data and turns that
into columns.
So things that you had in the description and the name I
think are also transferred, and then
nothing else comes along.
So that includes things like time stamp
and time span elements.
OK.
So the integration with the Maps API, as you will know
from the previous session, is essentially one line of code.
You can do additional things, as we've announced today, in
styling these layers as they come through.
And this is, again, just a summary of some of the things
to do with our KML support.
Again, itr renders this clickable raster, much like
the KML layer does, and you can upload files up to 100
megabytes in a single file into Fusion Tables--
although a single table can actually be much larger.
You can programmatically add data to files to get it up to
250 megabytes.
That's for a single Gmail account.
So this is your basic code sample for integrating with
the Maps API.
Here we've got a Fusion Table layers, object, you pass in a
table ID, and then you can optionally add in a query.
And this is from this Poland demo that I just showed you.
Select geometry from table ID where year equals year, and
set the Layer 2 amount.
OK, so that's all we have on that right now.
We are happy that you all are here and we'd really like to
take some questions.
We would ask that if you have a question that you come up to
one of the mics so that the questions can be recorded.
SEAN ASKAY: And a couple other things as well.
MANO MARKS: I guess we can both be on.
SEAN ASKAY: Apologies to Mano.
I screwed up you sample.
I was converting all our slides to HTML5 this morning
and I got a bad copy-paste.
MANO MARKS: No worries.
SEAN ASKAY: If you guys have feedback about this talk, we'd
love to hear it at SpeakerMeter.
The URL's down there.
Tell us how bad or well we did.
And questions?
AUDIENCE: Our organization's running Esri, and they have a
lot of jurisdictional data.
It's highly accurate, it's very up to date.
When I get a supervisorial district KML file that they're
going to generate off a shapefile, it's huge.
Do you have any way of simplifying it to make it a
smaller KML?
Shrink it a bit?
MANO MARKS: Yeah.
So there's a number of techniques that you can use.
AUDIENCE: A mechanism?
Yeah.
MANO MARKS: The classic one to use is regenation.
Regenation basically breaks down your file into simpler--
say you're dealing with polygons.
It'd be a simpler polygon when viewed from a distance, and
more complex polygons for portions of your
data at lower points.
SEAN ASKAY: You might look at Fusion Tables, if you didn't
already attend that talk.
If you do convert your shapefile to KML, you can put
up to a million characters in each cell in Fusion Tables.
So as long as one polygon doesn't have more than a
million characters for the geometry, toss them in Fusion
Tables, and we actually do quite well with really large
geometries, really fine detail.
The other thing is, do you really need all that
detail in the KML?
AUDIENCE: Probably not.
SEAN ASKAY: In which case, I would recommend using Esri
software that you have already.
There are polygon simplification tools in ArcGIS
that will simplify those polygons down and make them a
lot easier to manage and deal with in Google Earth.
AUDIENCE: Thank you.
MANO MARKS: So one additional point on that is actually Josh
[? Litmey, ?]
who's in the audience, wrote an application called Shape
Escape, which allows you to upload a shapefile directly to
Fusion Tables.
It decomposes it, puts all the features, and posts them using
the Fusion Tables API into Fusion Tables, and it will
simplify any KML that's too complex.
It'll simplify polygons that have too many vertices.
SEAN ASKAY: Next question.
AUDIENCE: Yeah.
A client asked me this question, and I hope I gave
them the right answer.
If you go ahead and load KML into Google Maps like that,
that URL I pass you, does that end up in the Google search
engine anywhere?
In other words, could that data then be found elsewhere?
MANO MARKS: So I don't--
SEAN ASKAY: Are you going to repeat the question?
MANO MARKS: So the question is if you create a KML layer
using a Maps API application, does that URL then
get passed on to--
AUDIENCE: Elsewhere in Google, yeah.
MANO MARKS: --To our web search to or Map search to
allow it to be found in some other spot?
No.
SEAN ASKAY: Yeah.
Not that I'm aware of.
I'd be shocked if it did.
So.
AUDIENCE: That's what I told him.
That's the best we're going to do is--
we'd all be surprised.
MANO MARKS: Does he want it to be?
Was it [INTERPOSING VOICES]?
AUDIENCE: No, no, no.
That's the point.
You can't put in a password, but I told him nobody's ever
going to find it.
MANO MARKS: Yeah.
The other thing you might do if you're really worried about
it is put in site map that specifies don't call the
particular directory that KML comes from.
SEAN ASKAY: I guess it all depends on how you're passing
the URL on, as well.
Because if you're doing that client-side on Javascript,
someone could look at your page, like you say, and
actually fish for the URLs.
But if it's server-side or something, or if you're
obscuring the way that URLs pass, you'll be fine.
MANO MARKS: If you're really concerned, you use Maps API
Premiere upload it to Fusion Tables, and use the private
Fusion Table option for Premiere that allow you to
keep your table private, but still share it with the rest
of the world.
AUDIENCE: OK.
Thanks.
AUDIENCE: I had two questions.
First, when the last I looked, I could not find a reasonable
pure Java API for writing KML.
I saw a number of JNI APIs but those are harder to deploy and
harder to work with.
Oh, you're on Linux, I'm on Windows.
Blah, blah, blah.
Is there a good pure Java way to make KML?
MANO MARKS: Not to my knowledge.
SEAN ASKAY: I'm not a Java guy, so not to
my knowledge, no.
Unfortunately.
MANO MARKS: You might be able to do something with--
essentially, KML is XML, right?
So using the built-in libraries to do it, you could
actually just [INTERPOSING VOICES].
AUDIENCE: I could write a Java [INTERPOSING VOICES]
in KML.
MANO MARKS: Exactly.
And then you could post it to Google Code Hosting, so that
everybody could use it.
AUDIENCE: But how would I get paid to do that?
MANO MARKS: And I think there's a couple of people
waving their hands who have some ideas--
AUDIENCE: Oh, you'll pay me to do that.
MANO MARKS: --About that.
So.
And if they could come up--
yeah.
It shouldn't be that hard, but at least one person may be
coming up to the mic to announce one later.
So [INTERPOSING VOICES].
SEAN ASKAY: To repeat that question, it was is there a
pure Javascript library for creating KML.
MANO MARKS: Not Javascript.
SEAN ASKAY: Java.
LibKML, C++, but you could probably do SWIG bindings to
Java, but that's not made of Java.
MANO MARKS: And it it poses cross-platform problems
because the SWIG bindings for Windows don't work very well--
SEAN ASKAY: At least when Py came out, that I was showing
earlier with Python, that's just an extension of LibXML,
C++ as well, so.
Nevermind.
MANO MARKS: A pure Java solution might be really
useful, for instance, in a Java version of app engine.
AUDIENCE: My other question is when I'm doing development on
my personal box behind a firewall, is there a DEV mode
or something?
Where I could say, I've got some KML.
I just want to post it to a place and then
bring it right back.
Where I don't have to set up a Sandbox and publish it on a
Sandbox with an URL.
I have the KML in memory in Javascript.
Could somebody do something with it?
MANO MARKS: You mean for Maps API?
AUDIENCE: Yes, for Maps API.
MANO MARKS: So the question is is there a way to load KML
into a development environment on your personal laptop or
desktop or whatever without having to post it to an
environment so that the Google servers come and get it?
No.
AUDIENCE: Too bad.
MANO MARKS: No, there's not.
SEAN ASKAY: Google has to come and get it, so if you can't
hit a server on your laptop--
MANO MARKS: That was the point of the diagram
[INTERPOSING VOICES]--
AUDIENCE: DEV would even--
I would even send it to--
the Maps tiles don't load if I'm not online.
I can be online.
What I want to do is be able to post it to Google directly
and then have Google just send it right back to me as tiles,
rather than putting it up in a place and then waiting for you
to come get it.
That's harder for my firewall.
MANO MARKS: If you want do that, you could use something
like Google Storage for Developers or Google Code
Hosting to upload it there and then grab the files off of
that using the KML layer.
AUDIENCE: Thank you.
MANO MARKS: So certainly you could do that.
AUDIENCE: Puncha a hole in the router.
MANO MARKS: I'm sorry?
AUDIENCE: Punch a hole in your router so it can see
[INAUDIBLE].
AUDIENCE: Yes, punching a hole in my router is what I don't
want to do.
MANO MARKS: Yeah.
I never recommend punching in a hole in your router so that
Google servers can come in and and look at it.
Yes.
AUDIENCE: Well I was just going to say that I've
marshaled from a future collection in Geo Tools into
and out of a KML.
So I think that's possible still.
My question was about an element in KML that would
allow me to take a georeferenced image that I
already have, like say a historical map.
I know the bounding box for it, and just bring it up in
Google Earth.
Is that possible?
MANO MARKS: Mmm hmm.
SEAN ASKAY: There are a couple different ways of doing it.
If you have a georeference file, like a GeoTIFF.
If you have Google Earth Pro or Google Earth Enterprise,
that'll directly import.
It'll convert it to a jpeg and then display it for you.
There are also some regenatioN options with that, if you have
really high resolution rasters.
But there are a lot of free tools, as well.
Goodle, or gDial, depending on how we'd say it, is another
open-source library that will tile stuff for you.
There's a tool called gDial to Tiles.
It's Python-based and it will convert it.
There's also MapTiler.
If you go to Maptiler.org, it's a desktop app that will
take georeferenced images and generate KML for it.
But not natively in KML.
There's no way to say, here's my random raster proprietary
format, bring it in.
You actually have to do a conversion
process to native KML.
AUDIENCE: To native KML.
But it will reference an image file, like a gif or something,
and then there will be bounding box
coordinates on it?
SEAN ASKAY: Yep.
Absolutely.
MANO MARKS: If you know the bounding box and it's not a
super large file, you can just load it using a ground overlay
element so that the core element is ground overlay.
That's the thing that you're looking for.
Large files, you need to do some
regionation and tiling for.
SEAN ASKAY: You can talk to us after and we can
[INTERPOSING VOICES].
MANO MARKS: And there's an article on the KML
documentation [INAUDIBLE].
AUDIENCE: OK, cool.
Thanks.
AUDIENCE: I was just going to answer the earlier question.
There is an API called Java API for KML, or JAK, J-A-K.
And it's hosted on Google Code.
It's kind of an early version, but I've been using it for
about a year.
It has a few quarks but it does the job.
MANO MARKS: That's great.
Java API for KML or JAK--
SEAN ASKAY: Hosted on Google Code.
MANO MARKS: --And hosted on Google Code.
By the way, Sean and I go to a lot of scientific
conferences as well.
There is a Fortran library for creating KML.
Whatever language you're going to ask about, there probably
will be something out there.
I'm not advocating Fortran as a solution, but they say
there's lots of math libraries out there for it.
Yes.
AUDIENCE: For the offset of polygons, now it's altogether.
Can we go back to have the regular one with points on
demand when we need it?
If we have slopes on the polygons?
Different nodes have different elevations?
SEAN ASKAY: Sure.
So if you put different elevations at each individual
coordinate, the altitude offset would just kind of
overwrite those.
It doesn't physically overwrite them, it just
ignores them.
So if you were to just remove that altitude offset, then all
that altitude data would still be preserved in
the original polygon.
So.
MANO MARKS: Doesn't the altitude or offset simply add
the altitude to each of the vertices?
SEAN ASKAY: No.
I thought it--
well.
I think it just overides it, but--
MANO MARKS: Hmm.
There seems to be some--
SEAN ASKAY: I can find out for you.
AUDIENCE: OK.
So another one is if I have a [UNINTELLIGIBLE]
shapefile with z elevation for each node.
So is there a way to bring those automatically with what
the elevation-- what the z value for each one of them?
Is there something out there that export
[INTERPOSING VOICES]?
MANO MARKS: If you convert a shapefile directly to KML
using, as Sean says, Goodle, as I say [?
G-D-A-L and as other people say gDial, there's an
open-source set of libraries that you can use, just a
command line, to do the conversion, or you can do it
in Google Earth Pro.
So, yes.
And that will bring along [INTERPOSING VOICES].
AUDIENCE: So Google Earth Pro, when you import with it, it
brings in also the elevation value, right?
For each node?
MANO MARKS: Yes.
SEAN ASKAY: It should, yeah.
And the question was, just to repeat, if you have z data
values in your shapefile, altitude values,
will those be converted?
And yeah, there are also extensions for ArcGIS, like
Arc2Earth, that will do export and they
may preserve z values.
So I look at some of those converters as options.
MANO MARKS: And if you're interested in that, Josh
[? Lidney ?]
and I are giving a talk tomorrow afternoon on GIS in
Google Earth and Maps.
That's another talk.
And also the folks from Arc2Earth
here in the Geo Sandbox.
So, yes?
AUDIENCE: Are there tools or APIs essentially for creating
vector tiles?
I don't know if Google Maps for web is using this, I know
that Google Maps for mobile has started to use vector
tiles to save on bandwidth.
[INTERPOSING VOICES]
MANO MARKS: You mean to create your own--
AUDIENCE: --tools that will take KML and put it into
smaller [INTERPOSING VOICES].
MANO MARKS: To create your own tiles as opposed to using our
KML layer or the Fusion Table layer?
AUDIENCE: Well some vector tiles as opposed to using the
image tiles.
MANO MARKS: Oh, I see.
So the question is are there tools for
creating vector tiles?
Vector tiles, essentially for KML, that's regionation.
That's actually a concept that's been
around for a while.
But there's been a lot of people experimenting with
passing vectors in the same kind of--
the concept was the same, that you're packaging it into these
tiles to a maps application or to Google Earth.
I don't actually know of anything specifically in that
area that's very good.
Do you know of anything?
SEAN ASKAY: Not so much for Google products.
There's some open-source mapping tools that kind of
have this concept of tiled vector data.
And I want to say one of the ArcGIS extensions, maybe it
was Arc2Earth, might do that.
One of the trick you run into is if you're tiling a polygon,
you chop it up.
You tile it up.
And if you want like a border along that polygon, now the
original polygon that's been chopped has lines through the
cuts, right?
So at the moment, Google Earth doesn't really
handle that very well.
It's something we'd be interested in looking at.
But, yeah.
So I can look online, but offhand, I can't think of
anything that works really well for KML.
There's definitely a need for that kind of functionality,
that kind of tool.
All right.
Any other questions?
Three minutes to spare.
Cool.
Thank you, guys.
Come up afterwards if you have any questions.