Imagico.de

blog

Social Engineering in OpenStreetMap

| 0 comments

With the use, popularity and economic value of OpenStreetMap increasing significantly over the last years interests and attempts in influencing the direction of the project and its participants also increased a lot. I here want to look a bit at how this works, sometimes in unexpected ways.

I use the term social engineering here in the sense of activities that aim to make people do (or not do) certain things not by educating them and enabling them to make better decisions according to their own priorities but by influencing their perception to serve certain goals without being aware of this. Some might consider this to be defensible or even desirable if it serves an ulterior motive but i would here take a strictly humanistic viewpoint.

Note social engineering does not necessarily require those who actually influence others to be aware of the reasons.

OpenStreetMap is well known among digital social projects and internet communities to have relatively few firm rules and giving its members a lot of freedom how to work within the project. This also provides a lot of room for social engineering of course. On the other hand the OpenStreetMap community is fairly diverse at least in some aspects and quite connected so it is rather difficult to target a specific group of people without others also becoming aware of the activities. This means classical covert social engineering where people are not aware they are being engineered is not that dominant.

But there are a lot of activities in OpenStreetMap that can be considered more or less open social engineering attempting to influence or organize mapping activities. Humanitarian mapping is one of the most iconic examples for this and there are also quite a number of widely used tools like Maproulette that can be used to support such activities.

The number of people mapping in OpenStreetMap on a regular basis makes influencing them to focus on mapping certain things fairly attractive even on a relatively small scale. But this is relatively harmless because

  • it is fairly direct,
  • the influence and often even the interests behind it can usually be readily seen by the mapper,
  • if it goes over the top such activity can quite easily be shut down or moderated by the community.

In other words: Mappers engaging in a HOT project are not that deeply manipulated because they do not believe they participate in such activity for reasons that are fundamentally different from the actual reasons. They might not know exactly how much the people in the area they map in profit from what they do and what economic interests the organization planning the mapping activity has exactly but in broad strokes they still make an informed decision to participate.

None the less such activities are not without problems in OpenStreetMap, especially since they can affect the social balance in the project. Local mappers mapping their environment for example can often feel bullied or patronized if organized mapping activities from abroad start in their area.

This is however not primarily what i want to discuss here. I want to focus more on a more subtle form of social engineering i would call social self engineering. A good example to show how this works in OpenStreetMap is what we call mapping for the renderer.

Mapping for the renderer in its simplest form occurs when people enter data in the OSM database not because it represents an observation on the ground but to achieve a certain result in a map. Examples include

  • strings being entered into name tags of features that are not names in an attempt to place labels.
  • place nodes being moved so a label appears at a more appealing position.
  • classifications of places or roads being inflated to make them appear earlier or more prominently in maps.
  • tags being omitted from features because their appearance in the map is considered ugly.

Compared to normal social engineering the roles are kind of reversed here. The one whose behavior is changed is the one who actually makes the decision (therefore self engineering) and the influence to do that comes from someone (the designer of the map) who is often not even aware that this might happen and is usually not really happy about this being the case.

This simple form of mapping for the renderer is widespread and those who do this – while they usually know they are doing something that is not quite right – are usually not fully aware of why they are motivated to do so and what consequences this has in terms of data quality. In most cases they simply consider this a kind of shortcut or procedural cheating. The specific problems of the whole field of interaction between map designers and mappers by the way is something i have discussed in more depth before.

There is another variant of mapping for the renderer (or more generally: mapping with specific consideration for a data user) that is less direct that i would call preemptive mapping for the renderer. A good example for this is the popular is_in tag (and variants of it like is_in:country) which indicate the country (or other entity) for example a certain town or other place is located in. I am not aware of any application that depends on this tag to work properly. Taginfo lists Nominatim as the only application actually using this. The very idea that it makes sense in a spatial database to manually tag the fact that a certain geometry is located within another geometry is preposterous. Still there are more than 2 million objects with this tag in the OSM database.

Why this happens has a lot to do with cargo cult. In fact quite a lot of tagging ideas and proposals developed and communicated in OSM can largely be classified as cargo cult based and this is one of the reasons why many mappers look down on tagging discussions. The very idea that any desire to document an observation on the ground in OSM needs to go through some universal classification system is inherently prone to wishful thinking. Sometimes a sophisticated structured tagging system is developed to make it attractive for developers to implement which luckily often ensures it is neither used by mappers nor data users. The idea of an importance tag that re-surfaces every few months somewhere falls into the same category. Out of the desire to have an objective and universal measure of importance for things people invent an importance tag and hope the mere existence of this tag will actually produce such a measure.

But not all of such mapping ideas are non-successful. We also have quite a few tags that were invented because someone thought it would make it easier for data users to have this and where mappers keep investing a lot of time to actually tag this – like the mentioned is_in. Or the idea to map things as polygons that could just as accurately be mapped as linear geometries or nodes – like here.

The problem about this is not only the waste of mapping resources, it also sometimes encourages data users to not invest into interpreting more sensible mapping methods. Preemptive mapping for the renderer – even if based on considerations that make some sense – always aims for technologically conservative data interpretation. This way it hampers actual innovation and investment in intelligent and sophisticated interpretation of mapper centered tagging and mapping methods. The is_in tag for example was invented back in the early days of OpenStreetMap where there were no boundary relations that could be used to automatically check where a place is located. So instead of inventing such a better suited solution for the problem someone took the technologically simple route to put the burden of this on the mapper. Luckily in this case this did not prevent the better solution of boundary relations and algorithmic point-in-polygon tests being developed and established.

And while attempts from data users to directly influence mappers to create data that is easy to interpret for them are often quite easily spotted and rebutted the preemptive variant from side of the mapper is practically often less obvious. And also the motives why a mapper uses or supports a certain problematic tagging are often complicated and unclear.

So if – as a mapper – you want to really support and encourage competent data use better ignore any assumed interests of data users and map as you as a mapper can most efficiently represent your observations on the ground in data form.

Leave a Reply

Required fields are marked *.

*

CAPTCHA

*