The Elegance (and Importance) of Ugly: the “Errorscape”

The Elegance (and Importance) of Ugly: the “Errorscape”

Some pretty things are actually rather ugly. Take this map (below), for example:


While it is pleasing in its shifting colors (ordered here by the area of the polygon) and even, to me, a bit mesmerizing  as the eye tries also to accommodate transparent, color-coded detail along the streets, this map is replete with error.* Indeed, its job is to reveal those errors. The blue and red shapes represent all the places where one polygon improperly meets another. This can mean that a street for a short stretch overlaps a sidewalk or that a small gap exists between that sidewalk and the house or shop beside it. The image links to a very large version (5312×2938) so you can see some these problems for yourself. They’ll still be hard to see because, despite the three meter buffers that surround them, each overlap or gap is less than three square meters in area, and the vast majority are less one square meter. The problems all come, sadly, from me… well, from me being a human being living in a world of finite resources and time. Each problem is a drawing error produced when I digitized the landscape of Pompeii – approaching 5,000 individual features – between 2005 and 2008. Now, in order to have a more precisely rendered landscape of Pompeii, one that both looks good as a map free of drafting errors and works well as a table with as accurate information as possible, these errors must be fixed. There are 3023 areas of interest to examine, so this won’t be fixed overnight.

In a related problem, the georeferencing of all the data is off. That is, when we overlie it upon satellite imagery, it is shifted considerably – approximately 30m to the southwest. The issue, however, is global and appeared to be one that would require only a reprojection of the data.** We did this using our “Architectural Features” layer, which represents all the architectural ground features (i.e., not the walls). When the two layers overlapped, they looked aesthetically interesting and remarkably like an archaeological phase plan.

Projection error looks like PhasePlan2

The utility of this plan is to show us the scale and direction of our reprojection error. The interesting thing about it is the way it piques the archaeological imagination. I immediately want to push the blue and the brown apart in chronology. I try to imagine how the experience of the space changed between these periods and wonder about the significance of the altar built directly above the stairs of an earlier temple. Then I remind myself, this is not a real landscape, it is a functional “errorscape”. Its a deliberate graphical representation of errors in (ultimately, tabular) data with the purpose of defining and resolving those errors. Still, I can’t help but reflect on its attraction and pull on me, the seduction of space and time distilled to a few lines in different colors, however unreal.

The point of the map, beyond its wonderment to me, is to be a guide between where my data are and where I want them to be. It serves to show me that my spatial data must be pushed through an new projection. This testing, however, shows that not only is there an error in projection, there is an error in location. The reprojected layer is still about 2.20m off from the satellite image, this time to the southeast. This error is undoubtedly again my fault, created in the original georeferencing of the data. Really, it’s only partially my fault as there are inaccuracies both in the underlying CAD data generously shared by the Soprintendenza*** as well as in the GPS survey that gave the real world coordinates. Regardless, the next step will be to adjust our coordinates to match the satellite imagery because, as I said in the last post, “if we have to be “wrong”, let’s be wrong in the right direction.”



Some more technical details:

* To make the map of gaps and overlaps, I did the following:

  1. Create new feature for the outline of the entire city;
  2. Union all polygons together;
  3. Sort the attribute table of the resulting layer by area, descending;
  4. Select all those items with an area less than three square meters;
  5. Make a layer from the selected items and export to geodatabase;
  6. Enlarge this layer’s visibility using the buffer tool (3m).
  7. Symbolize the total area of the Union layer as a color ramp
  8. Symbolize those gaps/overlaps less than 1m in red, more than 1m in blue.
  9. Adjust their displayed transparency to 50%.
  10. Export map.

** To test the error for reprojection, I used an unusual process: I converted the shapefiles to Google Earth KML files because I had noticed in a previous experiment that these files far more precisely overlaid the satellite imagery. Some of that work, as images, is here:



 We have struggled thus far (ok, after one afternoon) to get our files to reproject appropriately in ArcGIS or in FME. All suggestions are welcome.

***  The SAP CAD file was created by digitizing the RICA Maps of Pompeii, 1984, supported by World Monuments Watch and funded by American Express. The RICA MAPs were drawn in part from aerial images taken at 820m and supplemented by on the ground survey. Inconsistencies among the features of this layer with satellite imagery or other maps of Pompeii may be the result of errors in the rectification of the original aerial images. On the creation of the RICA Maps, see Van der Poel, H. B., Corpus Topographicum Pompeianum, vol. IIIA. Austin, TX, 1986, XI-XIX.