In 2007, we wrapped up the year with a bulleted list of our various accomplishments from this year. In 2008, a few LIs and a UL just won't do. So we're celebrating the year in typical New Years fashion: fireworks, baby. Watch the show below, and click any headline it leaves behind to read the relevant blog post. If it went too fast for you or you just can't get enough of it, then you can watch again by clicking the button below the map. Happy New Years, all!
P.S. Five bucks if you can find a way to name-drop the Google Geo APIs in your midnight toast (or New Years' post?) and send me proof.
For the second year in a row, Google partnered with NORAD to provide an online map-based interface for tracking Santa's Dec. 24th sleigh ride across the world. Last year, the map was powered with the JavaScript Maps API. As the programmer for this year's map, I made the decision to use the Maps API for Flash instead. Why? I desperately wanted a glittery "comet trail" to follow Santa's path, and those kinds of effects are easier to pull off in Flash. (One might argue that decisions shouldn't be based on glitter, but one could counter that by pointing out the entire 1970s decade was based on glitter).
While converting the map over to Flash, I wrote code that may be helpful to other Flex developers out there. Instead of just open-sourcing the Santa Tracker map code* and forcing you to sort through it all, I've created standalone demos and descriptions for each of the features:
* Okay, yeah, I open-sourced the whole code as well, mostly because I've developed an unhealthy dependence on Google Code's nifty subversion repositories and issue trackers. Finding the NORAD repository is left as an exercise to the reader.
Starting today, over 15,000 geoscientists and educators will gather at the Moscone Center in San Francisco for the Fall Meeting of the American Geophysical Union. Following on from previous years, we are convening a special session on Virtual Globes. This year’s session is titled “Visualizing Scientific Data Using KML and Virtual Globes,” and will take place all day on Thursday 18th December.
There will be over 60 talks, posters and demonstrations from researchers, educators and developers. The session has been organized in collaboration with Google, and they will have plenty of experts on hand at their exhibitor booth to help with KML problems and answer your Google Geo questions. Anyone is welcome to stop by and register for the conference for a day, so if you're in the Bay area, please check it out!The week starts off tonight with Michael Jones, Google’s Chief Technology Advocate, giving the Frontiers of Geophysics Lecture. His talk, “The Spread of Scientific Knowledge from the Royal Society to Google Earth and Beyond” will be held at 6:30pm PST. The lecture will also be broadcast as a live webcast.
A long time ago, at a conference not too far away, Google launched the Google Earth Browser Plugin, with the Google Earth API. At the time, we promised that we would bring it to the Mac, and now we have.
Today, we're excited to announce the release of the Google Earth Browser Plugin for Mac OS X 10.4+ (PowerPC and Intel). The Mac plugin is supported on Safari 3.1+ and Firefox 3.0+. The download link should now be available to all users from any Earth API-powered site. We also released a game, Puzzler, in honor of the new Mac plugin. It is, of course, playable on a PC as well. And as usual, it's open source, so you're free to adopt the code.
In addition to the Mac release, we've also upgraded the Windows version of the plugin. See the release notes for more details.
From time to time we release updates to the terms of service governing our products. We recently released an updated version of the Google Maps API Terms of Service. Based on feedback from that update, we are releasing a revised version today. The Google Maps API TOS is intended to satisfy several goals: it gives Google the rights needed to operate a service which overlays content on the map, gives us the ability to showcase popular mashup sites, and allows us to index and provide search over Maps API sites so that Google users can find them.
What changed and why? A key goal for the November 12th revision was to eliminate a number of unpopular restrictions, including the prohibition on friend finder applications and non-"site" mashups. We also eliminated ambiguity about whether it's OK to use the API w/ password-protected free sites (it is). Additionally, we streamlined the format of the terms, eliminating the need for developers to reference multiple sets of incorporated terms of service, including the Google Terms of Service and the Google Maps Terms of Service to figure out what rights and obligations applied to their use of the Maps API.
That format change appears to have called attention to the "License From You to Google" - section 11 in the November 12th update. That content license has always been part of the Google Maps API Terms of Service, because it is contained in the Google Terms of Service. Both the original and the November 12th updated Terms of Service relied on that provision to ensure Google received a sufficient content license to provide the Maps API service and to promote the service, including by highlighting excellent mashups as we did here. That section does not provide Google a license to all of the content on your Maps API site to use for any purpose, nor is that how we have treated the content from existing Maps API sites that were developed under the terms that existed prior to the November 12th update. Section 11(b), which we initially included in the November 12th update, created a lot of confusion among our API developers who are publishing licensed content. In 11(b) we were trying to be clear that we wanted a broader license from Maps API developers for use of business listings information. However, given the confusion that resulted, we removed that language from today's revision of the terms.
Thank you for using the Google Maps API. We look forward to continuing to create great products together with you.
Hi, my name is Björn Brala! In the last 2 years, I've been working on GeoStart, a framework based on the Maps API. In that time the community has been an invaluable source of information and help. While getting help is nice, helping is even nicer - so I've decided to properly release and document the code for two helper libraries into the open-source utility library project.
When loading hundreds of markers into a viewport, you should communicate this to the user, and this class will help you do so. The progress bar is a custom GControl with a few basic commands to start, update and stop the loader. The general idea is that you set the amount of operations the map will plan to do and then once in a while send an update command to the control.
The example below uses the control to show the progress of markers being added and removed from the map. Click the "loadMarkers()" button to start it up:
If that interests you, check out the reference and developer's guide for the ProgressbarControl.
In our framework, we wanted to enable administrators to not only create routes, but also plot different POIs along a route - so I created the SnapToRoute class based on one of Marcelo's examples. This class lets you snap a marker to the closest point on a polyline, ensuring that the marker is always somewhere on the line.
There are numerous ways to use this tool. The example below uses the class to let you zoom into segments of a polyline:
If that interests you, check out the reference and developer's guide for SnapToRoute.
Hope everyone likes the little additions, and don't forget to check out the other classes in the utility library!
Hi, I'm Oliver Oxenham, posting about the National University of Singapore (NUS) Library 3D interior mapping. After investigating a few other development options, we decided to go forward with Google Earth Plugin especially because of its API's ease of use -- there was no need for us to reinvent the wheel in the area of 3D display in the browser and camera movements in a 3D environment.
The NUS library features a few innovative uses of GE plugin as well as Google App Engine. App Engine is the platform that controls all the information you see in this 3D application. We offer our customer an administrative interface to allow them to create their own placemarks (landmarks) within the 3D library as well as choose to make them visible or invisible. The contents of the landmarks are editable. It can display formatted text or even videos. Additionally, customized orientation tours can be created on the fly by the user who only has to select a list of landmarks and arrange them in the order they want the tour to play.
The GE plugin displays a 3D model of the NUS library with the earth covered with a black layer so as to make the model stand out more and avoid distracting the user with unnecessary features. The navigation on the right is automatically generated based on the landmarks created by the user. It allows the viewer to navigate through the library from landmark to landmark.
The application also allows 3D book search. Google App Engine datastore keeps a catalogue of book call numbers and shelf references. When the viewer enters a call number in the search box, the latitude and longitude of the appropriate shelf is retrieved and located in 3D.
All these adds to the fact that we are using the GE plugin for an interior 3D of a building instead of the usual outdoor of an area. We believe that a lot of our implemented features can still be improved and we're working hard to improve them and make them more generic and reusable in the future. We believe 3D interiors can be attractive to some customers.
Just a little over six months ago our team announced the release of the Google Maps API for Flash. Flash developers around the world welcomed this new API with excitement... and a barrage of feature requests. By far the most popular one in the past six months has been the compatibility with Adobe AIR.
Throughout its three years of existence, the Google Maps API has become one of the most popular online APIs for creating web mapping applications at a time when web was the hot new thing. Well, in the past year, Adobe has taken web apps back to the desktop, with their innovative AIR product.
There were both technical and legal challenges blocking AIR support inour API. AIR has a different security model, which required a numberof changes to the "internal plumbing" of the API in order to implement our delayed-loading model, where the actualimplementation of the map's functionality loads dynamically fromGoogle's servers once the application launches. Also, our Terms ofService used to specify that the Maps API could only be used foronline web applications.
Now that both the API and Terms of Service have undergone a facelift, we are releasing the first version of the API that will allow Flash/Flex developers to bring Google Maps to the AIR runtime.
Developers who are already familiar with creating online applications with the Google Maps API for Flash will find it easy to start using the API for their AIR apps. Just about the only difference is the use of the url parameter of the map class. Developers creating normal online applications sign up for a key corresponding to the URL of the SWF, but developers creating AIR applications must sign up for a key corresponding to the URL of the page that the application can be downloaded from. While instantiating a map, AIR developers will need to provide both the key and that url in the key and url parameters of the map, respectively. For more information (and screenshots!), read through our snazzy new tutorial on developing AIR apps in Flex Builder.
url
key
For a few examples of using the API with AIR, check out the demo gallery. One example is the "Map CSV Parser", which is based on the great text-file editor example from the Adobe docs. This AIR app lets you open or drag a CSV file, and then it parses it into draggable markers on to the map. The new positions of the markers can be saved into the same or new CSV file on the file system. It's just a few lines of code, but should give you an idea of the kind of powerful interaction possible between a Map and a Desktop. Click the screenshot or here to view and download the source for that example.
We are looking forward to seeing your ideas and your AIR apps! As always, please follow up with your suggestions and questions in the forum.
Reposted from the YouTube API Blog
Gears Geolocation API provides a best-effort approximation (WIFI-based for PC and GPS/CellID-based for mobile devices) of your physical location.
YouTube Geo + Gears
Gears Geolocation builds on top of the IP-based ClientLocation locator we previously blogged about, but with a more sophisticated approximation.
OK, it's not exactly a manual, actually a handbook, The KML Handbook by Josie Wernecke. Josie is the Google tech writer who wrote the KML 2.1 and 2.2 documentation, and also helped write the KML 2.2 OGC Specification. So she knows what she's talking about!
The KML Handbook is the most complete treatment of KML in print. It explains all the various elements and features of KML. It also examines both well known topics like Regionation, and lesser known topics like View Based Refresh. It is also the only book on KML officially endorsed by Google.
The book is available for pre-sale from Amazon and O'Reilly, and should be available for immediate purchase soon. So for all those would-be Santa Trackers, and anyone else in the geographic world, you now have a great holiday gift.
There are two recently released additions to the articles section of the documentation, for two completely different audiences. Check them out below:
Are you a developer accustomed to developing mySQL-driven websites with PHP? Do you want to learn how to use the Google Maps API for Flash with dynamically loaded data? This article goes through the steps of creating a mySQL table, populating the table with data, using PHP to generate XML from that mySQL table, and finally, writing the AS3 code to dynamically load in the PHP-generated XML and display a map with multiple markers and custom icons. After going through this tutorial, you should be ready to extend what you've learned to your own databases.
Click here to read!
Are you a Photoshop junkie who wants to create the perfect GIcon for your map mashup? Are you struggling to figure out the best settings for the shadow and print images? This screencast (Flash player required) goes through the process of creating icons, covering each of the GIcon properties in detail. You can also download all the sample files (PSD/JPG/PNG/GIF) used in the screencast. After going through this screencast, you should be ready to extend what you've learned to your own crazy unique icons (Hello Kitty, anyone?).
The articles section now also includes links to a few external articles that we found really useful: Thematic Mapping with the Google Maps API for Flash, and Creating Custom Campus Maps using the Google Maps API. If you've written an article about the Google Maps API that you think would benefit developers reading our documentation, please let us know.
One of the first concepts I explain to developers that are new to mapping APIs is geocoding: the process of converting an address into a latitude/longitude pair. Approximately 99.9% of developers will have to use a geocoder before they can get their data onto a map, and to let users of their map locate themselves. Thankfully, we offer both the HTTP Geocoding service for server-side geocoding (the former), and the GClientGeocoder class for client-side geocoding (the latter).
Now, let me introduce the more advanced topic of reverse geocoding: the process of converting a latitude/longitude pair into an address. A much smaller (but important) percentage of developers will want to use a reverse geocoder to let their map users know the address for a particular point on the map, perhaps to help them fill in a form faster (why type when you can click?!). For those developers, we're now pleased to offer address-level reverse geocoding support to both our HTTP service and the GClientGeocoder class. To make it super easy to use, the interface for reverse geocoding is nearly the same as forward geocoding - the only difference is sending in a lat/lng instead of an address. Here's a code snippet for doing client-side reverse geocoding, taken from this sample:
geocoder.getLocations(latlng, function(addresses) { if(addresses.Status.code != 200) { alert("reverse geocoder failed to find an address for " + latlng.toUrlValue()); } else { var result = addresses.Placemark[0]; map.openInfoWindow(latlng, result.address); }});
As a live demo of the reverse geocoder, check out MeetWays, a site that mashes up the Google AJAX Local Search API with the Google Maps API and just a bit of math. It calculates the point between two addresses on the map, uses the reverse geocoder to find out the address for that point, and then does a local search near that address to find places to meet that are halfway between. Since reverse geocoding works in all the places that forward geocoding works, then you should be able to meet up with your friends in more than 70 countries.
For more information on this new service, read through the reference and sample code. We'd love to see the ways that developers will use the reverse geocoder, so please post a link to your reverse geocoding demo or website in the forum. Now go forth and reversify!
Howdy, everyone! I'm sure that after reading countless posts on the Geo Developers blog and writing tons of code using Google Geo APIs and other development kits, you're all experts with KML. I mean, you obviously know that to create a polygon, you simply need a <Placemark>, with a <Polygon> containing an <outerBoundaryIs> consisting of a <LinearRing> with a <coordinates> element which contains a series of (longitude, latitude, altitude) tuples... and, you didn't forget that you need to repeat your first coordinate tuple again at the end, right? Heh, well maybe not. For those of you can recite the entire OGC KML v2.2 schema from memory in one go, you can probably stop reading.
To the 99.9% of us who don't know everything there is to know about KML, and have been looking for a way to explore this curious little language, I present a new learning and exploration tool called the KML Interactive Sampler. One caveat, though -- since the sampler uses the Earth Browser Plug-in and API, the Earth view will currently only work on Windows.
Mac folks... be patient, a seriously awesome Mac version of the plugin is in the works!
Here are a few screenshots of the sampler to whet your appetite:
So, if you're just starting out with KML, or brushing up on your existing skills or maybe just looking to play around with a cool new toy, definitely check out the new sampler. If you have any trouble using it, feel free to comment in the Getting Started with KML support forum.
Thanks, and enjoy!
Back when we announced the "Google Maps API for Flash" in May, there were a large amount of Flash CS3 developers who were miffed at our lack of support for using the API in their favorite program, and quickly made "Flash CS3 Support" the second most starred feature request -- and there was even one developer named Vincent who managed to get our SWC running in CS3 who quickly became a one-man support desk for his hack. Well, Vincent, it's time to take a vacation, and CS3 Developers, it's time to get to work. The 1.7 SWC can now officially be used as a Flash CS3 Component, and the documentation now includes a snazzy screenshot-filled tutorial about creating your first map in Flash CS3.
To show that off, I made the kind of demo that one can only truly be done in Flash - a Google-ified re-envisionment of a scene from my all-time favorite movie, Puff the Magic Dragon. Click the screenshot to check it out.
Warning: Watch this scene (5:20) first if you've never seen the movie, or you'll think I'm a bit crazy. I mean, you might think so anyway. But still.
And there are a few extra features for everyone, like TileLayerOverlay, ScaleControl, Geodesic Polylines, Walking Directions. Check out the demo gallery for examples of those, and read the docs for more information. Enjoy 1.7, and let us know in the forum how you're using the API or if you have questions.
Back in May, we released a feature in Google Maps that let users toggle on additional "layers" of information on top of the map, starting with Panoramio and Wikipedia options. Both of these layers display thousands of variably sized icons on top of the map, and open info windows with more information about the clicked icon. So the user might click a large "W" in New York to read a snippet from Wikipedia's article about the Empire State Building, or they might click on a thumbnail in Black Rock City to see a photo of a Burning Man Temple.
Now, for those of you who want to easily enable these layers on your map (or through a custom control), you can create a new Layer object with the specified layer ID, and then add that to the map as an overlay. Check out the sample code and demo below, and read through the docs for more info:
map.addOverlay(new GLayer("com.panoramio.all"));map.addOverlay(new GLayer("org.wikipedia.en"));
Note: There are localized versions of the Wikipedia layers available in many languages. These will not be automatically served to users based on browser setting, so you should explicitly add those if your map is targeted at a local audience. See this spreadsheet for a full list of IDs.
For those of you developers wondering how these layers are able to display so many icons without slowing the browser down, here's some inside info for you. The layers are actually implemented as GTileLayerOverlays, where the tiles are just transparent PNGs with icons baked into them. The clickability of the layer is achieved by passing information about the clickable pixel bounds of each tile to the client, then doing a client-side check to figure out which bounds the cursor is inside on the map mousemove and click events, and changing the cursor or popping up the appropriate info window. If you're interested in implementing a similar solution for your own thousand-markered mashups, check out John Coryat's clickable tilelayer demo in the demo gallery, or the various presentations on creating custom maps.
Back when I was attending high school in Syracuse, NY, I did the typical teenager thing and learned how to drive a car. Syracuse is a (relatively) large city in the middle of upstate NY, so getting from point A to point B could either mean driving down winding country roads and passing by Llama Farms (true story) or driving on multiple highways to get to our nearly-biggest-mall-in-America/most-polluted-lake-in-NY (yep, its at the same location.. go city planners!).
I quickly learned that I loved country roads (who doesn't like llamas??) and hated highways, but since everyone around me were highway-lovers, it was near impossible to get directions to places that didn't involve highways. So that's where Google Maps, and now the Google Maps API, becomes my new best friend. By specifying avoidHighways in GDirectionsOptions, I can find a route that avoids highways. Click the screenshot below to check it out.
avoidHighways
GDirectionsOptions
Fast forward 5 years: I've moved to the bay area to start my job at Google, and I realize that there aren't really many country roads left, and pretty much all routes involve either a highway or intersections. I should probably mention that I eventually learned in Syracuse that I hate intersections: left turns, right turns, they all freak the gajeezus out of me. So I decided that I'd walk everywhere possible, and seek housing in highly walkable areas. So once again, that's where Google Maps and the API help me out. By specifying G_TRAVEL_MODE_WALKING in GDirectionsOptions, I can get walking directions from my apartment to the nearest "beverage" store. Click the screenshot below to check it out.
G_TRAVEL_MODE_WALKING
Note: Since walking directions may sometimes not include clear pedestrian paths, we need to make sure that your users take caution when using them. So, walking directions are only supported if you have supplied a <div> in the GDirections constructor; this <div> is used to display a warning to the user in the turn-by-turn textual directions.
GDirections
If that piqued your interest, read through the updated Developer's Guide and API Reference. As always, post in the forum with any questions you may have.
Sometimes there's functionality that's ridiculously useful for a niche group of developers, and completely unnecessary for others. That's the kind of functionality that's now available in our brand spanking new "Google Maps API for Flash Utility Library" open-source project, and is ready for developers to use, modify, and even improve.
Our 3 inaugural libraries are:
To check out the docs and demos for each library, visit our Libraries wiki. If you end up using any of the libraries for your own projects, please let us know in the forum.
For information on contributing patches or libraries to the project, visit our FAQ. To all of you talented AS3 developers (I know you're out there; I've seen you in the group!), I hope that you consider adding to our central repository of helpful add-ons for the Maps API for Flash.
So, it appears that a few thousand of you developers were sending our static map server requests with "&maptype=satellite" in them. Why would you do that? Did you think that we'd see all the requests and just decide to start returning satellite imagery to you? Well, fine. You were right. Here you go:
And just to anticipate those of you who are thinking to yourself about what a mighty fine plan that was, and how you're going to start sending "&maptype=hybrid" and "&maptype=terrain", here, have those map types too:
Okay? Happy now?? Statistically, many developers should be — since "add other map types" has been our top starred static maps feature request in the public issue tracker since the launch of the Static Maps API.
So check out the documentation and start using the new map types for your thumbnail maps, mobile maps, or any of the other reasons we mentioned in our last static maps post. You can also check out the other goodies in this release in the Static Maps API changelog. Enjoy, and let us know in the forum if you have any questions (or just nifty examples to share with us).
The Fall Meeting of the American Geophysical Union (AGU) is held each December in San Francisco. It is one of the largest gatherings of geoscientists in the world, with over 15,000 attendees. Over the past couple of years a quick tour through the poster presentations on any day would have revealed the influence that KML, Google Earth and Google Maps are having on how geoscientists present their data.
In 2006 and 2007 we convened a Virtual Globes session at the AGU Fall Meeting to provide an interdisciplinary forum for those interested in demonstrating their use of geobrowsers, and meeting other like-minded individuals. Previous presenters have included industry developers and bloggers, as well as the authors behind many of your favorite geoscience KML files, such as the volcano layer, earthquake locations, and sea-ice coverage. The sessions are a mixture of talks and interactive demonstrations, with the latter providing large plasma screens, poster board displays and high-speed internet for each presenter.
The 2008 Fall Meeting of AGU will be held on 15-19 December, and with the help of the Google Geo-team we will once again be convening a Virtual Globes session to demonstrate and promote the development and use of virtual globes and KML. We are currently soliciting presentations from scientists, developers, educators and any individuals interested in utilizing these technologies for better scientific understanding, public outreach and education about our "real" world. The deadline for submissions of abstracts is 10th September 2008.
Full details of how to submit your abstract for consideration are available on our 2008 Virtual Globes website, along with links to more info on the rest of AGU's 2008 Fall Meeting. For those just wishing to attend and not present, the full schedule of Virtual Globes talks and demonstrations will be posted on our website in mid-October.
Google Developer Day London is coming up, and I'm pretty excited. I'm coming to London for it. I'm coming to London and we're holding a meetup for geo developers on Monday, September 15th, at 4:00pm in the Google London office. We'll gather together for a couple of presentations and question and answers. Then we'll spend some time getting to know each other at a local pub.
Space is limited, so if you're coming, please let us know you're coming.
In the first release of MapIconMaker, we gave developers the ability to create dynamically resized and colored marker-shaped icons. Now with the second version, we're adding two entirely new types of customizable icons. The table below (stolen blatantly from the documentation) compares the three available functions. To get more of a feel for everything that's possible with all the icons, play around with the updated wizard.
As a demo of what kind of maps are possible with the new icons, I've created a gadget that uses the Visualization API to pull rows of U.S. address data from a Google Spreadsheet, clusters the rows based on what state code I find in the address (yay for RegEx!), and then creates icons for each state cluster that are dynamically sized and labeled according to the size of the cluster. As an added touch, I overlay a transparent state polygon on marker mouseover, and I change the color of the marker and polygon on marker click. Much thanks to the 2008 Election Trends map for inspiring the UI and making its code and states data available.
Check out the demo map below, and if you're inspired yourself, read through the MapIconMaker reference and documentation (or code - it's open source!).
A lot of map mashups out there have country-wide or world-wide content. That's awesome because it means there's something for everyone. What's not so awesome is that it means that when I get to the map, I often have to spend some time panning and zooming until I'm in my hometown and seeing the local content I'm most interested in. And as you know from previous posts, I'm inherently lazy and get bored whenever I'm forced to engage in unnecessary mouse movement. Wouldn't it be better if the map could automatically center to my location without me lifting one of my precious fingers? The answer is yes, and now it's easier to do than ever with the introduction of IP-based location information in the AJAX APIs framework.
To add user-based centering to your map mashup, follow the steps below.
<script>
google.load("maps", "2")
Check out the example implementation below, but feel free to make your own implementation snazzier (perhaps by adding a GControl to let the user easily jump to their location):
GControl
For more information, read the docs on using the AJAX Loader and using ClientLocation, or post in the AJAX APIs group with questions. If you're developing a mobile website and want a more precise location for your users, check out the GeoLocation module in Gears.
Before we release a new version of the Maps API, we always run it through a huge bank of tests to make sure standard functionality is working. But one thing we've realized since releasing the Maps API and watching its adoption is that it can be used in ways that we never imagined - and subsequently, ways we never thought to test.
So we figured the best solution would just be to let you, the creative developers, tell us exactly what functionality you want tested - by adding your own tests. We've open sourced our integration tests and are now ready to accept contributions. Our infrastructure allows us to run these tests on the stable, current, and bleeding edge versions of the API, so that potential problems can be discovered long before they are out in the wild.
The tests we have released use Selenium. Selenium is an open source tool for automating tests of human-browser interaction. It runs in a range of browsers, so by its very nature it takes into account browser discrepancies. As an added benefit, developers can run tests by simply going to a url and clicking a 'run' button!
The screenshot below shows our basic test running (and passing, whee!):
Note that we have hundreds of non-Selenium unit tests for expected functionality, but we're not releasing those just yet as they're more tightly coupled with Google infrastructure.
For information on running and contributing tests, read the project wiki. Thanks for reading, and we look forward to your contributions.
Good arvo from Sydney, Australia, where it's beautiful even in the dead of winter and the people use contrived abbreviations for literally everything. I kid, I kid. Australia is great, and the vegemite is even greater. I've spent my winter internship (also called a "summer internship" for my compatriots above the Equator) working on the Google Maps API for Flash, which was released back in May. If you're like me, you might think that Flash is a tool for creating amateur cartoons of questionable legality after school. Friends, I assure you -- it's so much more.
JavaScript developers have reaped the benefits of driving directions in the Google Maps API for over a year now, but without them Flash developers have endured three long months of repeatedly getting lost. As someone who accidentally drove into Oklahoma for well over an hour before realizing that his roadtrip only involved Texas, I feel your pain, Flash folk. But worry no longer, for I bring good news. It has been my pleasure to rectify this disorientation dilemma and bring the enormous utility of driving directions to our Maps API for Flash, starting with version 1.6.
The interface for the Flash API's Directions class closely resembles that of the JS API's GDirections class. You still create a Directions object, optionally listen for load/fail events on it, and then call the load() method with a directions query. The Directions object contains all the response information as Route and Step objects, also like the JS API. The awesome thing about Flash is that you can then include all sorts of animations and movie clips to complement the directions in your application. Consider the following application which uses a penguin to show you how to get from the Alamo Drafthouse movie theater to Waterloo Records in Austin:
Sure you could probably whip that up in a JavaScript application, but envision this scenario: an animated car traverses the route of your roadtrip; your videos are overlaid onto the map at their original shooting locations; and your meticulously selected playlist of driving music plays chronologically in the background. And that, my friends, is the power of Flash.
Hi, I’m Sterling Quinn and I work on the development team for server-based GIS technologies at ESRI in Redlands, California. We’re happy to report that ESRI software users can now expose their GIS in Google Maps through the recently-released ArcGIS JavaScript Extension for the Google Maps API. The extension is built on the Google Maps API and is designed to communicate with ArcGIS Server, ESRI’s product for serving GIS functionality on the Web.
The ArcGIS JavaScript Extension for the Google Maps API allows you to maintain the user-friendly front end of Google Maps while tapping into an advanced GIS on the back end. You can use the extension to display your own maps on top of Google’s, query features in your database and display them on the map, or expose tasks that run GIS analysis models on the server. You can display your results using the Google Maps API’s native graphics engine and info windows.
To learn how to use the ArcGIS JavaScript Extension for the Google Maps API, use the online SDK, which contains basic concepts, an API reference, and examples of how to create custom maps and Mapplets. The examples contain detailed descriptions on how to do things like adding an ArcGIS Server map type button, displaying query results as KML, or running a task on the server to return a route and elevation profile.
Following are some quick links to example Mapplets built with the ArcGIS JavaScript Extension for the Google Maps API. For those of you who don't know, Mapplets are mini applications that you can add to Google Maps in the “My Maps” tab and are nifty because a user can enable multiple Mapplets at a time.
Displays an ArcGIS tiled map service over the Google base map.
Retrieves US Census data from an ArcGIS map service at a point you click and displays it in a series of charts created with the Google Chart API.
Uses an ArcGIS geoprocessing service to tell you where a bottle would drift if you dropped it in the ocean.
Uses an ArcGIS geoprocessing service to display drive time polygons from a point you click.
This has been a busy week! We've released four new resources to help you with the Google Earth API.
We also released a number of samples which demonstrate small examples of code for the Earth API. Everything in the project is under Apache 2.0 license, so feel free to borrow it for your own.
Howdy, y'all. My name is Roman Nurik and I'm a newly minted member of the Google Geo APIs team. Some of you may already know me from the Earth Browser Plug-in Google Group. I recently started at Google's headquarters after 4 years at Boston University studying Computer Science and Marketing. My task here at Google is to help you all become experts with the Earth API and KML. In about 5 minutes, you'll realize how psyched I am about it, too.
Back in May before I joined the team, I remember reading one day that Google had released an Earth browser plugin. It really felt like a great moment; finally, immersive and lifelike exploration of geographic content was available to end users on the web, for free. Web developers were also given a cutting-edge tool to marry their existing geo-aware web apps with Google Earth, in all its spherical 3D glory (Maps/Earth integration mode ala G_SATELLITE_3D_MAP).
A few days after I started at Google on the Earth API team, I found a video of Paul Rademacher's Google I/O talk introducing the plugin. It got me thinking—if we can do fun stuff like drive a milk truck around a city crowded with 3D models of real buildings, and fly said milk truck off of our favorite local mountains, can we take this first-person-driver (FPD) concept and apply it to a more real-world problem? The problem of, say, familiarizing yourself with a new driving route before embarking on it in real life? The answer was clear: of course we can! And in that moment, the idea of an Earth plugin driving directions simulator was born!
After a surprisingly short time fiddling with the Earth and Maps APIs, the first version of the simulator was up and running. Pamela Fox and Mano Marks contributed some ideas and suggestions and the app grew rapidly! Today, I'd like to share the final result with all of you: the Google Earth Plug-in Driving Simulator. Please give the app a spin! Since the plugin currently only supports Windows, users who prefer Mac and Linux will need to borrow a Windows machine. Also, special thanks to the talented artist who contributed the Smart car model used in the app to 3D Warehouse.
Some screenshots (because 3 pictures are worth three thousand words):
The driving directions backend is powered by the GDirections API, which IMHO is a rock star. I also used jQuery, one of my favorite JavaScript libraries, to take the brunt of the work out of Firefox and IE compatible DOM manipulation.
If you have questions on how everything comes together, definitely post them to the previously mentioned Earth plug-in group and I'll be sure to clear things up.
I've had a great experience writing this small app and I'm really psyched to help you all get pumped up and ready to code with the awesome new Earth API. For those of you who haven't tried it out yet—what are you waiting for? As with all of our APIs, the developer community is growing and providing free support at the Earth Browser Plug-in Google Group if you run into trouble. We'd also love to see the cool stuff you're working on!
Thanks for reading; have fun with the driving simulator app! Even more so, have fun with the Earth API! And as always, stay tuned to the Geo Developers blog for more Earthy goodness.
Give us feedback in our Product Forums.
Follow