To Go or Not to Go --> (Urban Planning and the Distance Decay Function)

The fine art of problem articulation 

The important thing about mathematical urban models is not the mathematics itself but its application to simulate urban phenomena that we are trying to understand. Therefore, even a failed attempt at creating a model may help an urban planner understand and articulate a phenomenon with greater clarity. Trying to explain an urban phenomenon in the form of an equation compels us to cut through the fog of vagueness and confusion in our minds and seek clarity.

Try to imagine what we expressed by the equation --> A=f(B, C, 1/D) in the previous blog and then try to explain it in words instead of the equation.

We would have to say something like - "When we consider shopping or any such pattern in a city...it depends on how many people are shopping....where they are shopping...it depends also on which shopping areas are large or attractive...also we must consider which are far away or close by...its a pretty complex process....but also very basic etc etc"

While the equation used just 5 letters and 1 digit, the verbal explanation used about 250 letters (and counting). 

This is not to say that the equation is better than the description, but that one should attempt to formulate an equation from the description - if only to check if that is even possible. It is an iterative process where a description helps us to form an equation and the equation in turn helps us to give a clearer description and so on.

Distance decay and the Gravity function

Distance is a crucial topic in urban planning. As we have seen in the previous blog, "distance", in this case, is not just a physical distance, but the measure of difficulty (or ease) involved in reaching where we wish to reach -- it could be kilometers of roads; delays due to traffic jams; the high cost of petrol; the physical and emotional stress of spending hours in travel etc.

The funny thing with transportation is that it is the only land-use that does not exist for itself, but for the primary purpose of facilitating interaction among other land-uses. We are generally not on a road because we want to "go" to the road. We are on it because it links where we are (our point of origin) to where we wish to go (our destination).

The other funny thing is that distance...decays.

What this essentially means is that when distances increase between us and a particular destination, our desire to go to that destination also decreases (or decays). This is easy to imagine. Let's say that there are two cafes which are equally attractive to you. Would you rather go to the one that is 500 meters away from you or to the one which is 12 kilometers away ?  

This is what we expressed in our equation as 1/D, i.e. as D increases the A (number of trips) decreases. But by how much ?

Way back, in the 1930s, the American economist William J. Reilly discovered from his empirical studies on the flow of retail trade, that the volume of trade between cities increased in direct proportion to the population of the cities and in inverse proportion to the distance between the cities. The trade not only decreased  but it decreased in proportion to the square of the distance between cities. 

Based on these observations, Reilly formulated a law which states:

"A city will attract retail trade from a town in its surrounding territory, in direct proportion to the population size of the city and in inverse proportion to the square of the distance from the city."

Mathematically it is expressed as -

R_i = P_i / d²_ki

Where R_i is the attraction of city i felt by city k; P_i is the population of city i; and d_ki is the distance between city i and city k. It has an uncanny similarity with Newton's law of gravitation where the attraction between two bodies also decreases in inverse proportion to the square of the distance between them. 

Reilly tested his model extensively by studying the breaking point between cities in the United States.  

If we accept Reilly's findings for now, then we have already developed our original equation further and we now have this -

A_ij = f(B_i, C_j, 1/D²_ij)

Nothing Super-Natural about it

It is clear from the way we constructed our equation, that there is nothing super-natural or god-given or mysterious about any of it.

We are just trying to analyse and describe how a certain kind of spatial interaction takes place.

This implies that there is nothing holy about the fact that the distance is raised to the power 2. Depending on the local context, it may be something else. In fact, empirical work over the years has shown that it tends to vary between 1.5 and 3 depending on a range of contextual factors.

However, many planning text books in India (including the venerable book on transportation planning by L.R. Kadiyali which every planning student is familiar with) continue to use distance to the power 2 without explaining that while it was derived out of extensive empirical research, that research corresponded to large cities in the United States, separated by an average distance of about 100 miles and was conducted in the 1930s.

(The fact that the equation still holds was precisely due to Reilly's empirical rigour - something that our scholars and researchers tend to shy away from most of the time.)

In reality you are free to play around with the power of D in order to check which number makes the equation simulate an observed reality best. Consider the following graph which shows how the distance decay curve would vary if we assume distance to decay if we raise the D parameter in the equation to a power of 1 or 2 or 3 -

This graph shows how quickly the likelihood of traveling a certain distance will decline if we increase the power of D in the model.

As the power increases from 1 (the green line) to 3 (red line) the tendency to travel farther declines. The red line corresponds to a reality where the tendency to travel decreases precipitously when distance increases from 0 to 3 kilometers and becomes almost nil when distance increases beyond 5 kilometers. 

Understanding the rate at which the tendency to travel declines based on increase in the distance can help us understand how appropriately or inappropriately important facilities are located with respect to each other in a city. It can also help us to concretely evaluate planning decisions aimed at locating facilities in a certain way. 

In the next blog we will play around with this equation a bit more by applying it to situations familiar to us.

Overcoming the fear of mathematics in planning education and practice

A vital contradiction in our education system

The former chief scientist of Airbus, Jean Francois Geneste said in a brilliant talk delivered at Skoltech, that when it comes to large and complex systems, 

"We can only master, what we can measure and mathematics is a discipline for measurement -- it is measurement theory."

What he said has great implications for our own field of urban and regional planning too. It is important to measure and to measure correctly, before planning decisions affecting millions of people, thousands of businesses and hundreds of hectares of land-uses of different kinds can be taken. 

Yet, precisely when there is a growing fascination with data and digital technologies, there seems to be a relatively low understanding of the role of mathematics in planning. A substantial part of the problem lies in the fear of the subject itself and the inability to apply it effectively in real situations.

We are all aware, that due to the peculiar limitations of the Indian education system, there is a rigid and unnatural separation between the sciences and the arts. 

This leads to a situation where people trained in engineering techniques are often completely devoid of an awareness of social issues and of creativity; and the people trained in humanities are often clueless when it comes to physics, mathematics etc.

Truth be told, this challenge exists in urban planning education outside India too, though, perhaps, not as severely. As Brian Field and Bryan Macgreggor noted in the preface to their book on forecasting techniques,

"...we had both come to planning from numerate first disciplines and, in planning schools at opposite ends of Britain, had independently concluded that there was an obvious gap in the literature on this particular subject."

The important word here is numerate - which means having a knowledge of mathematics and the ability to work with numbers. It is the mathematical counterpart of the word literate, which is the ability to read and write.

The complex is essentially simple 

The complex is essentially simple, because it is also a function of our learning, experience and skill. To someone who has never stepped into a kitchen, even making a cup of tea may seem like a forbiddingly complex task. However, to most people it is just a regular task -- a simple task. 

The funny thing is that mathematics seems more difficult when it is taught but it seems easier when it is applied !

When it is taught - especially in our schools - its difficulty is cranked up to meet the needs of the engineering entrance exams, whose purpose is to eliminate large numbers of students through a process of cut-throat competition. It is easy to see that this "goal" has nothing to do with solving practical problems of life and society.

Even when students master that gigantic syllabus and get extremely high grades, they may not have internalised the logic behind the topics and may fail to apply them creatively in real life situations. 

However, when one begins to study science subjects because one wants to understand and solve real life tasks, then the relevance and applicability of the topics are automatically evident and the human mind understands and internalises them faster.

Let's try to understand this using an example of a model, where we go from the simple to the complex and then realise that it's essentially simple.

Distance decay and equations that make you run away

Urban models are essentially mathematical equations that describe essential features of an urban system and can enable us to simulate and predict its behaviour.

Consider the following equation from Field and Macgregor's book (I will refer to this book  and David Foot's book on operational urban models many times in these blogs, as they are just brilliant) -

A = f(B, C, D)

This equation basically means that the variable A is a function of (that is, in some way, depends on) three other variables - B, C and D. Therefore, the value of A will change if there are changes in the values of B,C and D.

But what do A,B,C and D stand for ?

Let's assume that we want to understand how many shopping trips are made from various residential areas in the city to commercial areas. We can describe the components of our model in this way --

A = Number of trips made for shopping purposes (what we wish to find out)

B = Population of the residential area 

C = Number of shops in the commercial area

D = Distance between the residential area and commercial area.

But what to do if a city has multiple residential areas and multiple commercial areas and sometimes the residential areas are also commercial destinations and vice-versa ? We would like to express our equation in a way that shows interaction between any number of residential zones and any number of commercial zones.

We do it by introducing two more variables - i and j (where i stands for any residential zone and j stands for any commercial zone) and re-writing our equation thus -

A_ij = f(B_i, C_j, D_ij)

 Where -

A_ij - number of shopping trips made from zone i to zone j

B_i - residential population of zone i

C_j - number of shops in zone j

D_{ij –} distance between zone i and zone j

 

Our model represented by an equation comprising just a few alphabets can now handle a rather complex interaction of trips originating from any number of zones and terminating in any number of zones. 

We can refine the model further by considering the fact that A is directly related to B and C i.e. if B and C increase, chances are that number of shopping trips will also increase and B and C decrease then number of shopping trips would decrease. 

Furthermore, A and D are inversely related. If the shopping area is too far away (distance between i and j is too large) then the tendency to go and shop there would be low. Therefore as D increases, A would decrease. 

 

Therefore A = f(B, D) and A = f(1 / D)

 

Our model now becomes -

We now know how the number of trips would be affected based on the variables B,C and D. But how are they related exactly ? The model tells us that if distance increases from 5 km to 10 km then number of trips should decrease, but by how much exactly ? Do they interact linearly i.e. for every unit increase distance the number of trips decrease by one unit; or in some other way e.g. one unit decrease in trips when the distance becomes a square (from 5 km to 25 km) ? 

 

What we have discussed are the concepts of gravity (how strongly do different zones attract each other) and distance decay (how the intervening barriers between zones e.g. distance, cost, quality of infrastructure etc), which are key concepts in mathematical urban models.

 

When an equation just hits us out of the blue it looks difficult to understand, but when we break it down to its components and understand the logic behind their construction then it starts getting de-mystified. In fact, science is all about de-mystification. Once we get a grip of the logic then it not only does not seem complex, it actually seems very clear and basic. At that point we can begin to play around with it, understand its strengths and limitations and get comfortable with applying it.

 

Constructing mathematical models is a creative process

It is clear that what variables we choose to construct the model depend on us and on our understanding of the reality that we are attempting to study and predict. For example, attraction of commercial areas can be measured by number of shops, but it can also be measured by total floor area of shops in a zone. Distance between zones can be in the form of kilometers but it can also be in the form of the cost of covering distance or the time spent in covering it. 

It is pretty clear that one has to be extremely observant, imaginative and creative if one wants to create a model that is able to capture the essence of various urban phenomena.There are many people who may be experts in mathematics but have no understanding of urban processes or may just apply ready-made models blindly without considering how they ought to be altered or re-constructed given empirical realities.

 

As the Soviet mathematician Elena Wentzel correctly observed,

 

"The trade of model development is an art indeed with the expertise being acquired only gradually, as it would in arts."

In the next blogs we will look deeper into the role of mathematics in planning and explore how to apply it in planning problems we encounter in our day to day professional work.

Automating Planning Tasks 2 - (Programming with GRASS + Linux)

In the first part of this blog we had discussed how the various steps of a particular planning problem (in this case the slum-proofing problem of Jaga Mission) can be articulated, algorithmised and then automated. In the second part we shall see how the specific commands in the computer program work.

The technical steps necessary for achieving the goal (given the capabilities and constraints of government organisations executing the mission) were identified and are listed below -

(a) Identify the location of existing slums 

(b) identify vacant government land parcels near the existing slums 

(c) check them for suitability 

(d) generate map outputs for further visual analysis and verification. 

It is clear that the problem solution involves spatial analysis tasks to be performed on a Geographic Information System (GIS) software. 

While QGIS is the more familiar and user-friendly option, my preferred software for tasks like this is GRASS, which stands for Geographic Resources Analysis Support System.

GRASS is an extremely powerful and versatile open-source software, which was originally developed by the US Army - Construction Engineering Research Laboratory (CERL) and then by OSGEO - The Open Source Geospatial Foundation. 

A very useful feature of GRASS is that when you undertake any operation on it (e.g. clipping features in one map layer using features in another map layer), the command line version of the operation is also shown.

This is because GRASS is not just a point-and-click software (software which rely on a Graphical User Interface - GUI - for performing the operations by clicking with a mouse), but it also contains a command line option.

Most computer users are unfamiliar with the Command Line Interface (CLI) - even intimidated by it (I certainly used to be not so long ago). They, therefore continue to work on the user-friendly environment of the GUI and doing all their tasks with the mouse. However, by doing that they fail to harness even a fraction of the power of these wonderful machines - there is a reason why users who work comfortably with the CLI are called Power-Users. I have written about the advantages of the CLI in earlier blogs.

When GRASS is launched, it opens three windows simultaneously - the Graphic console (for performing operations using the mouse) ; a display window (for viewing the maps and results of operations) ; and a command line window (for performing tasks by typing in commands).

An interesting thing happens when you do any GIS operation on GRASS. Let's say you wish to execute the module called v.extract , which creates a new vector map by selecting features from an existing map (quite like exporting selected features to a new map layer in QGIS). The series of steps is similar to that in QGIS, where you specify the input file name, the output file name (of the new file), any queries that specify which features are to be selected etc.

You will notice, that while you are specifying these details by clicking with the mouse and entering file names, the following line is getting typed at the bottom of the module window -

This line is basically the command line version of the v.extract operation. This is how it reads --

< v.extract input=bbsr_slum_houses@training where="ward_id = 16" output=ward_16_slum_houses --overwrite>

The command begins with the name of the module, then specifies name of input file, name of input file and the sql query (in this operation the query selects all slum houses that are located in ward 16). The optional --overwrite can be added if you run the operation multiple times and would want the previous output files to be overwritten automatically (useful during scripting/programming).

When you click the "copy" button in the module window, this command line gets copied to memory. You can then paste it in a text file to make it a part of your program.

A good practice is to run all the operations manually once using the mouse, just so that you are clear about all the operations and all the command line versions of the operations. With practice you would not need to copy the commands. You will simply be able to type them out from memory or my referring to the manual page of the respective module.

Turning individual commands to a script 

Commands are very powerful because instead of clicking with a mouse many times, you can just type a short line and get the job done. But the main power of the commands is that you can write a bunch of them down in a sequence in a text file and execute it as a program to automate all your computing tasks. 

Consider the following 4 commands written down in a sequence -->

(1) v.buffer input=centroids output=buffer type=point distance=$buffer

(2) v.clip input=orsac_tenable clip=buffer output=vacant

(3) v.out.ogr --overwrite input=vacant output=$LAYER_OUTPUT/$ulb\_vacant_$buffer\_m_buffer.gpkg format=GPKG

(4) db.out.ogr --overwrite input=vacant output=$LAYER_OUTPUT/$ulb\_vacant_$buffer\_m_buffer.csv format=CSV

Of course, it looks a bit overwhelming ! But nothing to worry, cos everything useful feels a bit overwhelming at the start. Here is what is going on -

In step 1, the v.buffer module draws a buffer of user defined distance around the centroids of slums and saves it in a file called buffer. In step 2, the v.clip module clips features from the land parcels layer using the buffer layer file. In step 3, the v.out.ogr module exports the clipped land parcels as a gpkg vector file and stores it in your chosen folder. In step 4, the db.out.ogr exports the attribute table of the clipped file (containing details of the land parcels) as a comma separated value (csv) spreadsheet file and stores it in your chosen folder.

When you run these commands as a script then all these tasks get performed automatically in this sequence. 

It is clear from the above, that you can tie together any number of commands in an appropriate sequence to handle analytical tasks of varying levels of volume and complexity. 

GRASS + BASH

Bash - an acronym for Bourne Again Shell - is basically a "shell", a program in Unix like operating systems such as Linux, which is used to communicate with the computer i.e. it takes keyboard commands and then passes them onto the operating system for execution. 

The unique thing about Bash is that it is not just a powerful method for passing commands to the operating system but also an effective programming language.

The advantage of combining GRASS with Bash is that you can take the GIS commands of GRASS and use them as it is in a Bash script without any change in syntax by adding a flag called --exec at the start of the command.

By doing that you can not only execute the GIS tasks but combine those tasks with all the other programs and the full power of your Linux computer.

For example, in the same script, you can select GIS files of a few specific cities, undertake all the operations that your need to undertake, then save them in a separate folder, extract the attribute data as csv files, undertake data analysis tasks on them, put them in some other folder, turn both the spreadsheets and the output maps into pdf files etc etc. 

I guess this is already somewhat of an overload...and I feel tired of typing too ! I will show the combination with Bash in the next blog.

The request and the reward

Using the command line and scripting with GRASS and Bash are extremely powerful, flexible and fun processes, but they do request a readiness to learn and an openness to be creative.

The rewards...well they are immeasurable.