This blog post isn’t a formal evaluation of the usability of OSM’s software or the equipment used for mapping. It is not meant to attack particular software; The software and implementation of OSM deserves many medals with equal amount of recognition.
This post is about things I noticed while mapping in Tandale, there is no statistical analysis, I have no dependent or independent variables, it’s based mainly around anecdotes and conversations with people. Though this doesn’t exist as a formal ethnography, it could serve for some useful pointers in future.
As we had netbooks with a small-ish (11″) screen-size and a trackpad, mice are essential for mappers getting started. In month spent in Tandale the designated editors have become JOSM gods with the majority of students and community members having fair literacy within JOSM’s processes. However when starting, the software was made accessible to the mappers purely through using a mouse. Most of the mappers were familiar with mice, whereas a trackpad was a piece of technology that wasn’t commonly used.
Conflicts commonly occurred within JOSM, in that groups where editing and uploading areas that they had mapped independently. This was difficult to control at first, as we had started with a blank slate, however boundaries of the sub-wards was relatively well known and demarcated by physical boundaries. Regardless groups wandered into areas which weren’t theirs to map. With the division of labour, in that roughly half were mappers undertaking the bulk of the surveying and with the others editing. When conflicts occurred the process was occasionally esoteric, especially if the group in question had been editing for a while.
To counter this I requested that each of the different sub-ward teams follow the mantra of save, upload and download often. Unfortunately this, on many an occasion, fell on deaf ears. This just meant conflicts were a laborious process, how could they be made better? Also JOSM’s autosave feature was a godsend, inevitably something would crash, causing people to start again.
Within the final presentation to the wider community and stakeholders, one of the points raised was incorrect spelling. There is autocomplete in JOSM, however it seems that if a spelling mistake got in first, like ‘Madrasah’ (an Islamic school, with debate on its correct spelling anyway) this would filter down, with the new mappers believing that the system is right. This would start adding clunky bits of software onto something that was never designed for spelling correction, but should plugins be created to improve this?
Due to the informal economy within the slums formal medical advice and dispensing is very rare. The community-at-large simply cannot afford ‘professional’ medical care. This has led to ‘dawa’ – medicine – shops dispensing everything from medical advice to prescription medication. Formally defining these structures into OSM is difficult, we could just create custom presets, it’s something done within Map Kibera and Map Mathare.
The issue here is that we are using the same ‘custom’ presets repeatedly. It surely would be better to include the commonly used attributes (common when mapping in environments such as Tandale/Mathare/Kibera) in the JOSM package itself? Is this feasible?
Satellite Image Tracing
One of the experiments that ‘failed’ was the tracing of satellite imagery. Bing were very kind in releasing their imagery to the OSM community to derive data, and our initial idea was to derive building outlines from this imagery. Initially it was perceived that tracing went well, some buildings weren’t quite perpendicular but using JOSM’s built in ‘q’ function fixed this. When map completeness was approaching, validation errors were caught informing that pathways were going through buildings and vice-versa. There are three explanations for this;
- The GPS has recorded an inaccurate position, i.e. path through the environment due to the accuracy being imprecise. (Technology Error)
- When editing the editor has generalised a GPS position or incorrectly mapped a building. (Human Error)
- The imagery is not rectified properly, or some error exists in the processing/the quality of a ‘high’ enough quality with which to derive information. (Human and Technology Errors)
These factors are a combination of human and technical problems, in this case I believe it is a culmination of each of the factors. Some of them, especially with image quality and GPS accuracy would presumably need some sort of best practice to be implemented. Other sources of human error in the editing process are harder problems, especially without a comparable dataset, this is a more open ended problem.
When I joined OSM I was a student in a foreign city, with no map with which to explore with. A massively pro open source friend recommended the OSM project. I already had a GPS from my time working at a camping store during summer holidays so it was a match made in heaven really. My first edit was of the D400 road from Nancy to Lunéville around 2007/8 then I set to work in the area.
The community was very small and so, presumably was the power of the servers; it would take a few days for anything to be rendered on the OSM homepage. Now something uploaded can take anything from five minutes to an hour. The server administrators deserve more recognition in their services, so if you meet them, buy them a drink – they deserve it.
In summary, I believe that the tools we use in OSM are great, none of what I’ve written is a slant at a particular software or person. I believe that we should however consider certain points about widening access to the software in making it more usable. I also welcome comments below!
Written and submitted from the World Bank Offices, Washington DC (38.899, -77.04256)