Beginning Google Maps Applications with PHP and Ajax 105
Michael J. Ross writes "Just as PHP and other Web scripting languages have made it possible to create dynamic Web pages, online mapping services are making it possible to create dynamic maps that can be customized by a Web site owner, or made customizable by a site visitor. In the case of Google Maps, this is done using the built-in application programming interface (API), which is described in a new book, Beginning Google Maps Applications with PHP and Ajax: From Novice to Professional." Read on for the rest of Michael's review.
| Beginning Google Maps Applications with PHP and Ajax | |
| author | Michael Purvis, Jeffrey Sambells, and Cameron Turner |
| pages | 384 |
| publisher | Apress |
| rating | 8 |
| reviewer | Michael J. Ross |
| ISBN | 1590597079 |
| summary | How to use the Google Maps API to make dynamic online maps. |
But first, a brief background: During the mid-1990s, the only generally available mapping applications were desktop programs with location data limited to major cities within the United States. Yet less than one decade later, those programs were obsolete, replaced by Web-based mapping services such as MapBlast, MapQuest, and Yahoo Maps. In early 2005, Google raised the bar, with its own Web-based mapping service that was far more attractive than the others. For countless Internet users, it was their first glimpse of the power of AJAX, a new combination of technologies that allows Web pages to be refreshed asynchronously, providing a faster user interface. But Google Maps later packed another feature, an API that allows Web developers to leverage the service's capabilities in previously unimagined ways.
The authors of Beginning Google Maps Applications with PHP and Ajax — Michael Purvis, Jeffrey Sambells, and Cameron Turner — are based in Waterloo, Ontario, Canada. The book was published in August of 2006, by Apress, under the ISBN of 1590597079. The publisher maintains a Web page devoted to the title, where visitors can find an online table of contents, a sample chapter (Chapter 3, "Interacting with the User and the Server") as a PDF file, and a link for submitting errata (none of which, as of this writing, appear to have been reported — assuming there are any). In addition, the authors have a Web site for the book, where they offer a sample chapter (Chapter 4, "Geocoding Addresses") in PDF format, links to raw data sources, and brief entries describing a variety of related topics, including geocoding services, Google Maps Mobile (GMM), Keyhole Markup Language (KML), and building your own geocoding using Perl.
The book's material is organized into 11 chapters, grouped into three parts. The fourth and final part contains the appendices. The three primary parts can roughly be thought of as presenting the beginning, intermediate, and advanced information. Part 1, "Your First Google Maps," whets the reader's appetite by showing how to easily create some simple maps (discussed below). In addition, it contains a chapter explaining how a Google Maps mashup interacts with the user as well as the server. The final chapter in this part discusses geocoding addresses. Part 2, "Beyond the Basics," explains how to work with third-party data, how to enhance the user interface, how to optimize and scale for large data sets, and finally what possible future directions Google may take with this API. Part 3, "Advanced Map Features and Methods," presents exactly that, covering such topics as creating custom controls and info windows, adding geometric shapes to maps, and getting the most out of geocoding, including how to work with postal codes.
The authors begin Part 1 ("Your First Google Maps") by introducing Google Maps with the two most simple examples possible: Keyhole Markup Language (KML) is an XML-like formatting language that allows one to specify the names, coordinates, and descriptions of one or more locations ("placemarks") in a single file. For anyone who wishes to avoid writing the code themselves, Wayfaring is a Web site that allows one to create and share custom Google Maps by point and click. Even though the introduction to KML is properly brief, instead of only stating that the sample coordinates were discovered manually, the authors should mention at least one simple way to find those coordinates (such as the "Link to this page" link in Satellite view in Google Maps). Nonetheless, it was wise of the authors to use simple examples to get the reader's feet wet as quickly as possible — especially for prospective readers who might skim through the rest of the book and become intimidated by the technical diagrams, JavaScript and PHP code, MySQL queries, XML markup, and mathematical formulas.
There is much to like about this book. The explanations are straightforward, the code is readable, the examples are relevant, and the writing style is approachable. The illustrations, all of which are in black and white, are well-chosen, and not overwhelming in number. In addition to showing the expected results of the sample code, they also provide enough visual incentive to encourage the reader to give the sample code a try, and perhaps develop it further into their own mapping applications.
The book is not too lengthy, clocking in at 384 pages according to the publisher (though, oddly, Amazon.com reports only 350 pages, even though the last page of the appendix reads "358"). The authors resisted the increasingly common temptation to pad the book with superfluous appendices. Instead there are only two. The first explains how and where to find location data, such as addresses and latitude/longitude points. The second appendix presents the details of all of the classes, methods, properties, constants and events defined within the Google Maps API. For some reason the authors mention "objects" instead of properties and events, but I was unable to find any pre-instantiated objects mentioned in that appendix., and I am not sure such are even possible in the API.
Fortunately, the weakest section of the book, its foreword, has the least impact upon the value of the book. It fails to perform the most basic functions of a foreword, such as explaining to prospective readers why they should become actual readers, as well as what the book covers, and how the authors are qualified to provide that coverage. Instead, its author mostly discusses his personal Google Maps Mania site, and even wedges in mention of his appearance on an NPR radio show, which has little to do with the book. He also lists his first five posts to his Mania site, the first of which contains a misspelling, which should have been caught by the book's editors, or at least indicated with a "[sic]." The best part of the foreword is the first few paragraphs, which provide a brief history of Google Maps and the hacking thereof.
Like most if not all of its titles, Apress helpfully starts this book with two versions of the table of contents — the first one serving as a high-level overview, and the second providing far more detail, listing not only sections but subsections. This is a nice touch, and should be employed by all technical publishers. On the other hand, this book does not have a lay-flat binding, which is a shame, as it makes it far more difficult to read the book with both hands free for keyboarding. With the introduction of lay-flat bindings years ago, it is inconceivable to me why it has not been universally adopted, particularly by technical publishers.
Overall, Beginning Google Maps Applications with PHP and Ajax is an excellent introduction to extending the power of Google Maps on the Web, and provides enough detail to both help and entice readers to build their own Google Maps mashups.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com."
You can purchase Beginning Google Maps Applications with PHP and Ajax: From Novice to Professional from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Let me be the first to ask... (Score:2, Interesting)
And yes, it's quite easy for anyone with a education in CS I'd say. If you can read a manual you can implement google maps.
I do. (Score:3, Interesting)
There are many applications that are just fine as "web applications". Blogs for example. Most shopping cart type applications. There may be an occasional place where sprinkling a bit of ajax fairy dust makes the application a bit nicer (altough often less nice if you are vision impaired).
There are other applications that suck as "web applications". They are now what we used to think of as "web applications"; they're just applications, but they would benefit from the scalability and maintenance advantages of web based distribution.
Map-centric applications are a good example of the latter. Your basic address to map translation, like the ancient versions of mapquest, is ok as a "web" application. But there's a lot more things you'd want to do that really suck in the round trip request/response model. Typical kinds of things: draw a box on the map and find all of the Xs (where examples of X include parking garages, burger kings, whatever) fall inside that box. Or click on a map feature and get a picture or information on it.
If you go down this interactivity path far enough, then to make a standards compliant, non-sucky implementation, you have to (1) do DOM manipulations via javascript, (2) perform asynchronous remote requests to a server. Pretty much AJAX, although not necessarily with the XML component. And people working on this problem have been doing just that, predating AJAX by several years I might add. What AJAX does is give a buzzword around which common tools to do these tasks can accrete. Which is a good thing.
We've had an open standard for years now on deliverying maps via the web: Open GIS's WMS standard. The thing is, it has no user interface component. Which from an engineering standpoint is correct, although it's hell from an adoption standpoint. You end up cobbling together too much of the application: user interface widgets, client and server side communication infrastructure. New map UI javascript libraries are taking this off your hands these days. AJAX of course is generating new communication libraries and more importantly developer expertise.
Put this all together and it means that the client end of a WMS based Internet mapping application is easier than ever. And there are terrific free WMS servers as well, notably geoserver, which has both WMS and transactional WFS (which means you can update your Internet maps from any modern GIS program or even a browser client).
But now we have Google Maps to consider.
Personally, I'd much prefer people adopt, and get behind, WMS than Google Maps, although there's always a apples-vs-oranges aspect to these kinds of decisions. WMS is an open standard, which can be used with a variety of closed and open source software. You can create a public service that can immediately be shown in your GIS system, or in NASA World Wind, or in anybody's web page becuase it IS a standard. If you are creating a client, your client can use YOUR data, or any number of public map data sources such as JPL.... not just Google. You can access WMS data from non-browser clients; I recently integrated WMS mapping in a legacy application. The only way to bring Internet based map distribution to legacy apps using Google's API would be to create a map site which is registered with Google, then use ActiveX to embed a MSIE control in the user interface.
The one thing that Google Maps does that you really might need that is hard to duplicate with WMS is scalability. Google's one killer advantage is massive storage and bandwidth. If you are FedEx and want to provide every customer with a map/sat photo of where his package is, then Google Maps is probably the only way to do it.
But aside from that, go with WMS.
Re:WHO cares ? (Score:3, Interesting)
On the one side is the financial take. Assuming your numbers are correct, how much money is behind the 20% of 'big business' sites do you think?
Are you truly suggesting that rich web applications are something that doesn't make these companies money?
Is it impossible for widgets and templates to be wrapped up in a nice customizable package and sold to smaller businesses for very affordable rates?
Wait a sec, I'm stopping there though I could go on and on and on. (I DO apply these techs in ways that are not only beneficial, but arguably entirely depended upon, and they are used by small public organizations thank you very much!)
Your post is at the very top of this thread, modded +5, and it basically attempts to invalidate things like google maps, gmail, and other 'new techno trend' applications...Here, on Slashdot.
I have to say, wtf?
Man for mod points, that does NOT deserve +5 by any stretch of the imagination.