Print This Post

Communications and the GeoWeb

When geographic information technology was new, old time “paper map makers” (today we would call them paleo-geographers) complained that the new computer-generated maps could not draw proper symbols, area fills, or line weights. They railed against the inability of these new technologies to clearly communicate the message to the reader. They talked about the importance of “cartography” in relation to just digital map making. Of course they were right, and gradually digital map making caught up to the capabilities of paper maps in terms of symbology and the other elements of maps as communication.

Today, with the widespread use of web-based mapping, we are seeing this scenario being played out all over again. Web based maps offer poor capabilities for symbols, line styles, and area fills. Just try to make a dashed line in Google Earth or a train track symbol in Google’s My Maps.

It is very likely that these deficiencies will be overcome, and fairly soon. In fact, Galdos Systems has already proposed an extension to KML that would provide fancy line styles and area fills (see below). And, while I am in no way suggesting we go back to using paper or avoiding the powers of the web, there is a more important point that is perhaps being lost in this discussion of technology… and that is the function of maps for communication.

The main reason for creating a map in the first place is to visually communicate an idea, or to tell a story… “Here is how the armies of Persia faired in their attempt to conquer Greece”; “See the route taken by Xerxes’ fleet of Persian ships” “They had sailed along the coastline from northern Greece into the Gulf of Malia on the eastern Aegean Sea towards the mountains at Thermopylae.” How much easier this is to understand if displayed on a map. How much easier if the map uses communication techniques to get the message across. The pass at Thermopylae is very narrow and thus made a good point for the Spartans to mount their defenses. How much more readily this can be understood if we can walk through the pass and look up at the cliffs around us. A picture alone does not help as we do not have the context to understand where we are looking, and exactly what we are looking at.

Map of Piri Reis

Another way of saying this is that map making should be driven by requirements. I was recently in a country where they were making a base map. There was some discussion about the definition of a “building footprint” for their base map. Should this be an orthogonal projection of the building? Should it be the physical intersection of the building and the ground? I asked what I thought was the obvious question — “What is the function of the base map?” It was, I was told, the objective of the department to create a base map. Enough said.

Let’s return to the theme of maps as communication vehicles. A recent Google map on the spread of the H1N1 Flu virus was heavily criticized in some quarters because it was unable to clearly portray what was going on. When the “reader” zoomed out, there were too many symbols (balloons), and when zoomed in, the context was lost. Many people preferred artists’ renderings of maps (see http://news.bbc.co.uk/2/hi/uk_news/8083179.stm as an example) to the Google map (see http://maps.google.com/maps/ms?msa=0&msid=106484775090296685271.0004681a37b713f6b5950), although the Google map was possibly the more accurate and current. The reason was simply that the artist’s map did a better job of telling the story and communicating the message.

This brings us to two tried and true approaches to computer graphics and other kinds of visual presentation: the notion of separating presentation from content, and the model-view-controller paradigm that was first made well know by Xerox Parc. The two ideas are intimately related. The separation of presentation and content means, simply, that one can distinguish the essential facts and data about some event or region from any form of presentation about that event or region. I may know the location and geometry of a road, e.g. the path of the road centerline (this is the content), but not bind this a priori to a particular form of visual presentation. This means my information about the road’s geometry does not contain information about line weights or line symbology that might be used in a graphical display. In a more trivial example, content might just be text, while the presentation information, such as the type font, size, and colour, would be maintained separately. Why do this? Think again about the H1N1 Flu map. Both the artist’s map and the Google map would presumably rely on the same base information, namely the location, severity, etc., of the reported flu cases. This is the content. By separating this from the presentation of that content, we can then readily imagine various “styles” that interpret that content and hence present it in different ways. The difference then between the Google map and the artist’s map is not content, but the styling mechanism used to develop the presentation.

The model-view-controller (MVC) paradigm deals more with software design, but attacks the same fundamental issue. Suppose one is interested in the graphical display of, and interaction with, a building. MVC says to separate the model (and the maintenance of the model) of the building, from the views of the building, and to further separate both of these elements from software component called a controller for interacting with the building. Imagine the building as something very simple such as a rectilinear solid. This can be very simply represented as a rectilinear solid with a particular location and orientation. This is the building content. Through our controller we can change the elements of the model, i.e. move it to a different position, change its orientation, etc. The view enables us to look at the building model. We might present it in an orthographic projection or in some kind of perspective. This is the presentation. Again we are separating presentation from content.

Think of the importance of these simple ideas for collaboration. Suppose two (or more) groups of people interact with one another through a shared presentation (e.g. they share a screen image across the Internet) such as WebEx or NetMeeting. If one of them rotates the building, it will be some time before that operation is conveyed to all of the participants since the presentation (image) is quite large and needs to be computed and then transmitted to everyone. Contrast this with the use of an MVC approach in which only the model is shared and each participant’s software handles the view generation and provides a local controller. With such an approach, real time collaboration becomes very easy to accomplish.

The bottom line here is that, in our migration from the days of cartography (to understand this further look at the type of drawings and maps that appeared in Diderot’s Encyclopedie), we have forgotten much of the value of maps as communication tools. It is my belief that we are entering a new era of using maps (including navigable 3D maps) in which this idea can be enriched and taken to an entirely new level. We just have to think harder, and not lose the message in the medium (apologies to Marshall McLuhan).

Antique Map of America