My job as a cartographic designer. Part 2

Just like any other professional, I get slightly annoyed when people assume what I do in my day job to be limited to a few obvious tasks. As highlighted in part one, those in our industry find it hard to explain to friends what we do, but being able to explain and show people what we do is important; no more so than in the workplace – there is nothing more irritating than working on a project and being seen as someone whose role is just a bit part, for example to colour in the final output and decide if buildings should have outlines or not!

The role of the cartographer has always involved much decision making but with technology has come a different set of skills from the more craft-like skills of scribing or even digitising.

Mapping in a GIS (Image: Ordnance Survey/Twitter)

Yes I can create paper or digital maps using Adobe Creative Suite or whatever, I can style geographic vector data to look ‘map-like’ in a GIS but, as mentioned in the previous post, the role of a cartographer is also to create web maps, to support and evolve automated cartography, to help provide a better user experience, to supply tools and documentation to make products easier to use, and to influence the design and development of all geographic or location-based source data, content data, products, apps and services.

Even though I don’t do any app or main service development, computer language is used in cartography and GIS every day, from writing expressions that filter or label data to creating stylesheets for web mapping. You may have seen I tweeted a photo of me listening to tunes at work while hand-crafting some web cartography earlier this week. So there you have it, I’m also a code monkey!

Well, not quite. Thankfully at OS we have developers who do most of that side of things for us which allows me to concentrate a bit more on the cartography and product experience. However cartography is increasingly becoming tech-based and so computer science skills are becoming increasingly useful. Think of all the whizzy maps you may have seen such as the Recce app, the 3D mapping of the Tour de France or ESRI’s story maps (other story maps exist!); these all take a skilled cartographer but also require a lot of coding.

Recce app (Image: Projectz)

Creating vector stylesheets is far more complex than a still, stand-alone map for on-screen. Whether for web or a GIS, our stylesheet creation does involve choosing colours – which takes a huge amount of skill – and it does involve deciding whether or not buildings should have outlines! But it also involves working out complex filter or label expressions, and evaluating and honing-in on the optimal settings for automated label placement. All of these things take a huge amount of mathematical problem solving with the goal of defining all of the logic-based rules of both styling and automation including scale thresholds, label placement and conflict resolution, and for the web defining them all in a computer language such as Styled Layer Descriptors (SLDs – a form of XML) or CartoCSS.

Expressions in GIS packages tend to be written in SQL, VBScript or Python and the above logic is held in a minefield of GUI-based settings.

Last week I wished to remove the trunk road suffices from the road numbering in OS’ Strategi product. A theoretically simple task of removing (T) from the end of A31 became a very long and painful exercise, the usual forums and help pages on the web offering no answers to this particular issue. The problem being that none of the java functions an SLD uses, string replace for example, would accept bracket characters (even as ascii codes).

Eventually I created this little work around, simply removing the last 3 characters of road numbers containing the letter T (simple but intuition was to remove the brackets explicitly):

..  <ogc:PropertyIsLike  wildCard="*" singleChar="." escape="!">
      <ogc:Function name="strSubstring">
          <ogc:Function name="strLength">

Code to remove (T) trunkroad suffix from OS or DfT road numbers

Our vector stylesheets also work across a continuous scale range which once again makes the task a lot harder. An awful lot of logical thinking is required to consider at what scale each feature should change, or should they change continuously by using ground units instead of screen pixels? I suspect even the biggest champions of our work don’t realise the sheer number of good decisions that have to be made to ensure good cartographic representation.

But before we can even begin the above we need appropriate content. So I also get involved, as many cartographers do, in agreeing with our developer teams things like generalisation algorithms and their parameters, what attribution our content data requires, what needs improving in source data to give us the best possible product for our customers.

Then there are also different options available to us nowadays in terms of output, such as 3D. ArcScene and QGIS2threejs are a good start but I’ve just started learning how to use Blender (with a lot of help from our resident expert Guy). And I haven’t even begun to explore the cartographer’s input to point cloud data.

Cartographers are increasingly becoming involved in visualisation, in gaming and in recent technologies such as augmented reality (AR), virtual reality (VR), autonomous vehicles, smart cities and so on.

2.5 or 3D terrain scene I created a while ago
Hampshire street light data visualised using cartography skills in a way that immediately communicates (Image: Charley Glynn)
Samsung’s Gear VR headset (Image: AsiaOne)

Cartography is now about so much more than paper maps or even Google Maps. It is about consumption of geographic information. Other cartographers have criticised the mass sharing of maps on social media as there is nothing to filter the good from the bad, but I disagree. If it works, then it works; as I keep saying, there are no rules. For me the internet globalisation of map distribution simply means that an increasing number of people in the ‘general public’ from an increasingly diverse set of backgrounds are learning to appreciate and understand the importance of location and the value of cartography in being able to visualise such information. Evidence of this is the immediate uptake of places on our cartographic masterclasses aimed at developers and entrepreneurs at the Geovation Hub in London.

Take for example the map of tracked sharks that has been ‘doing the rounds’ of late. There are so many stories in here but it is immediately accessible, easily understandable and it is getting people immersed into our world of geography and location analytics.

OCEARCH Global shark tracking (Image: 3BL Media)

Cartography is all about communication and outside of map creation we do a heck of a lot of oral and written communication.

For example at conferences I showcase our work, seek validation from our peers and experts in our field, keep abreast of the latest academic and industry developments, and gain new ideas and understanding. I also sit on various committees and contribute to collaborative projects. I give presentations, run workshops and deliver masterclasses to support both our products and their users. I have also made time for technical book reviewing, contributing to industry reports, writing for books and journals as well as the endless media interviews on the back of the success of my venture into planetary cartography with Western Arabia Terra, Mars.

The art in cartography is still important – in fact it underpins our design principles. And cartographers (including me) do still make maps. They remain an important, relevant and often powerful way to communicate a message or tell a story. But please, please, please think before you assume a cartographer’s job is simply to colour in geographic data to make a pretty map.

Map of the Arab Spring 5 years on (Image: The Economist/Twitter)

Further reading

Hasn’t everything been mapped already (or why do we need cartographers anymore)?
By Chris Brackley.


Glossary of terms


Association for Geographic Information


Cartographic Cascading Style Sheet


Environmental Systems Research Institute


Geographic Information System


Graphical User Interface


Ordnance Survey


Styled Layer Descriptor


Structured Query Language


Visual Basic Script


Extensible Markup Language


Leave a Reply

Your email address will not be published. Required fields are marked *


Get every new post on this blog delivered to your Inbox.

Join other followers: