At the Forge - Google Maps
During the past few months, we have looked at a number of Web services. Web services is a catch-all phrase for the ways in which Internet companies are making their data available to the general public, for use in people's own applications. Thus, Amazon makes its product catalog available for us to create on-line stores and pricing programs, eBay allows us to search through (and bid on) products available for sale, and Google makes its search results available for viewing and manipulation. Each company restricts the ways in which we are allowed to use the provided data, but the trend appears to be toward additional openness and availability.
This month, I explain how easy it is to create maps using the Google Maps API. We create some basic maps and even put up small markers indicating locations of interest to us. This will serve as a building block to creating our own mashups, the increasingly popular term for the use of Google Maps to display information culled from a separate database.
Now, we have seen this sort of restriction before, both in Amazon's Web services and also Google's main Web services (that is, for search results). However, the key used in Google Maps is somewhat different; it is keyed both to a particular person (with a Google account) and to a particular URL. This means a map key that works at http://www.example.com will not also work at http://www.example.net.
The first step in using the Google Maps API is to decide under which URL you want to put the maps. I decided to create a new Apache virtual host on my system, which I named maps.lerner.co.il. I then registered with the Google Maps API page (www.google.com/apis/maps), indicating that my applications would be under the URL maps.lerner.co.il. Several seconds later, I was greeted with a page containing my API key, as well as a simple starter page that can display a map. The key is a very long string of ASCII characters, separated by spaces.
Because we will base our applications on HTML, we should take a close look at it:
The HTML document begins by declaring its DOCTYPE, which turns out to be strict XHTML. XHTML is a wonderful idea and ensures that HTML is structured according to all of the strict XML rules. That said, many HTML pages do not adhere to this standard and thus are considered either transitional (meaning, XHTML with a liberal eye) or nothing at all. Because Google Maps tries to be compatible with as many browsers as possible, it benefits greatly from strict adherence to XHTML.
Inside of the div, we finally get to the heart of the matter, with three calls.
First, we create an instance of a GMap object. As you might imagine, a GMap represents a particular map within the world of Google Maps. We attach the GMap object to the node with the ID of map. (If the element does not exist, the map will not appear on the screen.) This means, by the way, that you can have more than one map on a particular Web page—simply create multiple <div> tags, each with its own unique ID attribute, and attach different instances of GMap to each <div>.
Once we have created an instance of GMap, we can send it messages to control its behavior. For example, we can add a control to it, allowing us to zoom in and out. In this document, for example, we add a small map control by invoking the addControl() method, passing it a new instance of GSmallMapControl. The GSmallMapControl contains +/– buttons for zooming, as well as arrow buttons for moving the map without having to drag the mouse.
Google provides two other control types as well, known as GSmallZoomControl (which has only the +/– zoom buttons) and GLargeMapControl (which includes everything that the GSmallMapControl does, plus buttons that allow you to jump to a particular zoom level). The controls always appear in the top-left corner of the map, and there is no way to stop you from instantiating more than one of these controls. This means if you aren't careful, you might create more than one control, leading to an ugly map and site.
After creating our map and adding a control to it, we then instruct the map to show us a particular point. Points in a Google map are represented with the GPoint data structure, which represents a single point of longitude and latitude. Longitude and latitude can be represented with either degrees or floating-point numbers; for obvious reasons, GPoints are constructed using the latter. The example document has the following call:
map.centerAndZoom(new GPoint(-122.1419, 37.4419), 4);
It is important to realize that GPoint objects are created with longitude and latitude as their parameters, and not the reverse. This is probably because Google engineers thought in terms of x and y coordinates, which are more natural for math and science people. However, coordinates are often given in latitude, longitude pairs, as opposed to the reverse—so be careful before blindly entering coordinates into a program without checking their order and meaning.
The GPoint created in this default document is in Palo Alto, California, presumably pointing to Google's offices. To look at another area on the map, simply substitute a different set of coordinates. For example, to look at Skokie, Illinois (where I'm currently living), I simply substitute a different set of coordinates:
map.centerAndZoom(new GPoint(-87.740070, 42.037030), 4);
Sure enough, when I reload my page, I'm now looking at a map of Skokie, rather than Palo Alto.
Finally, Google provides us with the ability to switch between three different views, known as map, satellite and hybrid. By default, these controls are shown in the top-right corner and appear thanks to the line:
As you can probably guess, the above line sends an addControl message to our map object, handing it a new instance of GMapTypeControl.
- Handling the workloads of the Future
- Readers' Choice Awards 2014
- diff -u: What's New in Kernel Development
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Synchronize Your Life with ownCloud
- December 2014 Issue of Linux Journal: Readers' Choice
- Days Between Dates?
- Non-Linux FOSS: Don't Type All Those Words!
- Computing without a Computer
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane