Geocomputation for Geoscience: Crowdsourcing

PhD student and King’s Geocomputation member Alejandro Coca-Castro attended Europe’s premier geosciences event, The European Geoscience Union (EGU) General Assembly, in Vienna, Austria (April 24th – 28th 2017). In addition to presenting his preliminary PhD results in the session “Monitoring the Sustainable Development Goals with the huge Remote Sensing archives”, Alejandro kindly dedicated part of his attendance at EGU to capture the emerging Geocomputation fields applied to Geosciences, and in particular for land and biosphere research. In this post Alejandro summarises the latest advances in crowdsourcing presented at EGU, which he sees as one of the two main emerging fields revolutionizing the data-driven analysis allows knowledge-production.


 

Public participation in science is on the rise, and citizen science is playing a fundamental part in this. Citizen science is the participation of the public, non-professional scientists, in scientific research – whether it be in data analysis, data collection, community-driven studies or global research. According to a recent special issue of the Remote Sensing Journal, citizen science and projects which are based on user-generated content have dramatically increased during last decade, in particular to support analysis based on Earth Observation and Environmental sensing data. The EGU session “Citizen science and observatories for environmental monitoring, planning, and disaster resilience building” presented developments in the management of crowd-sourced environmental data, and how it can be used in the context of policy support and local planning.

picturepile

Fig 1. Traditional scientific data-driven analysis is now being favoured by so-called ‘citizen science’, through which  citizens can contribute to science and increase awareness of the global sustainability challenges. Source: Geo-wiki (2017).

One of the research initiatives presented in the session was the successful Geo-wiki project led by International Institute for Applied Systems Analysis (IIASA). Through involving volunteers from all over the world, the Geo-Wiki project has been able to  tackle environmental monitoring problems relating to flood resilience, biomass data analysis and classification of land cover. Geo-wiki’s most recent campaign called ‘Picture Pile’ was presented to the EGU attendees as a citizen-powered tool for rapid post-disaster damage assessments (Figure 2, below). Picture Pile, which was originally designed to identify tree loss over time from pairs of very high resolution satellite images, announced the start of its new campaign to crowdsource post-disaster data from the Hurricane Matthew, which affected large regions of Haiti in September 2016. According to the authors’ campaign, “the proposed campaign will not only help to increase citizen awareness of natural disasters, but also provide them with a unique opportunity to contribute directly to relief efforts”. Anyone can get involved in the  current Picture Pile campaign and further info is provided here.

paperpile

Figure 2. Example of the mobile application interface designed as part of the Paper Pile campaigns for crowdsourcing rapid post-disaster damage assessments in developing countries. Source: IIASA (2017).

Dr. Steffen Fritz, main leader of the Geo-wiki project, explained to me that part of the success of the Geowiki campaigns is based on the transparency of the project (i.e. making all the collected data openly available), a dedicated research investment in rigorous methods/collaborative networks to use, analyse and recycle the collected data and last but not least providing fair acknowledgements to all volunteers involved (i.e. via co-authoring them in peer-review publications derived from each campaign).

Dr. Fritz admits even though the use of crowdsourcing for earth observation is still at an early stage, the huge potential arising from the combination of both data streams is already very clear. Challenges still remain, not least the need for more efficient methods to encourage citizens to collect data, the quality of crowdsourced data, data conflation, and the combination of crowdsourcing with other technologies and methods applied by experts (further details are provided here).


 

Interested in how Big data technologies are revolutionizing the way to collect/extract knowledge for data-driven? See Alejandro’s earlier post.

The author is grateful to the Geography Department Small Grants and the P4GES: Can Paying for Global Ecosystem Services reduce poverty? project for providing funding for Alejandro’s successful attendance to the EGU General Assembly. Revision of English version by Sarah Jones.

For updates about Alejandro’s research follow @alejo_coca on twitter.


Feature Talk: Prof. Sergio Rey talks about PySAL, Open Source & Academia

We’re really pleased to announce that on Wednesday, 22 February Professor Sergio Rey, of the School of Geographical Sciences and Urban Planning at Arizona State University will be discussing the Python Spatial Analysis Library (PySAL). His talk will provide an overview of PySAL and illustrate key components of the library drawing on examples from regional inequality dynamics and urban analysis.

Future plans for PySAL and related projects will also be outlined. Lessons learned in directing a distributed, open source project will be shared with a particular emphasis on the challenges and opportunities found at the intersection of open source and the academy.

The talk will be followed by drinks and a chance to speak informally with Prof. Rey, or just to mingle and chat with other researchers.

When:

Wednesday 22 February at 5:30pm

Where:

Room S-3.20, Strand Building, WC2R 2LS

https://goo.gl/maps/7zmjc6xGmuA2

Download the flyer: serge-rey-talk-22-february.


Humanitarian Mapping Night

On Monday 21st March 2016, Faith Taylor and I managed to organize a MissingMaps mapathon here at KCL.

What follows is not a mere report of the event (it’s been great fun, just look at the pictures!), but rather an attempt to cover certain aspects of a mapathon which usually might be overlooked, and that I instead consider to be of interest for an academic audience.

Background

Let’s start first with an obligatory (short) background on the Missing Maps initiative.

Quoting from the MissingMaps website:

Each year, disasters around the world kill nearly 100,000 and affect or displace 200 million people. Many of the places where these disasters occur are literally ‘missing’ from any map and first responders lack the information to make valuable decisions regarding relief efforts.

Missing Maps is an open, collaborative project in which you can help to map areas where humanitarian organizations are trying to meet the needs of vulnerable people.

Masterfully summed up with a one-liner, their aim is thus to:

Put the World’s Vulnerable People on the Map

Hence MissingMaps (from now simply referred to as MM) acts as a catalyst to solicit new contributions on OpenStreetMap (OSM) in areas that otherwise would tend to be:

  • Under-represented
  • At potential risk of Natural Hazards

This helps organizations and NGOs such as Médecins Sans Frontières/Doctors Without Borders (MSF), the Red Cross and the Humanitarian OpenStreetMap Team (HOT) to carry on their field work with up-to-date cartographic products, while at the same time enriching the OSM database.

 Invaluable tool for research

As part of the DfID-ESRC funded Urban Africa Risk Knowledge Project (Urban ARK), focused on breaking the cycles of risk accumulation in sub-Saharan Africa, Faith’s research requires better understanding of what structures might be impacted by hazards such as earthquakes and floods, and how people and goods move about during a disaster. This clearly relates to improving also our understanding of the built infrastructure in a hazard-prone city.

Karonga, a small town in Northern Malawi part of the Urban ARK initiative, only a couple of weeks ago wouldn’t have met such requirements due to a complete unavailability of data.

But given the open nature of OpenStreetMap, which is freely editable by anybody, the mapathon has proven to be a powerful way to improve the basemap of Karonga. Helping plenty of other NGOs and working in the area on topics such as development, sanitation and health, in addition to contributing to Faith’s work.

mm1
Kicking off the mapathon

 

Networking

This leads us to the second point of this post: the additional benefit of hosting a mapathon isn’t just limited to an evening of fun (for those of you who possess a penchant for maps). But it’s a rather excellent moment for stepping outside the traditional boundaries of academia and connect with a wide breadth of professionals.

Checking the guest list we realized in fact that only a portion of all the guests actually were part of KCL, with a good amount of external attendees coming from all walks of life: NGO and humanitarian crisis mappers, GIS technicians specialized in Natural Hazards, Red Cross UK members etc..

During the evening we had a few hours at our disposal to get to know new people. And not only while mapping or during the break over a slice of pizza! Network building and socializing was actively encouraged, as throughout the whole event a whole range of spontaneous talks ignited discussions and  interesting topics were shared among the mappers.

Andrew Braye, GIS team lead with the British Red Cross, provided a list of “GIS-sy tips”,  events and people from the geospatial community worth to look at:

img_1645
Beer and Maps

A Quick Note on Dissemination

Lastly, as with projects of different nature, communicating the results is of paramount importance.

The OSM community offers an easy tool,  developed by Pascal Neis, which can be used to monitor and retrieve stats from a mapathon. The tool filters changesets by a specific comment, which, in our case, was the #UrbanArk hashtag.
See it in action here.

Another approach is to get the data and then render it yourself. This is precisely what I’ve done to produce the slippy map hereafter:

karonga-fast

 

Firstly I’ve downloaded all the buildings mapped since our task (numbered #1641) opened on the HOT Tasking Manager. To do so I’ve used an OverpassTurbo query (try it here):

[diff:"2016-03-14T15:00:00Z","2016-03-24T15:00:00Z"];
(
 way["building"](-10.021215, 33.770943,-9.8744528,33.962517);
);
out body;
>;
out skel qt;

The query calls the Overpass API asking for all the polylines tagged with a key property equal to “way” regardless of the value of such property (Remember that all OSM features are “classified” on the basis of a key-value tagging system!). This means that I’m retrieving all buildings regardless of their use/typology (i.e. schools, churches, residences..). I’ve also specified a Bounding Box and a starting+ending date to temporally delimit the search.

I’ve then used Mapbox GL JS to create two layers, in order to render the before/after state.

If you want to know more, I’ve created a repo on my Github account where you can download the code and play with the map.

Take-Away Points:

The aim of this post was to account for the KCL Geography for Missing Maps event not just by giving a narrative of a Mapathon night (you should come and experience it yourself! Monthly events are scheduled in London and over the world) but rather to shortly explain its value and potential for an academic crowd.

So remember, a Mapathon is:

  • quick and easy to organize
  • a powerful catalyzer of interest toward a topic and an area, that might help gather data for your research
  • an effective way to connect with other communities and professionals outside of the Academia

 

karongaok

Aspect-Slope Maps in QGIS

While working with Naru to design our new 2nd year GIS methods training course (with parallel QGIS and ArcGIS streams!), I came across a rather striking map on the ESRI blog that managed to combine both slope (steepness) and aspect (direction) in a single representation. This post explains both a problem with the way that the colour scheme was specified and how to replicate this type of map in QGIS (with style sheet).

The Inspiration

Here’s Aileen Buckley’s Aspect-Slope map in all its glory – this is a the area around Crater Lake, Oregon, and you can see that it neatly captures both the direction of slopes (aspect) and their steepness (degree). So features like the crater stand out really clearly, as do what I assume is evidence of lava flows and such, while lesser features gradually fade towards grey, which means flat.

aspect-slope_map

So these maps combine two properties:

  • The direction of the slope is expressed in the hue – different directions are different colours.
  • The steepness of the slope is expressed by its saturation – steeper slopes are brighter colours.

Rather than just jump into providing you with a style sheet, I think it’s useful to trace this back to its constituent parts as it turns out that ESRI has made a mistake in setting up their colour maps.

Aspect Mapping

Aspect maps give the viewer a sense of the direction in which various slopes derived from  a Digital Terrain Model (DTM) lie – typically, we do this by dividing the angle of the slope into eight quadrants: North, Northwest, West, Southwest, South… well, you get the idea.

Here’s an example of what the standard aspect map out of ArcMap looks like as posted by the Rural Management and Development Department of Sikkim:

10sikkim-village-aspect

This, helpfully, gives us the ranges that we’ll need for our aspect-slope map. Note, however, that we don’t really have any idea how steep any of these obvious hills are.

Slope Mapping

Slopes maps are, obviously, intended to fill in the gap in terms of how steep an area is. Typically, we can measure this as either a degree value from one raster cell to the next of the DTM or as a percent/ratio (1-in-10 gradient = 10%). Here’s a nice example looking at the link between coffee bean growing areas and slope in Costa Rica:

costarica_bean_atlas_slope-rb-new

Unlike the aspect map, the divisions used in the slope map seem to be largely arbitrary with no real consensus on the mapping between measured steepness and terminology. The clearest guidance that I could find came from The Barcelona Field Studies Centre and looked like this:

Slope (%) Approx. Degrees Terminology
0.0–0.5 0.0 Level
0.5–2.0 0.3–1.1 Nearly level
2.0–5.0 1.1–3.0 Very gentle slope
5.0–9.0 3.0–5.0 Gentle slope
9.0–15.0 5.0–8.5 Moderate slope
15.0–30.0 8.5–16.5 Strong slope
30.0–45.0 16.5–24.0 Very strong slope
45.0–70.0 24.0–35.0 Extreme slope
70.0–100.0 35.0–45.0 Steep slope
> 100.0 > 45.0 Very steep slope

A Better Aspect-Slope Map Scheme

In order to create an aspect-slope map, we need to combine the two data ranges into a single number that we can use as a classification, and  this is where the ESRI blog approach goes a bit off the rails. In their approach, the ‘tens column’ (i.e. 10, 20, 30, …) represents the steepness – so 0–5 percent slope=10; 5–20 percent slope=20; and 20–40 percent slope=30 – and the ‘units columns’ (i.e. 0–8) represents aspect – so 0–22.5 degrees=1; 22.5–67.5 degrees=2; etc.

The problem with this approach is that you have a lot of problems if you want to add or remove a steepness category: in their example the highest value is 48, which means ‘highest value’ and an aspect of Northwest. But what if decide to insert a class break at a 30 percent slope to distinguish more easily between ‘Extreme’ and ‘Steep’? Well, then I need to redo the entire classification above 30… which is really tedious.

If we switch this around such that aspect is in the tens column (10–80) and steepness in the units column (0–9) then this becomes trivial: I just add or remove breaks within each group of 10 (10–19, 20–29, etc.). No matter how many breaks I have within each aspect class, the overall range remains exactly the same (10–89 if you use the full scale) regardless of the steepness classification that I’m using. It’s not just easier to modify, it’s easier to read as well.

Implementation in QGIS

For all of this to work in QGIS, you need to generate and then reclassify a slope and an aspect analysis from the same DTM. You can do this using outputs from the raster Terrain Analysis plugin (that’s the point-and-click way), or you can build a model in the Processing Toolbox (that’s the visual programming way). I personally prefer the model approach now that I’ve finally had a moment to understand how they work (that’s a topic for another post), but one way or the other you need to get to this point.

Regardless of the approach you take (manual or toolbox), once you’ve got your two output rasters you then need to reclassify them and then combine them. Here’s the mapping that I used to reclassify the two rasters as part of a model. You would copy these lines into text files and then use the GRASS GIS reclassify geoalgorithim while specifying the appropriate reclassification file.

Aspect-Reclassify.txt

0.0 thru 22.499 = 10
22.5 thru 67.499 = 20
67.5 thru 112.499 = 30 
112.5 thru 157.499 = 40
157.5 thru 202.499 = 50
202.5 thru 247.499 = 60
247.5 thru 292.499 = 70
292.5 thru 337.499 = 80
337.5 thru 360.5 = 10

Slope-Reclassify.txt (for percentage change)

0.0 thru 4.999 = 0
5.0 thru 14.999 = 2
15.0 thru 29.999 = 4
30.0 thru 44.999 = 6
45.0 thru 100.0 = 8

So that’s a 5-class steepness classification, but you could easily set up more (or fewer) if you needed them.

Once you’ve reclassified the two rasters it’s a relatively simple matter of raster layer addition: add the reclassified slope raster to the reclassified aspect raster and you should get numbers in the range 10–88.

Here’s the model that I set up (as I said above, more on models in another post):

Aspect-Slope-Model

Specifying a Colour Map

Taking the ‘Aspect Slope Map’ output, all we need to do now is specify a colour map. I took the colours posted by ESRI in the colour wheel (as opposed to the ones specified in the text) and converted them to hexadecimal since that was the easiest way to copy-paste colours. I think, however, that I’ve ended up with a slightly ‘muddier’ set of colours than are in the original Crater Lake set as you’ll see with my ‘Sussex Aspect-Slope Map’ below:

Sussex Aspect Slope Map

And, finally, the QGIS style sheet file is here (sorry about the zip format but .QML is not a recognised style type):

Aspect Slope Style – Close to Original.qml

Wrap-Up

I’m sure that this style sheet could be further improved (and may even try to do so myself, though I’d also welcome submissions from anyone with some time on their hands), but at least this gives users and easy way to combine representations of slope and aspect in a single map using a reclassification scheme that is simple to extend/truncate according to analytical or representational need. Enjoy!