After much delay, possibly due to government meddling, Google Street View finally went live in select Canadian cities last week! Most of the GTA is covered, along with Kitchener/Waterloo, Ottawa, Montreal, Quebec City, Halifax, Calgary and Vancouver. This likely ensures coverage for a majority of Canada’s population, if only a very small minority of its geographical area.

This is a welcome move, since street view has been available for our neighbours to the south for the past two years.

According to some reports, Street View was supposed to launch in Canada earlier this year, and some of the imagery was collected as early as 2007. (Though the images around my area seem to be from early this year) Oh well, this is better late than never!

I’m speculating that the government’s concern with Google Street View may have slowed deployment, as in 2007 the privacy commissioner voiced strong concerns against the technology. I’ve never believed any of that FUD, but it seems that their concerns have been addressed with Google’s automatic detection and blurring of faces and license plates, along with new straightforwards processes to request that your image be removed from the service.

But it’s still been much ado about nothing, not really like the conflict between the government and Facebook earlier this year, which was also subsequently resolved. In the case with Facebook, privacy settings were often complicated and unclear; with Google Street view, they’re merely providing public views of public places, so I don’t see what the problem with that is.

Also available on the iPhone/iPod Touch

You can also use Street View on the built in Maps app for the iPhone OS, though it’s a bit convoluted since there’s no “Street View” button to toggle. Instead, you must first drop a pin (click on the “layer peel back” icon in the lower right corner) and then bring up the dialog box for that pin. If it’s in an area with Street View present, the little guy icon on the left will be lit up and you should be able to click it to bring up Street View.

Street View only works in landscape mode but it’s still pretty useful for getting to know an area before you visit it for the first time. Sometimes an actual image can convey sense better than just a map.

Competition?

It remains to be seen how the launch of Street View in Canada will fare for the similar service launched by Canpages in BC. That service only covers Vancouver, Whistler and Squamish but was launched back in March.

Nonetheless, it’s very neat technology, even if it was originally unveiled over two years ago. Witness this by the fact that reporters are still drooling over it by embedding the service in every article covering the launch.

When Google launched App Engine about one year ago, many were excited about their expected move into the cloud computing space, but at the same time, dismayed that it only supported Python, a language seemingly favoured at the Mountain View-headquartered company.

However, Google was adamant that they would begin supporting new languages and began taking requests on their issue tracker for what language to support next. So, it was no surprise that support for Java was announced last week as part of an “Early Look” at the feature.

I qualified for signup!

The Google App Engine page indicated that access would be limited to the first 10,000 developers who signed up, but I was able to get approved for access after signing up over the weekend, even though Java support was launched last Wednesday on April 8th. Google has since expanded the “early Look” to accommodate a total of 25,000 developers, so be sure to sign up if you can!

The choice of Java as the next language to support was no big surprise, as indicated by many articles speculating on the matter.

Furthermore, Java is one of the most popular languages out there, both outside and inside Google, making it a logical choice. This is seen by the numerous Java projects Google has created/supported, such as Google Web Toolkit and Google Guice. Additionally, Java is second to none when it comes to a viable developer ecosystem, which has resulted in great open source projects such as JBoss, the Apache Commons collections, and other libraries/frameworks that have provided great tools to any Java developer, allowing them focus on developing their application instead of worrying about lower-level problems. There are also a great many websites out there running on J2EE, such as LinkedIn and numerous corporate websites.

App Engine as a enabler for free/cheap Java hosting

However, this hasn’t translated into the availability of cheap web hosting for J2EE/Java development. Typically, web hosting for a shared-server solution will be only a few dollars per month if you’re using a scripting/interpreted language like PHP, Python or Perl. If you want to develop Java web applications though, you’ll likely have to pay much more due to the complexity and overhead of the hosting provider having to run a Java VM.

As outlined in this somewhat overly optimistic article, Google’s support for Java in App Engine has the potential to change the game by offering a cheap/low-cost, or in most cases, a free solution to allow developers to begin creating J2EE/Java-based web applications. This will have the effect of encouraging greater adoption of J2EE as a server-side solution. In my opinion, the high cost of Java web hosting has indeed hampered its adoption by the community, as compared to alternatives like PHP, Python and Ruby.

Hello, World

As for me, I’m currently devoting my free time to experimenting on App Engine using Java. So far, the documention and tutorial seem to be fairly well-written and easy to follow, and for the most part App Engine is using the standard Java APIs for providing most of their service functionality. Furthermore, Google has made an excellent Eclipse plugin for App Engine Java support, which provides not only the SDK, but also a built-in development server/Jetty-based servlet container for local testing, but also the tools necessary to upload your application to Google’s servers directly from the IDE. Another reason why Eclipse is the best IDE out there.

I hope to have something working within a few days, at least to test the service and play around with its capabilities. Overall, I’m very impressed!

Like many, I’ve been using Chrome occasionally ever since it came out back in September.
I never really had any problems with any sites, and was impressed with how fast it left the “Beta” stage, considering Google’s affinity for the term.

Initially, I had no problem using Hotmail with Chrome. (Yes, I still have a Hotmail account from years ago, even after switching to Gmail for almost all of my needs) But recently, it stopped working for me – basically, I could go to the Inbox, but clicking on any of the messages or trying to compose a new email would not working. Basically, none of the links worked. I can’t pinpoint the exact date that this occurred, but it was likely after an update to the Hotmail site.

The fix is really quite simple, which I found on the Chrome Help Forums. You just need to alter your shortcut to Chrome to add an option/parameter when it’s run. If you right-click the icon/shortcut that’s used to launch Chrome, you should see something like this in the “Target” field:

"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe"

Change it to this, adding the --user-agent option to the end.

"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1 Safari/525.1"

Note that in the above two examples, user name is meant to be the folder of the currently-logged in user. Change as appropriate. Note that even though the help forum is talking about the 2.0 Developer Beta version, I found that this fix worked with the latest 1.0.154.43 release.

From what I gather, this “fix” just makes Chrome identify itself as another type of browser, which apparently makes Hotmail serve up the proper pages to Chrome. If this is true, this would mean Microsoft deliberately disabled Hotmail for Chrome users. This would not be surprising, as Google has been trying to sway users away from Internet Explorer (especially 6.0) by recommending other browsers (such as Chrome) when using Gmail.

It appears that the Browser Wars are again moving into webmail as a sort of proxy battle.

A few things to note: Firstly, while the act of promoting or removing a search result seems very akin to Digg, the result is not the same. The changes you make only affect your own search results, and Google is very clear on this. However, it would be madness to believe that Google would not use the data gathered from this social experiment to further improve their algorithms. You also have the option of adding your own results to further personalize your searches and there is an option for seeing what others have recommended/promoted or removed, providing for an interesting social experiment.

Secondly, as this WSJ blog notes, this ability may annoy people who have used SEO tactics to improve their site’s placement in Google’s search rankings. However, I find this complaint misses the point: Search is supposed to simplify people’s lives, and if they’ve promoted or removed a link it was because they found something to be more useful or irrelevant.

This isn’t yet a “wisdom of the crowds” approach to search results, but its undoubtedly a step forward towards a hybrid approach that takes in more human input to determine the quality of results and their placement. One can only hope it will improve with time!

The Google Chart API is a great way to dynamically create chart and graph images for any non-static data you might want to display to your visitors, such as stats for a runner’s training log.

Although you can use your own server-side solution for generating charts, using PHP’s GD Image Processing Library or even a fancy chart library like pChart, this can increase the drain on your server’s resources. Client-side solutions that utilize the canvas element and jQuery or Flash can be very nice and easy to use, but may slow down the browser if there are a lot of charts.

Google Charts offers a nice trade-off; by using their service you offload the processing and bandwidth and get back a simple PNG image, but you must learn to use the API. Additionally, there’s also the risk that the service may throttle you, even if there’s no current usage limit.

Problems specifying Axis Ranges – Data points are not changed!

The API for Google Charts essentially consists of passing different query string parameters and their values and getting back a PNG-format image. As a result of this, passing in parameters is a bit quirky, and information in the API guide is a bit sketchy in this respect.

One such example with quirky behaviour is properly setting the axis’ ranges, or scales, of a chart. By default, all charts are set up on a 100×100 grid. It would seem that by changing the axis range, these values will be adjusted accordingly, affecting the position of any data points you’ve plotted.

But this isn’t the case; instead, changing the axis range with the chxr parameter only adjusts the position of any axis labels you might have, and does not affect the position of data points. Instead, data points will continue to be plotted as if they were on a 100×100 grid.

Illustrating the problem

The following examples illustrate this point. We plot a set of points, {(10,40),(30,60),(50,70),(70,20),(90,40)} using an X-Y line chart. The first chart illustrates the points on the default grid of 100×100. Because axis labels/positions have not been specified, the chart has been filled with default axis labels, which are values in the respective positions.

URL: http://chart.apis.google.com/chart?chs=200x200&cht=lxy&chd=t:10,30,50,70,90|40,60,70,20,40&chxt=x,y&chg=10,10&chm=o,0000FF,0,-1,5,0

In this case, the points are plotted in the correct positions. (Points have been highlighted with markers for clarity and grid lines spaced 10 units apart)

However, if we simply change the axis ranges by specifying the chxr parameter to be chxr=0,0,200|1,0,200, the axis labels change, but the data points are not properly scaled:

URL: http://chart.apis.google.com/chart?chs=200x200&cht=lxy&chd=t:10,30,50,70,90|40,60,70,20,40&chxt=x,y&chg=10,10&chm=o,0000FF,0,-1,5,0&chxr=0,0,200|1,0,200

This is further evidenced by the grid line spacing; though it’s still set to 10 units, the lines would appear to be 20 units apart in the above graph. This means that internally, the chart is still using a 100×100 grid. So, how do we fix that?

Plotting data properly with axis ranges

The documentation would benefit from being clearer in this respect.

In order to properly scale data, you must use data scaling whenever you adjust the axis ranges to non-default values.

For the above example, since we have set both axis ranges to 0-200, we must set the data scale of both data sets (X and Y values) to 0-200 as well. We accomplish this by setting the chds like so:

chds=0,200,0,200

The resultant graph is now as expected for the given data points:

URL: http://chart.apis.google.com/chart?chs=200x200&cht=lxy&chd=t:10,30,50,70,90|40,60,70,20,40&chxt=x,y&chg=10,10&chm=o,0000FF,0,-1,5,0&chxr=0,0,200|1,0,200&chds=0,200,0,200

(Curiously, grid lines are still placed 10 units apart according to an “internal” 100×100 grid.)

I couldn’t find anything clear in the documentation about this, but instead found some helpful threads on the Google Groups for their Charts API that aided me in figuring out exactly how this all works.

Clear as mud?

There are still some things I’m not clear about, such as what data scaling is actually supposed to mean, and why simply changing axis ranges does not properly scale data in the first place. Additionally, the data formats page specifies numerous other ways of specifying data in more compact, encoded forms, but these formats do not seem to support data scaling. Does that mean these formats are confined to a 100×100 grid?

I haven’t had the time to fully experiment with the API, but hopefully will have time to learn. In the meantime, I hope you found this information useful. If you have some information I haven’t presented here, please don’t hesitate to comment below!

Note: The information and graph images here reflect the state of the Google Chart API as of the date of publication. (2008-11-06)

On Thursday, Google rolled out an update to its personalized home page service, iGoogle. Among other UI updates, the major new features were increased flexibility in what “gadgets”, the personalized “chunks” that make up an iGoogle start page, can do. This, in turn, allows developers much more freedom with what they can provide to the user through an iGoogle gadget.

Previously, gadgets could only occupy a small box that took up only a third of the screen. While this was okay for reading headlines or perhaps glancing at stock prices, it limited the usefulness of gadgets and the information that could be provided. For more detail, users would often have to click a link in the gadget that would take them away from iGoogle. While this is perhaps the proper use of a “start page”, Google may now see things differently.

Life is a great big canvas

Gadgets now offer a near full-size “canvas” mode, where the gadget is expanded to take up most of the screen. This allows more information to be displayed and makes the iGoogle page less of a start page and more of an aggregator – like an RSS reader, but with much more.

Speaking of RSS readers, any RSS feeds on iGoogle can now be expanded into a full-feed view, using a layout/interface not unlike that of Google Reader, their specialized RSS reader product. All of these enhancements are designed to help you get the information you want, without having to leave iGoogle.

Some good examples of gadgets taking full advantage of the new functionality offered by the new iGoogle include the GasBuddy gadget, which display a small labeled map of local gas prices in the “mini” mode, which expands to a fully-searchable map complete with a clickable legend in the full-screen canvas mode.

Google’s own products, such as the Gmail and Google Calendar gadgets, have also been updated to nicely take advantage of the new abilities. In canvas mode, each gadget expands to fill the screen with pretty much the same UI as their respective web applications. This makes accessing your various Google Account services easier and decreases load times.

Content and Money

Others include the Wall Street Journal’s gadget, which in canvas mode looks similar to a start page of its own. Interestingly, ads are shown in this mode, presumably from the WSJ itself. This highlights another important aspect of gadget development: Income.

This is really the crux of the iGoogle update, in my opinion. By allowing giving more power to developers and allowing more content to be shown on iGoogle, developers can have more flexibility with their creations. In return, Google is apparently willing to allow them to show ads so they can make money off of their creations, which clearly add value to iGoogle.

It’s hardly an original idea. Facebook has had their own applications platform for well over a year, with much of the same ideas. Facebook Apps are made by third party developers, and mostly run “within” the confines of the main Facebook site, keeping users on the site. In return, developers can also choose to run ads in their application to generate revenue. It’s a very similar model. (Facebook recently awarded some of the best apps through their fbFund initiative, with the promise of more money to come – perhaps Google will do the same? They’ve already done something similar with Android in order to spurn development)

Not so fast

Unfortunately, the changes were not all good. For one thing, the vast majority of existing gadgets haven’t been rewritten to take advantage of the full canvas mode. In all likelihood, many will not, since third party developers may do as they like. Gadgets that haven’t been updated will merely be displayed besides a huge “You might also like…” list of recommended/related gadgets when displayed in full-screen canvas mode.

Furthermore, some users have complained about the UI updates. In particular, the mandatory left sidebar now in place has caused some to lament the loss in screen real-estate. Previously, tabs were only shown on top if you had defined more than one; now the list of tabs, along with the iGoogle gadgets in each one, are shown in the sidebar no matter what.

Indeed, such a display might be superfluous if there’s only one tab. At the very least, Google should have allowed the sidebar to be collapsed or tucked away. (I won’t be surprised if they implement this change in the next few days, or already have it planned)

Also surprising is how Google rolled out the new version so suddenly, effectively forcing all users to adopt it. A better approach would have been to roll out a “beta” version (we all know how much Google is in love with beta) and allow users to preview it and optionally switch. This would allow them to get more feedback before switching everyone over, like Facebook did with their new redesign, which effectively took months to take effect.

However, given that iGoogle’s user base is likely a very small percentage of all the users who have Google as their start page (with most just preferring the stripped-down original search page as their starting point), perhaps Google believed that rolling out the updated site would affect so few that a beta period wasn’t really needed. In any event, the changes are not so ground breaking to warrant serious concern.

What’s good

On the positive side, there are some reports that Chrome’s market share has already surpassed that of Opera, coming in at close to 2.5% when I last checked. These results should be taken with a grain of salt, as Clicky’s web analytics might only be used by websites that tend to be visited by those more technically-inclined and thus more likely to try out something like Chrome. (Though Chrome’s visibility on Google’s main page no doubt has some small part in its fast growth)

For what it’s worth, Google Analytics on my lowly-trafficked site amounted to over 4% of hits in the past five days. (Google Analytics has since started identifying Chrome as a specific browser type, no surprise)

Chrome browser share on my site

What’s iffy

While the V8 JavaScript engine of Chrome was reported to be fast (myself included) Mozilla has fired back with their own results when compared to the upcoming Firefox 3.1, which also features a newer, faster JavaScript engine dubbed TraceMonkey.

Even if this only manages to bring Firefox 3.1 to within striking distance of Chrome for JavaScript performance, it’ll still easily hand the win over to Firefox 3.1 considering its much larger established base and support for extensions/addons.

Microsoft, meanwhile, still seems to have their heads in the sand when it comes to IE. True, IE7 still have a substantial margin on any other browser but that lead has been steadily sinking. Though IE8 will likely be a vast improvement over IE7 and seeks to erase all memories of the abomination that was IE6, it looks like Microsoft will have its work cut out with the stiff competition from Firefox and Chrome.

Problems

The release was not without controversy, as since this product was from Google, many privacy concerns were voiced. There were concerns about the “GoogleUpdate.exe” process that is installed with Chrome, which apparently allows for higher privileges to install software, which understandably freaked out some users. Generally, unwanted processes running in the background are just the thing the tinfoil-hat wearers are looking for.

Additionally, some keen-eyed users who perused the EULA discovered that Google had apparently tried to claim ownership of all content posted through Chrome. (Who actually reads a EULA?) Evidently, it was all a mishap, as Google quickly moved to correct the errors in the TOS. Apparently, in the rush to release Chrome, a “standard” TOS was used as the basis for the EULA, most likely similar to the ones covering services like Blogger, etc.

My own experiences

Personally, I’m very pleased with the browser. The “application shortcut” feature is very nice as it makes web apps like Gmail integrate very nicely with the desktop. I can’t wait to setup my Mom’s computer with shortcuts to things like Gmail that will undoubtedly make her life easier.

The JavaScript performance is very fast compared to other browsers, but some things like Flash are still buggy at times. This has caused problems with sites like Google Finance (which uses Flash for the charts) and YouTube, which are ironically Google’s own services.

I guess the “Beta” tag and the lack of a full version number excuse these problems, though it looks as if the list of bugs is already quite extensive. Google’s bug tracker for Chrome lists over a thousand bugs/feature requests currently, though likely many of them are duplicates. (Google is, however, following the trend of using the “Beta” moniker in an increasingly loose manner)

After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome – it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page – no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list – this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well – the combined address bar/search bar is very much like Firefox 3′s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials – and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

This made it somewhat tedious to decode them, as the only way to get the original list of points was to create a GPolyline and then pull out the points from that object. This is not ideal since the work must always be done on the client side with JavaScript and using Google Maps.

To solve this, I quickly ported the algorithm over to PHP from the JavaScript source. Please feel free to download/modify/use this script.

Since the encoded polyline format offers numerous benefits (and because I had data already stored in this format) I did not want to move away from it. At the same time, I needed access to the points for working with things like Google Static Maps, which curiously does not accept the encoded polyline format for displaying paths. (Probably to reduce resource usage on their end, since decoding takes CPU time)

Thankfully the polyline decoding algorithm was already available at Mark McClure’s site. I spent a few minutes understanding the process and porting it over to PHP. The source is attached above and is released under an MIT license. Basically, the only change I had to make was to use some PHP functions to convert characters to their ASCII code, since PHP doesn’t have a charCodeAt() function.

Please let me know if you find it to be useful.

Projects using this

• VORG Tool

I’ve just starting playing around with the Google Static Maps API as a complement to the regular Google Maps API, which as you probably know, is for JavaScript. The Static Maps API, on the other hand, provides a way to display static map images. This is useful in situations where you just need a non-interactive map and don’t want the overhead of an Ajax/JavaScript-based one.

However, I ran into some minor problems related to the API key usage with the Static Maps. Basically, an API key is tied to a certain domain name so that Google can keep track of your site’s usage. This means that the API key is tied to the domain name of the web site where you’re using the Google Maps API.

As in most development situations, I maintain a production server (with a real domain name) and a test/sandbox/development machine, which is just running off of my localhost. Thus, I had to get two API keys – one for the real domain name, and one for localhost and then switch between the two depending on the host name. (In PHP it’s fairly easy to check, using something like $_SERVER['SERVER_NAME'])

However, with the regular JavaScript-based Google Maps, it appears that if you’re running off of localhost (not 127.0.0.1) the service doesn’t check if you have a valid API key – this was probably done because many people are probably running test servers off of localhost and trying enforce usage limits would be counter-productive. (You do, however, need to have a valid API key – even if it doesn’t match localhost – if you want to use GClientGeocoder to resolve locations)

Because of this, at one point or another, I decided just to stick with using the production API key in all situations; after all, things continued to work even on the development server and in general, I don’t like making changes just for testing purposes.

This ended up causing problems when I started using the Static Maps API though. It turns out that this API does require you to have a valid API key matched to the host name in all circumstances, even if it’s localhost. This, of course, is the proper behaviour, but it differs somewhat from the behaviour of the standards Google Maps API.

Guess it pays to be correct in all situations, even if you don’t need to be!