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 in our API. AIR has a different security model, which required a number of changes to the "internal plumbing" of the API in order to implement our delayed-loading model, where the actual implementation of the map's functionality loads dynamically from Google's servers once the application launches. Also, our Terms of Service used to specify that the Maps API could only be used for online 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.
Give us feedback in our Product Forums.
Follow