Slashdot Mirror
Beginning Google Maps Applications with PHP and Ajax
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.
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.
There's a whole book for this?
When I was a kid, we only had one Darth.
So what are some of the better mashups out there? The sex offenders one and the gas prices one are both quite cool. What other decent ones are there?
Warhammer forums
There are very small number of people and businesses who are able to put forward such capitals that might dwell on ajax apps, and dependencies on third party sources like google and try to establish a youtubeish, or some other service. (youtube is given as an example to imply a big operation)
Almost 80% of the web development market is comprised of small businesses or individual investors, who do not care the slightest for ajax widgets, mumbo jumbo or the such when they start an online presence. Their problem is, selling their wares, or services via a secure, easy and clock-like working site.
Much hype was done around this ajax, yet we as web developers still are not seeing any demands on ajax stuff in contracts. And the ones that there are negligible when proportioned to the whole.
Im increasingly starting to see this ajax thing as a new "techno trend" that is pumped up and put forth by genius-tech-wizz kids (net celebrities) who did big business with similar things in the past.
The catch is, market does not need it.
Read radical news here
Microsofts Virtual Earth API is much better than Google's. As an example, Microsoft's API allows you to obtain driving directions, Google's API does not. Google is "considering it".
i le.ashx).
Also, on the client side, I believe that Microsoft's birdseye view at local.live.com is amazing. As an added bonus Microsoft provides live traffic data with their maps (Google doesn't). Also there is a Microsoft Virtual Earth client for the PocketPC, which includes source (http://www.viavirtualearth.com/vve/Gallery/VEMob
I think Microsoft was behind but caught up and passed Google very quickly on this.
The main problem I have with the Google Maps API is that the dataset that they let non-paying users use for Geocoding (extracting the Lat/Lon from an address) is not accurate. Yahoo provides Geocoding with much much better accuracy. So, if you need accurate Lat / Lon data, you'll have to fold both mapping technologies into your app (get the lat / lon of an address from Yahoo, plot on a map with Google. Or just use Yahoo and skip Google).
If you want news from today, you have to come back tomorrow.
One of these days, it will be a good idea if the FOSS community gets together with some trend-setting companies, and invents a single language for the web. Instead of combining many different things that were invented for many different purposes, it would be a purpose-built language that will provide all the the client-side interactivity that users expect and all the server-side operations that content providers need to supply. Whether it's the AJAX-style interactivity you seek or the Flash-style content, the web is expected to do much more than the mess of languages that implement it are capable of without some 1337 h4x0ring.
Google maps API is still very much in development with new features coming out all the time. When they switched from v1 to v2, there was a lot of converting to be done to make maps work correctly. This book will be out of date in no time. Can't see the need for it when you have an active mailing list and sites such as mapki available.
Save yourself $5.95 by buying the book here: Beginning Google Maps Applications with PHP and Ajax. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
You heard the man! Let's get cracking on WebForth immediately! Imagine... all the interactive capabilities of the web combined with the ease of programming of Forth! What could be better?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I find Mapki and Mike William's Tutorials more than sufficient. A quick glance at the API group's mailing list also helps.
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
yes they do. read the agreement with google about not being allowed to use the maps for commercial applications. you'll find that after about an hour of using the maps consistantly, explorer and firefox start using a buttload of memory. this book is fine for people who want to whip up a quick map etc.. but i do not reccomend anyone using google maps on anything with extensive reloading of the maps.. just my 2 cents.
Those interesting in the topics should take a look at the Google Maps Hack book (review here).
Anyone whom have interest in Google Maps API must take a look at the numerous alternatives. Which includes OpenLayers.org (which just released v2.0). There are various other alternatives, all with different levels of interoperability and compatibility with OGC standards. On the subject, see slashgeo's web mapping section.
.
Animoog.org
Sure these technologies are great but standalone mapping programs are "obsolete"? There are still many applications that require a standalone application. ESRI isn't quite out of business. Anyone actually interested in providing map services on the web should be first using and understanding the current GIS packages. This will keep you from having lots of headaches when it comes to projection issues, etc. There is no need to reinvent the wheel 100 times.
You're just working on the wrong kinds of apps, apps where "AJAX" is just a parlor trick to show that you're a really hip developer.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Nobody cares about Euroscum like you.
Sure, they have the right to charge whatever they want, but damm, who is going to adopt it at that rate just to add some cool mapping features? Everyone can use the technologies, but few will spend those dollars on mapping alone. I fear Google maps is doomed to the "Cool-Hacks" purgatory.
There's Microsoft's Live Local and Yahoo! Maps that are also data-filled. But you're right, data is the next intel inside. You can look at OpenStreetMap, the best open data project amongst the community.
Animoog.org
I agree that this book will be quickly out of date, but either Google or a third party really needs to put together a web-based, comprehensive, step-by-step instruction guide. The "documentation" http://www.google.com/apis/maps/documentation/ that Google has up is very limited and doesn't address even some of the more basic things that a map-newbie like me needs to know (some of the simple things like placing a locator or geocoding wasn't obvious to me). I had to search the forums, etc to get the answers I needed, and even then it wasn't that easy. What would be nice is a comprehensive application that builds everything one would need to create a map (hint hint programmers). Some kind of GUI that's super easy that says: put locator here. Add satellite/map/hybrid options. Create clickable marker...etc. And viola, the code is generated and you cut and paste into your page.
Health Insurance Quotes
Has anyone checked out "Ajax And Php: Building Responsive Web Applications (Paperback)" If I can only afford one of these books, should I get this one or the one reviewed here on /.
Anyone have a torren for this?
He announced info about his book on our class forums (tron09.com). Not bad for a 2nd year Eng student :P. Congrats!