Representing flows (arrows) on a map

The following describes a very general technique: once you create a table (or "matrix," if you want to call it that) describing the flows, then any decent vector-based GIS should be able to convert those representations dynamically into graphics (arrows) on a map.  The core function consists of displaying data in a single flow record; if you can do that, then you can easily (and automatically) represent all flow records.

The basic steps, therefore, are

1. Create the flow table.
2. Attach start and end coordinates to the table.
3. Describe the shape of a standard arrow.
4. Tell the GIS how the shape of the arrow must be altered based on the data in an archetypal flow record.

We provide details of an  ArcView 3.x implementation.  ArcView requires you to write a short script to accomplish step 3, but it's simple: you provide coordinates for the arrow's vertices and you describe how to transform the arrow.  (If you cannot wait, you can view the script here in a new browser window.)

Step 1: Let the number of administrative units be N (N=3 in your example).  Begin by creating a polygon theme with N*N features.  (An easy way is to copy a theme already having at least N*N features and then deleting the extras.  It does not matter what the features are; you will change them in Step 4 below.)  Create two fields, [Begin] and [End], to contain identifiers of your administrative units, and another field, [Flow], to contain the flows.  Use them to represent the flows as in the example:

[Begin]   [End]   [Flow]
A         A       m
A         B       n
A         C       o
B         A       p
B         B       q
B         C       r
C         A       s
C         B       t
C         C       u

Step 2:  Create [X] and [Y] fields in your administrative unit feature table.  Populate them with coordinates of the centers of the units.  (Use the field calculator; the requests are [shape].ReturnCenter.GetX and [shape].ReturnCenter.GetY.)  Join this table, using the common administrative unit identifiers, twice into the flow theme created in step 1, using the [Begin] and [End] identifiers.  In this fashion your flow table will contain coordinates for the center of the beginning unit, coordinates for the center of the ending unit, and the flow.  Use the table properties dialog to alias the [X] and [Y] fields so that they have distinct names, such as [X0] and [Y0] for the coordinates of the beginning and [X1] and [Y1] for the coordinates of the end.

Here's what the flow table might look like at this point:

[Begin]   [End]   [Flow]    [X0]    [Y0]    [X1]    [Y1]
A          A       m         1473.2  800.1   990.0   887.9
A          B       n         1473.2  800.1   1004.2  738.0
...
C          B       t         1515.5  609.6   1004.2  738.0
C          C       u         1515.5  609.6   1515.5  609.6

(You don't need to include any records where the flow is zero or where you don't want to show an arrow.)

Step 3:  Write a (simple) script.  Let's call it "Arrow."  Here's what it does: Its argument is a list consisting of a starting point P0, an ending point P1, and a numeric value, which I will call "w".  It returns a polygon, shaped like an arrow, beginning at P0, ending at P1, of width w.  I recommend building such a polygon beginning with a standard shape, such as an arrow of unit width pointing at a zero degree angle.  You can use the value of w to scale the arrow vertically (that is, along its width), the vector P1-P0 to scale and rotate it, and the point P0 to translate it. Each of these operations is simple to implement.

These are straight arrows and the procedure will not work well when P0 = P1, so you may wish to modify this script to accommodate these deficiencies.  (Maybe use a circular arrow for this case only?)  This is where the creative work goes!

Test this script carefully before going to Step 4.  (One way is to perform Step 4 with a very small number of records selected at a time.)

Step 4:  Begin editing your polygon theme.  Clear any selection.  Use the field calculator to edit the [shape] field.  The expression to use is

av.Run("Arrow", {[x0]@[y0], [x1]@[y1], [flow]})

Stop editing, save edits, refresh the view, make the theme visible.  You are done.

If you wish to experiment with different arrow-drawing algorithms, you need only restart at step 3: modify the script, then redo step 4.  It's fast and easy.  If your administrative unit maps be changed, just recompute the centers and redo step 4.

In June, 2001, another reader wrote again with a request for a sample "Arrow" script.  You can find an html formatted version here.

A little later he wrote back with this message.

It took some time to get all things right, but it worked! (I had to correct for the width for the length of the arrows). Thank you very much! In the attached file is the result. It shows commuting between different parts of the Randstad (or the Deltametropolis as we Dutch call it now) at different scale levels. With this easily working script I can start now picturing the historic development.

(Note that the GIS analyst, by studying historic development, will actually be working with matrices giving origins by destinations by amount of flow by time period: a wealth of information.)

The technique described here works for displaying data using any kind of "glyph" whatsoever.  It is an amazingly powerful visualization tool.  Its chief limitation is that it is purely local: that is, the placement of one glyph is independent of where the others have been placed.  Thus, for example, it would not be effective for drawing arrows that curve elegantly to avoid colliding with or overlapping each other.

--Bill Huber, June 28, 2001.

Here is more advice contributed to the ArcView-L discussion list by a GIS luminary, Duane Marble, in October 1998.

You can find a description of our work on flow mapping and analysis in:

"Recent advances in the exploratory analysis of interregional flows in space and time," (with Zaiyong Gou, Lin Liu and James Saunders), in Z.  Kemp (ed.), Innovations in Geographic Information Systems. London: Taylor & Francis. [Keynote address given at the 4th National United Kingdom GIS Research Conference, Canterbury, England, April 1996.]

There are also a number of doctoral dissertations that have been done here at OSU.

We write our own software. Trying to do flow mapping in ESRI products is just not viable. John Gatner at Sandia National Laboratory did manage to make Arc/Info do urban traffic mapping but it took him nearly two months and the result was poor. He said he would never do it again.

We work from multi-dimensional O-D matrices (origins by destinations by type of flow by time period).