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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Client-Side Performance
- Tibbo Technology's Tibbo Project System
- July 2016 Issue of Linux Journal
- Sony Settles in Linux Battle
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- The Giant Zero, Part 0.x
- Profiles and RC Files
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide