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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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