Here be dragons

17. Here be dragons : some principles of cartography and OSM Steve Chilton Chair of the Society of Cartographers Contact: [email_address] Society of Cartographers: http://www.soc.org.uk/ SoC Conference: http:// www.port.ac.uk /special/soc/

Notas do Editor

We need to start with a little theory. I have heard many people – particularly neo-geographers – repeating the idea that anyone can now be a cartographer. Whilst I laud that concept, I do feel that an understanding of some basic principles of graphic communication is going to raise the quality of the ensuing maps. In my view a lot of people are producing a lot of poor maps. You have probably heard the term “red dot fever” – a term that may or may not have been coined by Schuyler Erle - used in particular to describe the indiscriminate placement of red markers (the original default in Google maps) to show distribution of geographic data. Frankly, this is still what you see in a lot of neo-cartography. In most people’s eyes cartography isn’t an art form, like painting, music, dance, etc. But there is an art in producing map designs that work. An attractive map is a functional map. An unattractive map will soon lose the viewer’s interest. To produce an attractive map requires some considered design compromises. One of the most important of these is to make appropriate decisions on visual variables – the size, style, colour and orientation of the (carto)graphic elements. There is a whole field of study of visualization which we can’t go into at this stage. Suffice it to say that the points, lines and areas of the theoretical model are reflected in the nodes, ways and areas in OSM. So, let us apply some principles of cartography to a project such as OpeenStreetMap.
Scale OSM is producing a scale-free database. How it renders this data then becomes important. So, what happens if 2 or more features share the same space (eg a tram down the middle of a road, a double decker bridge, a canal and it’s towpath). Traditionally cartographic licence might be invoked, allowing the cartographer to move one or more features slightly to allow successful mapping of the discrete features. I would argue that we should NOT move features at source, but map them in the database as accurately as possible. We then need to seek rendering solutions that deal with these circumstances. In theory, as scale increases so the space the features occupy becomes more “usable”.
Topology Topological correctness must be sought. By this I mean that networks (eg roads) should be logical, complete and discrete. For example roads should not be connected to rivers (ie sharing a node). Not strictly true, as a ford would share the same node, as the river and the road are conceptually the same at that point. Roundabouts, sliproads, etc must always make topological sense – so that they may be used by route finding software. Similarly the parts of a way (segments) should be arranged logically within that way. If a way is an enclosed polygon (an area) then the segments should be connected all in the same direction and in a continuous clockwise OR anti-clockwise direction. If not the rendering of the area may be problematic, and very importantly software checking for such as inside/outsideness of areas may well fail. Equally segments in a (road)way are best connected in a W-E direction so that the default rendering of the road name is also W-E and not needing to be read upside down. Failure to connect (road)ways in sequence and W-E is the reason for many of the disjointed and irregular text placements that occur on roads at present. One time when this rule has to be ignored is when a way is a oneway street. The onewayness will be indicated by the “direction” of the street. The namedirection=-1 tagging assignment can be used to correctly label the street name in this instance.
Data richness What data is needed to record features? If the feature is a straight line, then it just needs 2 nodes to record it. If the feature is curvilinear then it needs many more points to define it appropriately. When recording GPS tracks and converting these to OSM data several variables come into play. For instance, there is the interval between the GPS points, and then the number and position of nodes that are inferred from this GPS data. Do you trust your GPS data explicitly? You need to remember that the accuracy of the GPS data can vary significantly during a particular track. Do you have supplementary knowledge to help you make that translation to nodes? Local knowledge obviously helps a lot here. Can you imagine an extreme case where a feature zig zags in an exaggerated way (illustration). Your GPS tracking may have been set to an interval that happens to only record data on the zigs and not the zags, or on the straights but not the bends. In theory you could get a result similar to illustration 2. Remember that back at base you may only have the GPS track to work from. This is a situation that would certainly be enhanced by the making of a field sketch at the time to indicate what actually happens. I would argue that is more useful to have the correct shape recorded rather than the absolutely correct GPS points.
Symbols Many symbols have been designed by different people for the project (usually in SVG notation). All will have a default insertion point. In order for predictable results to ensue the same relative insertion point should be used in all cases, and the bottom left of symbol is recommended (illustration). Mimetic symbols (that look like miniatures of what they represent) are being used in OSM in most cases, which is good because the slippy map has no key! “What is the difference between those dashed lines and the dotted lines?”
White space Historically cartographers had an aversion to white space on their maps, and there was a lot of that on early explorer’s maps! One solution adopted is encapsulated in the expression “here be dragons”. However, this is a bit of a global myth. Historical research shows that there is only one recorded example of these exact words appearing in a map – and that was in Latin on the Lenox Globe in 1511. Notwithstanding this, there are many examples of similar text/graphics being used to fill up space on maps. The first example shows a cartouche filling a blank spot on a map. The second example shows the same technique in use in OSM (more to follow!). There are sometimes reasons for there to be no data mapped at particular parts of maps. In OSM it could be that: it has not been mapped yet; there is no map feature yet for what is there; or in fact there is “nothing” there to map.
Problems in non-manual cartography A long-winded way of saying that there are three classic problems that computer-generated map output has to deal with. These are generalization, type placement, and overlaying of detail on other detail. Taking type placement first, there are issues about placing type along features (road names), at nodes (long railway station names), and within areas (calculating the centre of gravity of the polygon). Generalization is the process of reducing the amount of detail – in for example a river or stream – as the scale of it’s depiction is decreased. The overlaying of detail can be dealt with to some extent by sensible layering of rendered information, use of transparency rules, etc. However, it is the not the role of this presentation to deal with these complicated issues. Suffice it to say that there are algorithms extant for most of these situations. It will be our task as a project to incorporate these principles and techniques as the project develops, solving problems along the way. I am sure it will be an interesting ride.

Here be dragons

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Mais de Steve Chilton

Mais de Steve Chilton (20)

Here be dragons

Notas do Editor