Programming Falsehoods About Geography

| |

Programmers will often try to create consistencies in how spatial locations are understood in order to stream line programming. Two separate posts have been published, picking apart some of the falsehoods found in computer programs that deal with geography.

The first post is a list by Matthias Wiesmann published a couple of years ago entitled, “Falsehoods programmers believe about geography.” In it, he outlines some of the erroneous assumptions about geography that he has found embedded within computer programs. Some examples of falsehoods includes the notion that places only have one official name or that they only have one official address. He also counters the assumption that all countries have capitols, citing Switzerland, which has the seat of its federal government in Bern but, by law, does not designate a capital of its country.

Michael Tandy has a very long list of falsehoods programmers believe about addresses gathered during his work as a programmer. Some examples of faulty assumptions about addresses include: no buildings are numbered zero (0 Egmont Road, Middlesbrough), or, at the very least no buildings have negative numbers (Minusone Priory Road, Newbury).


Enter your email to receive the weekly GIS Lounge newsletter:

1 thought on “Programming Falsehoods About Geography”

  1. I think a lot of the problems referred to in these two articles stem from the stage that GIS is at. The need for quantitative geographical information stemmed from the work of people like Ian McHarg (Design with Nature, 1969) and even John Snow (in his famous cholera study in 1854). Computing came about in the 1970s and GIS development gained pace in the 1980s. The development of software was necessarily highly technical and most people with an understanding of geographical applications were excluded because of this. When GIS software showed enough promise, organizations began adopting it, mostly to streamline map production. A great era of map digitizing began. By around the turn of this century data quality issues began to emerge because organizations had begun to query maps and associated databases.

    GIS was still a very technical profession and user communities were very much excluded both by the very technical nature of GIS and the departments that controlled it. However, I think we are now at a point in time where GIS (both commercial and open source) has matured enough for it to be routinely included in the undergraduate education of many professions. Hopefully this will empower user communities to have greater involvement in the GIS data issues that both articles refer to. For me the key point in Matthias Wiesmann’s post is that “To actually to write useful programs, one needs to understand what the programs are about.” This is a big bugbear for me. Too many GIS maps I see demonstrate no understanding of the problem being mapped. I tire of seeing…

    * GIS maps without legends.
    * GIS maps produced with no understanding of implications that scale of the paper maps that the GIS maps were digitized from have on the appropriateness for the use they are being put to.
    * GIS modelling efforts focused on which GIS algorithm to use, with no consideration given as to whether the problem being modelled is suited to the approach being taken.

    Greater involvement in GIS map (and GIS model) production by users who understand the nature of geographical information should overcome many of the problems that these two articles refer to.

Comments are closed.