Saturday, 5 January 2013

UW-Madison Campus Map

UW-Madison released a new version of their campus map recently.

New UW-Madison Campus Map

UW has a rich cartographic history with their Cartography Lab being established by Arthur H. Robinson in 1953. Successive Faculty and students have become renowned for the high quality of their work and have helped shape cartography as a subject and as a practice in the subsequent years.

Their campus map has always been a work of high-quality cartographic design. Their web site hosts an archive of past maps that showcase the shifts in design through the years. Apart from a period in the mid-seventies and the most recent 2006 version when they reverted to planimetric form, the maps have been constructed using a 3D axonometric approach.

Extract from 1978-2005 UW-Madison Campus Map

This is a common approach for University campus maps because it allows individual buildings to be represented as they appear. This works well for this type of large-scale map that needs to show the form of a dense urban environment to aid location and navigation. This sort of approach was well used by Bollman in 1962 and, later by Anderson in 1985 in their highly detailed, famous maps of Manhattan Island. By allowing people to see their environment in detail, the maps support a more immediate way of linking what they are looking at in the real-world with the map that provides the description. They also exhibit a strong aesthetic. The 2006 version was also a beautiful and well-designed map and the drop shadow on buildings lifts them off the detailed basemap.  On this version, the basemap is the key to the detail with individual trees and land cover shown to provide the context.

Extract from 2006 UW-Madison Campus Map

So what of the new map? Well it's a now a web map which is inevitable as the new publishing paradigm for mapping. Nothing wrong with that per se. It replaces a previous Flash-based online version, presumably to ensure that students with iProducts can use it. The map has been "developed by University Communications and Marketing" and authored by their web developers with advice from cartographers. When you click "About the map" you get a roll-call of tools and software used to build the map. JOSM this, Mapnik that, Ruby on Rails blah blah yackity schmakity. Maps never used to have a huge list of the different sized Rotring pens used, or whether it was built using Illustrator or Freehand did they? None of the previous UW campus maps have this detail...the maps speak for themselves. Mode of production should be irrelevant but smacks of an attempt to show how clever the map is when presented like this. Instead, we could have had a description of what the map is showing, what the design philosophy is and how choices of representation are expressed. Alarm bells ring...this is an example of treating the map as a technical challenge and solution rather than a cartographic one. It's really not that important how the map was built...what is important is the map does its job and does it well.

The map itself relies on an OpenStreetMap derived slippy map. Gone is the local detail. Gone is the immediacy of the axonometric projection. Gone is the colouring by building function that the 2006 version used. Gone is the cartographic nuance and polish that brings a large-scale local environment to life. The map is bereft of detail. The buildings are merely flat shapes on a flatland that lacks detail. The argument of showing detail through the satellite basemap will undoubtedly be made but that, of course, includes all manner of extraneous detail because it lacks generalization.

New UW-Madison Campus Map with satellite basemap and overprinted thematic markers

The map now becomes nothing more than a portal to other information via popups. Yes we get pictures of the buildings but have we made progress when it takes 2 clicks to get that picture when some of the previous maps had them built into the design itself. You can add libraries, public parking and visitor centers which appear as huge markers.  Again, a well designed map would have these integrated into the design. The map is not much more than a collation of data sources that lacks a coherent design strategy. A brief Twitter conversation with one of the UW web developers illustrated that the desire is there to make a better cartographic product but that the technology and resources were a limiting factor. So it begs the question...why replace a perfectly good map if the replacement isn't going to be capable of being an improvement. Change for changes sake.

Yes, the map is searchable and rollovers give us other detail.  The bones of a decent map are here but it lacks the quality of the previous maps. As a first iteration there is undoubtedly room for improvement but here is the main problem... UW-Madison is renowned for high quality Cartography. Web sites are a public facing demonstration of the University, they are a highly visible window into the quality they purport to offer but the web map does nothing to demonstrate that quality so visitors to the site leave unimpressed. If the web site itself does not match the quality of what the University offers then it detracts.  The same is true of many many other institutions. How often do we see a sub-par map published by a Marketing department which has been developed by people lacking in the cartographic expertise to do the job properly? Kingston University are hideously guilty of this as I well know from my previous job. Their awful maps are still being used despite in-house cartographic expertise and student work providing a much higher quality product.

'Official' Kingston University Campus Map...still one of the worst examples!

This problem isn't just seen in Universities. Many organisations push out maps that fail to do justice to the quality of their other work or provision. Many have expert map-makers yet the work given the most visibility is often built by others.

Good maps are a combination of domain knowledge, cartographic expertise and technology. Web maps are becoming the de facto standard but they need more than just web development. They need cartographers with web development abilities; they yearn for design; and they need a symbiosis of skills to realize a truly high quality product. It's no good cartographers moaning about poor web maps if they aren't willing to step up to changing technologies. likewise, those with web development skills shouldn't assume they have the necessary cartographic skills to do the job. Currently, web maps are limited by the technology, or, more accurately, by such fast-moving technological change that maturity and stability is still hugely disruptive which leaves many projects either experimental or limited.  If web maps are going to improve then people with design skills need to be heard so that the technology can be built to support good design.


Saturday, 8 December 2012

The Mystery of the Grey Line

Some debate at the office this week after a mysterious light grey line appeared on Google Maps from the Salton Sea to Monterey Bay that ran right over Redlands. Nothing better than a mapping curiosity to divert attention from work. So what is it?


Here are a selection of the theories on the mile wide feature:

  • mis-aligned administrative boundary...but there aren't any that shape or position nearby
  • San Andreas fault...but it only matches part of the fault's position and why would it be symbolised like this?
  • a little known boundary accidentally symbolised too large
  • a planned new high-speed public transport rail link (huh? in California...c'mon!)
  • a newly found subduction zone
  • a pipeline (well, it does disappear under the San Bernardino mountains)
  • a planned pipeline
  • an irrigation ditch
  • new river to drain what's left of the Salton Sea
  • a spatial reality distortion zone that just happens to fall across Redlands (think about it...)

The answer, thanks to a friendly Google man in the know: probably a rendering bug. Simple. Back to work...fixing our own rendering bugs ;-)

Bomb Sight Map of the Blitz

The Bomb Sight project recently went live, presenting the London WWII bomb census between 7.10.1940 and 6.6.1941. It's a terrific effort (kudos to the team), cataloging anti-invasions sites, bomb types and adding an overlay of the bomb maps themselves.  The map is the result of a year's worth of work which hints at the effort needed to build an interactive web map with good quality content...it's not a trivial task! Just a few words on the cartography...

Given the sheer magnitude of the number of bombs at scales smaller than about 1:72k the map descends into an inevitable push-pin madness.  Now I can understand the point of this is perhaps to create a stunning visual impact of the sheer scale of bombing (and the word Blitz has never been more appropriately illustrated) but there are more useful ways to present the data.  Binning into geometric shapes (hexagons, squares) would create a summary overlay.  Some form of interpolated surface might also summarize the data better at these smaller scales. The scales could, of course, be constrained to avoid the map being able to zoom out too far. I'm in two minds over this...it's probably the only example of data which isn't fundamentally destroyed by the amorphous blob of overlapping symbols simply because of the subject matter. Certainly, the scale of the Blitz is illustrated with a frighting clarity even though, technically, clarity is not usually supported by push-pin overload.

Bomb sight map at 1:577k

At 1:72k even though there isn't interactivity it's fascinating to see the patterns of bombing runs (clearly seen in the screen grab below).  It might be nice to code the symbols somehow to indicate they were part of a single run (perhaps a thin line to join related dots)....possibly at scales 1:36k and larger.

Bomb sight map at 1:72k

Zooming in further, the contrast between the subtle basemap and symbols is well crafted. When you zoom to the largest scales (1:4k) the symbols change from generic geometric shapes to pictorial designs and multiple bombs at a single site are presented as numerical markers that literally explode into component parts when clicked to reveal individual sites.  At 1:4k the map now allows interaction with each symbol containing a popup with basic details and a link to much more detailed information. The map works really well at these scales but I'd like to have seen interactivity developed at smaller scales. Given people's propensity to move away from web sites rapidly, it would be useful to incorporate interaction earlier to avoid them leaving the site before the good stuff....I found myself clicking around at smaller scales to prompt some form of interaction which is only rewarded once you have reached 1:4k.

Bomb sight map at 1:4k

There's some useful filters in terms of layers you can switch on or off and you can isolate the first night of the Blitz with a nice bar graph. The ability to search by neighbourhood, view other statistics and ancillary information, images etc is a great way to support alternative forms of inquiry and further mining of the information. The cartography could have supported the interaction further though. The popups could present the date as well as the place.  The data clearly has a temporal component so it shouldn't have been too difficult to provide a time slider allowing users to cycle through by date, or even play an animated version. The Android app version adds in functionality to use the phone's location to zoom to the local area and an augmented reality mode that supports the overlay of bomb details as you wander round. Neat!

Overall a really great example of how a web map can be used as a portal to archive material and how the map is part of the overall presentation which works well when you have a rich dataset. In my opinion, some tweaking of the cartography would help...not to make it 'pretty' but to summarize the data better at certain scales and make the map more effective across scales rather than only at larger scales. The point here is really to emphasise that a multiscale web map is really a series of individual maps that has to function at each scale. The bomb sight map works brilliantly at some, but less so at others which impacts on the consistency of the user experience across scales. Building a multiscale web map requires careful planning of each scale along with a clear idea of the transition of data representation, symbol design and interactivity across scales. There aren't many that get the balance right but this web map is certainly one of the better examples.

Monday, 26 November 2012

LGA National Map of Shared Services cartojunk

This one from @StevenFeldman who is seemingly learning that pushpin maps are not actually that good.  It's taken me a while to persuade him that applying some design KnowHow (to add to his KnowWhere) is a really important part of the data dissemination and communication process and this example from the Local Government Authority web site is a perfect example.


I'm not going to go on and on but here's the thing...when you click on this map some really useful information appears but:
poor symbols that don't differentiate
poor reference backdrop that just adds visual clutter
overlapping symbols at small scales that just creates visual noise

The map needs far more nuanced design to enable it to operate as a multiscale information product.  Some form of aggregation at small scale that then proper symbol design to differentiate meaning between different classes. Maps like this are lazy.  Yes, good maps take time to create but this sort of map does a disservice to the information behind it. Who will stay to interrogate this map? Answer...very few...they're off to another web site.