• SR_spatial tweets

Thoughts about Google’s Styled Maps announcement

At the Google I/O developer event this week, an impressive item was included in the announcement about the latest Javascript Maps API (v3).  Now you can use Javascript to change the style of Google’s base map, in effect creating your own CSS for Google Maps.

Yesterday’s Google Geo Developers Blog highlighted the new feature and capabilities, including a link to a style wizard – see screen shot below – so you can see in real-time what each change looks like (the wizard is kind of like ColorBrewer, without the helpful suggestions for good vs. bad color schemes and symbology).  Note that the Style Wizard won’t work in IE.

Google Maps Style Wizard

This step for Google Maps is big, no doubt, but I’m ambivalent.  On the one hand, it opens up myriad possibilities for using Google’s map API.  Before, some geoweb developers (our team at CUNY included) tended not to use the Maps API because each and every map looked the same.  It got to be boring, and from a cartographic perspective it was basically an acknowledgment that you took the easy way out.  And often the Google map style got in the way of other layers you wanted to add to your map.

As Google’s own blog puts it,

No matter which [Google] Maps API site you are on, every map looks the same. If you want your map to stand out from the crowd, your options are limited to customizing the markers and controls, and if your brand has a particular colour scheme that is reflected on your site, Google Maps may not sit well with it.

EveryBlock’s Paul Smith wrote about these limitations two years ago at his post about “Google Maps Fatigue”.  For our part at CUNY, if we wanted a basemap with our own style that didn’t conflict with other thematic layers and choropleth overlays, either we rolled our own.  Or if we used Google Maps, we used the Flash API so we’d have the ability to desaturate its color (following the New York Times and others) — our Census 2010 Hard to Count mapping site used this technique. 

On the other hand, I’m sure more of us will now use Google Maps as a basemap, but will that further undermine the diversity of locally-crafted and customized online cartography?  With the advent of Google map styles, our team is now looking closely at GMaps for our map applications.  I think we’ll likely only use Google’s basemap for nationwide applications where it’d be too difficult to assemble all the base map layers at that scale.  But … maybe we’ll use it beyond that.

There are still major issues, of course.  Modifying Google’s map styles is one thing, but it’s still the Google basemap with the Google logo.  Using Google’s basemap whether we style it ourselves or not still means we’re stuck with the underlying data — with all its errors, inconsistencies, outdated place names, etc.  Google is trying to fix the errors, and errors are bound to exist, but until the basemap gets to a high level of quality and consistency, in effect you’re endorsing the errors when you use their basemap.  And though we can use the GMap style options to turn on/off place names, for example, this is nowhere near as robust as setting layer-specific filters that display or omit only *certain* place names, or using different road label types for different types of roads, etc.

As I understand it, CloudMade gives you much more control over map content as well as style.  You need to use OpenStreetMap, but perhaps the openness of OSM is more to your liking than Google Maps.  This post at Programmable Web highlights some of the differences between GMaps map styles and CloudMade’s editor features.

Some critics also point out that just making a map look different doesn’t necessarily mean it looks good, or better than the standard Google look-and-feel.  The examples provided via Google’s Geo Developer blog are intriguing …

… but this one via the Javascript Maps v3 documentation is, well, not so much:

Perhaps one cartographic benefit in all this is that it will help the mashup neogeographers of the world realize that there are good and bad map styles — cartography matters.  Web map developers will need to make choices about symbology, it won’t just be on a silver platter from Google.

What do you think?

3 Responses

  1. Ride the City has been using a custom Cloudmade map style for the past year or so. As you say, it allows you to de-emphasize certain features (highways, in our case) and emphasize others (bike and pedestrian paths).

    Google’s styling capabilities are a bit rudimentary compared with Cloudmade’s so far, but they do allow you to turn labels off completely — something Cloudmade doesn’t do yet.

    Since it’s Google, I suspect they’ll get sophisticated fast.

    Right now the ultimate in control over web-based slippy map styling is probably the marriage of Mapnik (for tile rendering) with Cascadenik (for specifying the style in something a little nicer than the standard Mapnix XML).

    Development Seed’s TileMill (http://mapbox.com/tools/tilemill) and Stamen Design’s TileDrawer (http://tiledrawer.com/) both offer pretty slick tools to offload the task onto Amazon hardware, using OpenStreetMap data as the data source.

  2. Thanks Jordan, helpful comments & good insights. Ride the City has a nice look, and I like it better now with your custom OSM design than when your basemap was Google Maps.

    Will TIleMill and TileDrawer work with map layers other than OSM? Also, have you had any feedback about OSM’s data quality in New York City? (not that I’ve heard any complaints, but I’m curious how it compares with, say, the NYC Dept of City Planning’s LION file)

  3. TileDrawer does require you to use OSM data if you want to use the system as designed. (Of course, once you log in to the Amazon Web Service instance you initiate, you can manually change the data sources.)

    TileMill is designed to be a little more generic: you can point it at any data source you’d like. Development Seed (the providers of TileMill) does manage Amazon EBS images of several data sets, including OSM, TIGER, and NASA SRTM data.

    DCP’s LION data is definitely superior to OSM in New York City. In general, we’re okay with using OSM for map tiles in the U.S., but we rely on local data (like LION) for routing.

Comments are closed.

%d bloggers like this: