(Skip to main content.)

Blogs Quoderat Land and Hold Short

Quoderat

Archive for July, 2008

Detecting overzoom in Google Maps

Sunday, July 27th, 2008

Here’s a link to a web page showing how to detect overzoom with the Google Maps API.

Overzoom is a big issue for my site OurAirports, which shows a close-up satellite view on each airport’s page (e.g. the former Meigs Field). Unfortunately, there’s no documented way to use the Google Maps API to check if a satellite view is overzoomed (instead of a satellite picture, it’s showing the “We are sorry, but we don’t have imagery at this zoom level for this region…” message). That can be confusing for someone who isn’t a regular Google Maps user and hasn’t actually touched the zoom controls on the map.

The hack

The page above came up with the clever solution of counting paragraphs in the map container. If there is a “sorry” message, there will be HTML p elements inside the map container. Here’s a simple JavaScript function that checks to see if the map is overzoomed, and zooms out one level if it is:

function check_zoom (map)
{
    var zoom = map.getZoom();
    var count = map.getContainer().getElementsByTagName('p').length;

    if (zoom > 1 && count > 0) {
        map.setZoom(zoom - 1);
    }
}

Note that it doesn’t iterate — it just does one check and exits. The easiest way to use this is just to have it run every two seconds or so. If your map is available in a variable named map, this will do the trick:

setInterval("check_zoom(map)", 2000);

Examples

To see how it works, check out Vuotso Airport in Finland. Google Maps doesn’t have very good satellite coverage for Lapland in the far north, but OurAirports now detects that after a couple of seconds and zooms out one step. For a more extreme example, look at Alert Airport, the world’s northernmost permanent airport, in Nunavut, Canada — the code has to zoom out several times until you can see anything in the satellite view.

Caveats

The more elegant solution would be to detect when the map is finished loading after every event that can affect it, but that sounds like too much work to save a couple of milliseconds here and there.

Note that Google can break this at any time simply by adding or removing p elements — it would be much better to have an official, reliable way to detect when a satellite view is overzoomed.

Widgets vs. Portlets

Monday, July 14th, 2008

Widgets are web pages embedded in larger web pages, generally using iFrames — the content comes via a separate HTTP connection and has its own CSS stylesheet, cookies, etc. Final composition takes place in the user’s browser.

Portlets are software modules that produce fragments of HTML markup that are assembled into a single HTML page, sharing common CSS stylesheet, cookies, etc. Final composition takes place on a portal server, and a single page is delivered to the client browser.

Features

Portlets have a lot of features that iFrames don’t: they require fewer HTTP connections, they allow for common styling (one CSS stylesheet can style all the portlets on a page), and they can communicate with each other and take advantage of common authentication/authorization, etc. (so that a user doesn’t have to sign on to each portlet separately).

Portlets use a window-manager metaphor, allowing the portlet server to resize them, expand them etc. They also have modes, like edit and view, all of which can be accessed through a common interface. All of this happens on the server side.

iFrame-based widgets don’t normally do any of that, but they don’t require special portal servers, they can be embedded in more creative ways, and they offload the processing from the server to the client. They also introduce potential security holes, but only if they’re hosted somewhere that’s not under the original company’s control (the same applies to remote portlets using WSRP).

Users

Portlets are used mainly in intranets, to provide a collection of enterprise apps on a single web page for employees (e.g. a news feed, calendar, expense forms, bug reports, etc.).

Widgets are used everywhere else (e.g. embedding Google maps, Facebook applications, etc.). While widget authors/consumers don’t tend to know (or care) much about portlets, the portlet people haven’t failed to notice the popularity of widgets — most (if not all) portal servers now have an iFrame portlet that does little more than wrap an iFrame and allow it to be resized, etc.

Future?

Are the extra features of portlets compelling enough to justify the extra cost and hassle of running a portlet server? Now that we have browser tabs, AJAX, etc., do enterprises really need to continue to squish all their apps into a single web page that looks like a 1995 Mac desktop gone bad?

My guess is that the only portlet feature with compelling benefits is common authentication/authorization — once the web community gets behind a solution to that problem (OpenID or something similar), widgets will probably push portlets out completely, even in the enterprise.