Easy Panorama creation with Ice Cream Sandwich

I was hanging out with +Dan Galpin in China, and he was showing me an Ice Cream Sandwich phone. ICS comes with a panorama capability in it's phone. He took a few photos and sent them to me. I spent a few minutes and pulled them up into custom Street View panoramas.



It was pretty easy to do, but there were a few caveats. The panoramas didn't contain any location EXIF headers. Not sure if that will be part of the final release. My demo didn't require it since I was just using a free floating panorama viewer. Also, the panorama camera didn't always go a full 360 degrees, so the seam between the two ends was a little uneven. The only other issue was figuring out where the center of the panorama was and coding that into the heading of each panorama. Still, it was a nice and easy way to display these panoramas. Oh, and take a look at the full version, it shows the copyright information for Dan that I coded into the panorama.

Playing with the HTML5 Drag and Drop API

So another thing that inspired me during Sean Maday's talk at Google's Geospatial Awareness Day was his demonstration of using HTML5's drag and drop API to load a KML file into a Google Earth API site. In that sample, he loaded the KML file. The JS then parsed the KML and read it into the plugin. I immediately thought about using it with Maps, and adding in a GroundOverlay. So I wrote a quick sample to do just that. Of course, it doesn't work on older browsers, but if you're using later versions of Chrome, FF, or Safari it works just fine. I haven't tested it on IE9.

The code owes a lot to Riyad Kalla's HTML5 Drag and Drop Upload and File API Tutorial. He does a good job of explaining the API, so I'll leave that part to his post. All mine does is put any image in a GroundOverlay on a map. Drag any image from your computer into the little space at the top and it'll show up in a pre-defined place on the map. Next-up I'll work on a way to stretch and position the image. I'm also thinking I'll try to pull out any positioning in the EXIF headers to make a guess about location.

I'm thinking this would be useful for image upload and positioning sites. Say I want users to place images of old maps or more recent satellite imagery. They could position it on the map and then upload it to my server. Of course this doesn't take care of proper georeferencing or projections. Thoughts for another project.

Here's my code for creating the GroundOverlay:

function handleReaderLoadEnd(evt) {

  var imageBounds = new google.maps.LatLngBounds(
    new google.maps.LatLng(40.716216,-74.213393),
    new google.maps.LatLng(40.765641,-74.139235));
  var oldmap = new google.maps.GroundOverlay(evt.target.result,
    imageBounds);
oldmap.setMap(map);
}
  

HTML5 Input Range for a slider

I was at Google's Geospatial Awareness Day today, and Sean Maday did a demo of the new HTML5 input type of range, and I had a palm on forehead moment. Regular readers of the blog know I'm slightly obsessed with sliders, so I came home tonight and did a quick sample using a demo I did in Mexico City at the Esto es Google event. The example uses a FusionTablesLayer to show polygons from Natural Earth Data showing the boundaries of the Mexican states, and colors them using the populations, as found on Wikipedia.

Here's the sample, and here's the code for this sample.

function initialize() {
 
    var center = new google.maps.LatLng(23.99170847335287, -102.6702973539042);
 
    map = new google.maps.Map(document.getElementById('map_canvas'), {
      center: center,
      zoom: 5,
      mapTypeId: 'roadmap'
    });
 
    layer = new google.maps.FusionTablesLayer({
      query: {
        select: 'Shape',
        from: '1231298'
      }
    });
    layer.setMap(map);
  }
    function showValue(newValue)
{
  document.getElementById("range").innerHTML=newValue;
   layer.setOptions({query:{
      select: 'Shape',
      from: '1231298',
      where:"'2010'>" + newValue
    }}
      );
}
  </script> 
</head> 
<body onload="initialize()"> 
  <div id="map_canvas" style="height:75%">
  </div> 
  <input type="range" min="600000" max="15000000" value="600000" step="100000" onchange="showValue(this.value)" />
<span id="range">600000</span>

Fictional Worlds in Street View

I hope I'm not shocking anyone, but Liberty City isn't a real place. The central location in the video game Grand Theft Auto is a fictional self-contained world, a sandbox in gaming terms where there are missions but you essentially have free reign of the city, not confined to a narrow path like in some other kinds of RPG video games.

So why am I talking about video games, aside from the fact that video games are AWESOME?

Recently, I discovered a map on a fan site for Grand Theft Auto IV. It's actually not the first one, the first one I've seen was on IGN. Both these sites use Custom Projections and map tiles to define a map that shows only Liberty City with no reference to Google Map tiles.

 The new site though has a significant new feature, it uses Custom Street View Panoramas to display the Street View of Liberty City. Go ahead, try it, drop pegman onto the city and check out the panoramas. I'll wait.

...

Pretty awesome, huh? There's an interesting hack going on too. When you add a custom panorama it doesn't become part of the blue overlay that happens when you grab pegman but before you drop it. Since the designer had access to all the road data, since they designed the map, they were able to create a custom pegman that created their own custom blue overlay that allows you to see where Street View is.

I'm hoping we'll see more of these kind of fictional places in Street View Maps API implementations. The code for it is reasonably simple, creating the actual panoramas is more difficult. I hope this sort of thing inspires people to use the Maps API to show planning projects too, showing interiors of buildings yet to be built, etc.

Private Tables in Fusion Tables: Better privacy for your data

Back in June, I wrote about "Techniques for protecting your data." Yesterday, Google announced another way to protect your data, Protected Map Layers.

Protected map layers, a part of the Google Maps API Premier package, allow you to create a data table in Google Fusion Tables and keep that table private. Maps API Free allows you to use only tables marked Public. Protected map layers are rendered as clickable rasters. You still have to be careful what data you put into the infowindow, make sure it's only what you want public.

Of course, Maps API Premier also allows you to make maps that are password protected, so this will be really useful for enterprises that want to keep their data entirely private but still take advantage of the performance improvements and spatial queries that are allowed by using a FusionTableLayer.

Interactivity with FusionTableLayer and mouse clicks

The FusionTablesLayer in the Google Maps API is a bit of a black box. Fusion Tables generates a clickable tile overlay to use place in your Maps API application, but you don't get direct to change anything. If you want to change data, you have to do server side calls. However, the FusionTablesLayer does give you access to row data on click, which allows you to do interesting things server side.

In my sample interactiveftlayer, I use a Fusion Table of Google's corporate addresses. The table has a simple Color column, with values of 0 or 1. In the Fusion Tables map visualization for the table, I configured the Marker Icon such that values of 0 are green, and 1 are blue. The color means nothing of course about the actual office.

In interactiveftlayer, I suppress the InfoWindow by adding a suppressInfoWindows: true option to the layer initialization. I then add an event listener to the layer that captures the click event on the layer. This gives me row information about the feature clicked. I then send a XMLHttpRequest to the server (in this case App Engine) with the other color (1 if the color is 0, 0 if it is 1). After the response from the XMLHttpRequest, I reload the layer.

There's one tricky part, and hopefully we can find a way to improve this on the Maps API end. The FusionTableLayer is cached by the browser. Which means that even if the data has changed, the layer stays the same, at least at zoom levels visited while it was visible. This includes, BTW, not only the images but the row data associated with them. In order to defeat that caching, I append a Where parameter to the layer selecting for a Id greater than a random number from -1000 to 0. Since I know all Ids are greater than 0, I can do this. I'm not proud of that strategy, but it works.

Two Thumbed Closure Slider for Time Slider

I've posted a couple of times about sliders - Playing with Closure UI Library: Slider and a basic Basic Time Slider in Closure. My final slider example uses the same data set as the last, and incorporates a Two Thumb slider, meaning you can use the slider to set a range of values, not just a less-than or greater-than value. I also corrected something that impacted performance in the last sample, that is I checked whether the query changed by the different events, and change the query on the map layer when the query changes from the last. This is an artifact of the events that I'm listening form, MOUSEUP, MOUSEOUT, and KEYUP. You may remember in the first sample, I realized that firing off a query change whenever the slider had a CHANGE caused too many queries to hit the overlay server, causing the Map to show the missing overlay error. Listening for mouse and key events caused fewer events to fire, but still more than one per change. The change simply tests to see if the new query is different from the old query, and only re-query the layer server if the query changes.

Playing with Closure UI Library: Slider

For Google Developer Day in Saõ Paulo, my colleague Ossama Alami created this sample, which allows you to select between three different Google Fusion Tables layers and play with queries against them. I looked at that and decided that I would use it to play with the Closure Library. Specifically, I wanted to play with the UI library. So for the GDD events in Munich, Moscow, and Prague, I decided to add a slider. The results were fun, and instructional for me. The code to add a slider was pretty simple. Here's my sample, and here's the slider code:


<script>

var el = document.getElementById('s1');
s = new goog.ui.Slider;
s.decorate(el);
s.addEventListener(goog.ui.Component.EventType.CHANGE, function() {
document.getElementById('out1').innerHTML = s.getValue();
});

goog.events.listen(
s.getContentElement(),
[goog.events.EventType.MOUSEOUT,
goog.events.EventType.KEYUP,
goog.events.EventType.MOUSEUP],
function() {
var preset = document.getElementById("preset").selectedIndex;
var query = presets[preset].sampleQuery + s.getValue();
document.getElementById('query').value = query;
layer.setTableId(parseInt(document.getElementById('preset').value));
layer.setQuery(query);
});
</script>


I just took that from the documentation. Of course, there's a an HTML element for the slider, and some CSS to style it, and loading the library itself. Well, you can view source. The instructional bit was that of course as soon as you move the slider, events start firing. If you listen for a CHANGE event, as you slide the slider, it'll fire too fast. Each tick, it'll try to grab a new layer from Fusion Tables. That'll consume lots of bandwidth as FT tries to return a layer with each tick. So instead, I listen for MOUSEOUT, KEYUP, and MOUSEUP events, which fire when the user is done moving the slider, either moving off it or releasing the mouse.

Next up, I'm going to try to use it to simulate a timeslider.

Presentation at NACIS

I presented today at the North American Cartographic Information Society annual meeting, on new features in Google Earth Pro, Fusion Tables, and the Google Maps API. NACIS focuses a lot more on design, on cartography, and therefore it was a very interesting conference to be at, different from the usual GIS and developer conferences I present at. I sat in a session on rethinking the bike map afterward. Unfortunately, I had to leave after that, so didn't get to participate in much of the conference.

Here's my slides. There were a lot of questions on all aspects, but particularly on imagery.

My Slides from TimesOpen 2.0 Event on Mobile/Geo

There were about 100 people there, and it was great fun. The developers were all really engaged. When I asked how many had used the Google Maps API, almost everyone raised their hands. I almost went home at that point. And lots of interest in Fusion Tables, which I only did a demo of, didn't put in the slides, but check it out if you haven't already.

Ruminations on the 5th Birthday of the Maps API

A few weeks ago, we celebrated the 5th birthday of the Google Maps API. We celebrated again the next week. In a transpacific video conference, the Geo teams in Mountain View and Sydney ate cake and drank champagne. Speeches were made, memories recounted.

In particular, Paul Rademacher gave a brief history of Housingmaps, the first known Google Maps mashup, created initially before there was even an official API. It was thanks to the work of Paul, and several other mashup creators, that Google saw the potential to create something really special.

I often say that Google had two choices at the time. We could either sue Paul and others who reverse engineered the API and created mashups. Or, we could go with it. We went with it. I say "we" btw, as if I had anything to do with it, but it wasn't until a year later that I started at Google.

As I recounted that story at WhereCamp Socal on Sunday, I asked people what our choices were, and Tim Craig shouted out "Kill him or hire him!" Maybe that's the difference between ESRI and Google :-). (Tim is actually a great, gentle guy. As far as I know...)

It's hard to remember a time before mashups now. It's not that Google Maps was the first mashup ever, but it was the first monster mashup platform, and still the biggest. And it is having repercussions beyond people putting maps on their sites. As soon as people figured out that they could mashup maps with data, they started looking for data to do it with. And putting pressure on governments and companies to make that data available. Or simply going out and generating their own.

OK, those of you old enough to think back that far, try to remember the web before all these mashups. Still a cool thing, but not nearly as exciting. I'm old enough to remember a time before the web, of course, but that's beside the point. The fact that we can put a map with high resolution satellite imagery on our web site for free is amazing in retrospect.

The impact on the mapping community was also pretty profound. I think we're still figuring out what the implications of that are. Neogeography, the geoweb and all the other things many of us hold dear, they take off with the Google Maps API.* It is hard to imagine this, but 5 years ago who would have thought this would happen? I know it's a cliche to say that about the web in general, especially for those of us old enough to remember before the web, but 5 years. 5! Can you imagine going to a site for a retail store and not seeing a map to their location?

But there's a lot more here than putting dots on your map, showing where your store is. That's important, revolutionary indeed, but think beyond that.

Maps mashups have been used to map election violence in Kenya, report potholes in the UK, show reports of people in need after the Haiti Earthquake, convey comprehensive data about Africa, and much more. Creating advocacy maps, informative maps, or fun maps no longer requires a professional cartographer. Nothing against cartographers, but put the power in the hands of the people.

So, what happens when you start mashing up data? You start looking for more data. The confluence of the Open Source movement with the mashup community produced a call for more open data. And because of the power of these mashups to put data in front of the people's faces quickly and easily, governments had to respond. In the US, in the UK and around the world, more and more data is being opened up by governments, NGOs, and to a lesser extent corporations. Bringing data to the public is a democratization. Knowledgeable, informed citizenry can respond to their governments, and help out as we saw in the case of the CrisisCamps that sprang up after the Haiti earthquake.

We still have a long way to go. Good tools are developing, but most people aren't programmers, to take advantage of the API, or know much about geographic data. That's why I'm excited about GeoCommons and Fusion Tables, because they allow people to use tabular data (say, in a Excel), probably the most used "databases" in the world.

But all those involved in mapping on the web, pat yourselves on the back. Look where we are compared to 5 years ago. I'm guessing most of those reading this blog are involved in Geo in some way, and so I'm saying to you: Thank you, you've done a great thing for thing for the world. You're bring democracy to the world. I know that sounds hyperbolic, and I know it's not the only thing driving increased access to information. But mashups, driven by mapping mashups (Google and otherwise) are helping change the world.

Map Styles and Usability: Please Help

I've been away for a couple of weeks, and I'm now catching up with what's been going in the Geo blogging community. I saw a couple of posts on the Google Maps API new styling features:

Thoughts about Google’s Styled Maps announcement

Google Map Styles

There were more of course, but Steven Romalewski and Richard Treves raise some good points about usability. We've basically provided no guidance on usability of the new styles. The examples that we provide are designed to show extremes of styling to get the point across.

The truth is, we're mostly engineers, not cartographers. I'd love to see some great guides to how to style your map. Anyone want to give it a go? Anything good out there, I will make sure we link to it and talk about it.

To be fair, Steven is also concerned that it'll actually drive more people to use Google Maps API. His concern, our hope of course :-). He is concerned that this will reduce the commitment to other mapping platforms and perpetuate a mono-culture of maps. I don't see any danger of that right now, but I do appreciate that concern. Competition is good for us, it does help drive us to better things. So Cloudmade, Bing, OSM, everyone else, please make your mapping better. It helps us too.

Techniques for protecting your data

I was asked in the comments in this post: Maps to KML?, to talk about techniques for protecting your data in Google Maps applications. I'm finally getting around to that.

First off, let's just say that like any part of the web, it is probably impossible to totally protect your data that is published on a Google Map. People can always get access to it at very least by just viewing the data, which you want, and making notes. Screenshots, viewing source, intercepts, and other techniques can be used by the truly ambitious. True data privacy in a completely public page is an oxymoron. Note, I'm not saying privacy on the web is bad or not possible, but we're talking here about displaying data. As long as it's displayed, someone can get at it.

That being said, there are steps you can take to make it harder to get at, to make people work at it.

The most important thing you can do is avoid hard coding any information into the page. That should be fairly obvious, but many people fall into the trap. That means:

1. Don't have any code in your JavaScript that uses a specific Latitude/Longitude pair, an address, or anything of that nature.
2. Use calls to server resources to plot only the data necessary to display at that moment. Try to verify the origin of the requests to prevent people from scraping. Generating your data on the fly prevents someone from getting all your data at once.
3. Obfuscate/compile your Javascript code to make it harder to read.

You can also rasterize your data, or turn it into image overlays. There's a lot of techniques for doing this. This talk by John Coryat is a couple of years old, and was oriented to Maps API V2. However, in it he discusses many techniques that are applicable to V3.

Rasterization makes it difficult to extract the data directly. It can also increase your performance in some cases where you have lots of data.

If you're working with KML, you can distribute the KML to only trusted people to load in their Google Earth instances, but this is subject to trusting them. Any KML used in a Maps API application will be easily findable by someone who can get passed any obfuscation you have.

That's all I've got. Feel free to post any additional techniques in the comments.

Geo Highlights from Day 2 of Google I/O

Wow, Day 1 at I/O was such a big day Geo, it would be hard to top it. But there were some amazing gems. Check out these highlights:

1. Styled Maps! Probably the biggest news of day 2. Maps API V3 now gives you the option to style your maps. Don't like golden highways and green forests? Change it! Check out our announcement for more details and links.
2. Matt Lowrie gave a great talk on the SketchUp API and using SketchUp.
3. Josh Livni and I previewed a whole bunch of additions to the Earth API and a new KML extension. In particular, Earth API now has control over the time slider, and better balloon handling. Now, you can preserve your JS and Flash in the balloons. In KML, we previewed the Track extension, which will allow you to assign multiple way points to a model or point and move it around, rather than recreating them with multiple Timestamps.
4. Finally, and this was actually announced on Wednesday, you can now add a FusionTable layer to a Maps API V3 app, right from the API.

It's really exciting to see all this. We're closing the loop on a lot of developer requested features, and we're really happy. Thanks for those of you who came or watch it on video.

Geo Highlights from Day 1 at Google I/O

Boy, are my feet sore!

Wow, what an amazing day! Geo rocked Day 1 at Google I/O.

First, Daniels Lee announced that the Google Maps API V3 has graduated from labs and now is the recommended version of the Maps API to use. It also means that V3 is part of Google Maps API Premier, which is something people have been asking me about.

That also means that V2 is deprecated. We'll continue to support it, and fix bugs, for at least the next 3 years. Check out the deprecation policy in the terms of service. We're also deprecating Mapplets.

We also announced Street View in the V3 API, Flash-less so you can use it on mobile browsers. See my talk for more details. Videos and slides should post soon.

We announced a Directions web service as well, allowing us to close by far the single most requested feature in the issue tracker.

And finally, we previewed a Places widget, allowing you to show Places nearby your current location. It's built on the Places web service, now in Developer Preview.

There was also a fireside chat with Geo engineers and Product Managers, a Developer Sandbox with lots of great stuff on display, and a talk on Maps Data API by Tom Manshrek.

Plus, there were tons of Geo developers all over the conference. I think I talked to half of them. If you're in the other half, come and talk to me tomorrow!

Maps to KML?

People often ask me, can I take a Google Maps mashup, and make a KML file out of it (or in some other data format)? This question never comes from a Maps developer, only from people who see a cool mashup and want to overlay the data on their own map.

The short answer is: no, you can't.

The long answer is: no, you can't, and that would be wrong.

The longest answer is: no, you can't, unless the developer chooses to make a KML file available to you. It's possible, in fact, that they are using the KML file loaded onto their map using GeoXml or some other method. Otherwise, no, and it would be wrong.

I can understand the desire to do so. After all, a mashup is a combination of data from different sources, and a Google Maps API mashup is a mashup of data with Google's mapping API, in JavaScript, Flash, or just plain image URLs using the Static Maps API. And people often use public sources, or sources that are about things that are interesting or impacting lots of people, like Sports or the volcanic eruption in Iceland. Why wouldn't that be available to you?

First, from a moral point of view, the construction of that site belongs to the developer of that site. Usually, the data isn't presented to them raw, a certain amount of development has to happen to transform the data into a format usable for the app. In fact, they may have agreements with the data provider that they don't, or some license in the download from a public site restricts redistribution.

Of course, it's possible they just didn't think of it. Ping them, maybe they would do it for you just to be nice. Depends on the data of course.

Second, think about it from a technical point of view. Flash of course is it's own beast, and can write files. If the developer so chose, they could put a download data link or something. But as far as the JavaScript APIs go, JavaScript deliberately doesn't give you file access for security reasons. So a data file can't be taken from a JavaScript page. Nor has Google hidden an API inside the Google Maps API to allow other people to pull data out programatically. Again, that would be wrong.

I'm not saying that people can't look at your code and figure out your data sources, if you're the developer. If you want to protect that data source, you should design accordingly.

My Where 2.0 Slides Going Mobile

Client-Side Geocoding Rocks!

Part of my job is to help partners with their code, making sure they are successfully implementing on Google Earth and Maps. The most common problem people come to me with is something like "Can you give me more quota, my http geocoding limit is reached." This is for the free Google Maps API. There's a simple solution. Don't do it!

The way the quota for the Google Maps API geocoder works is by IP address. If you put the geocoder in your JavaScript code (or Flash) it's rendering in the browser. And therefore counts against the IP address quota of the browser, not your site. If you have a single server side script that does an IP address lookup, it's going to be against the single IP address of the server. In other words, if your site is popular, you're going to run out quickly.

So, geocode in the browser and then send the geocode to do your lookup. We even allow for caching, as long as you're going to display on a Google Map or Google Earth. Caches can happen in the browser or server side.

A few additional things to think about:

1) Cloud computing services often share a range of IP addresses. If you're running on AWS or Google App Engine or any other cloud computing service, you particularly want to do client side geocoding, as you may be running quotas parallel to other apps.

2) Some mobile networks share IP addresses as well. That can cause problems for your client side software, as lots of people on their smart phones are looking at your map. If you anticipate heavy mobile use, you might consider having a server-side back-up as a fail-over. Try to geocode and if that doesn't work, send the address to your server for http geocoding.

3) If you're still running into problems with quota, you may consider a Maps API Premier license. Check out http://maps.google.com/getmaps for more information on the differences and to get started.

Slides from Visualizing the Past

I presented at Visualizing the Past on Google Geo technologies and their use for historical visualization. I didn't get to the part on the Google Visualization API, but the links are in the slides.