analysis

Using Computer Vision to Identify Mangrove-containing pixels in Satellite Imagery

This blogpost has been written by a team of 3rd-year BTech students from PES College, Bangalore: B Akhil, Mohammad Ashiq, Hammad Faizan and Prerana Ramachandra . They are collaborating with us on a research project around the use of computer vision and satellite imagery for mangrove conservation purposes.

Mangroves are plants  that grow in salt marshes, muddy coasts and tidal estuaries. They are biodiversity hotspots and serve as nurseries for fish stocks. They also help in maintaining the quality of water by filtering out the pollutants and sediments. Mangroves can flourish  in places where no other tree can grow, which makes them important ecosystems that help prevent coastal erosion and provide protection from flooding and cyclonic events. Furthermore, mangroves have the highest per-unit area rates of carbon sequestration (Alongi 2012) among any ecosystem, terrestrial or marine. Despite the ecosystem services they provide, mangrove forests are among the most threatened ecosystems on the planet. Globally, we have already lost 30-50% of all mangroves forests (WWF Intl. 2018) in the last 50 years and mangroves continue to be cut at rates 3-5 times higher than terrestrial forests every year.

One part of the solution in the puzzle to better conserve mangroves is to better document and monitor their existence, and the ecosystem services that they provide. So far, Technology for Wildlife has used traditional remote sensing methods on satellite and RPA imagery to understand the extent of mangroves. Our team is experimenting with the  use of computer vision to detect mangroves in satellite imagery. Through this project, we hope to develop this technique and compare its accuracy with that obtained using traditional spatial analysis methods. We  are also interested in this project because of the possibility of implementing a machine learning model that could become better  at detecting mangroves over time. Finally, the prospect of creating an automated monitoring system that systematically evaluates satellite data and detects changes in mangrove cover could be a significant tool for the conservation of mangrove ecosystems, both in Goa as well as globally.

In the rest of this post, we will outline the methods we considered for this project , as well as our reasoning for our final selections. The three major categories of  methods we considered for this project are:

(i)Machine Learning approaches, 

ii)Deep Learning approaches and 

iii) Image Processing Techniques. 

The Machine Learning approach  includes techniques such as decision trees, which is an approach of vegetation classification done by matching the spectral features or combinations of spectral features from images with those of possible end members of vegetation types. Other techniques include K-Means and IsoData algorithms, both of which are unsupervised, easy to apply and widely available in image processing, geospatial information and statistical software packages. 

The Deep Learning approach deals with architectures such as classification using Siamese residual networks (SiResNet) in which a 3-D Siamese residual network with a spatial pyramid pooling (3-D-SiResNet-SPP) is used which learns discriminative high-level features for hyperspectral mangrove species classification with limited training samples. Other potential techniques which could be used for better training of the model is the Chopped picture method, where images are dissected into numerous small squares so as to efficiently produce training images, and Convolutional Neural Networks, which are a class of deep neural  networks, most commonly applied to analyzing visual imagery. One could also use Mask - RCNN, which is a deep neural network designed to solve instance segmentation problems in machine learning or computer vision algorithms. An architecture which can be used for segmentation is a U-net neural network which is a standard CNN architecture for image segmentation tasks.

Under Image Processing, the techniques available include Gabor Filtering (which is widely used in image texture segmentation) feature extraction (where we use Hadooop to extract features from large datasets) and the Colour based approach (it deals with methods like k-means clustering and colour extraction using HSV model), among others. 

Choosing an appropriate method depends significantly on the data available. For training our model we have used USGS EarthExplorer to download Landsat 8 images. Each image consists of 8 channels, containing spectral information across several different wavelengths in the visible and near-infrared portions of the electromagnetic spectrum. The samples used to train the model were labeled at the pixel-level i.e. each pixel in the sample has an attribute value.  These attribute values are binary in nature, with a value of 1 representing the presence of mangroves, and a value of 0 indicating the absence of mangroves. Due to the limited spatial resolution of Landsat images, direct visual interpretation is difficult. The criteria initially used to label the mask data were a combination of altitude values from SRTM data and NDVI values from Landsat 8 data. If a specific pixel meets the required criteria to be tagged as ‘mangrove’, then it is labeled with a value of 1, or else given a value of 0.  For future iterations, we’ll be developing a masking process that includes aerial imagery and more sophisticated spatial analyses.

The method we chose for our project is segmentation using a U-net neural network. U-Net is considered to be a standard CNN architecture for image segmentation tasks. Segmentation is similar to image classification but in segmentation instead of just classifying the image based on the object present each pixel is classified to belong to a specific class i.e. segmentation requires discrimination at pixel level. U-net was originally invented and first used for biomedical image segmentation. Its architecture can be broadly thought of as an encoder network followed by a decoder network. 

The encoder is the first half of the architecture. It is usually a pre-trained classification network like VGG/ResNet where convolution blocks are applied first, followed by  maxpool downsampling to encode the input image into feature representations at multiple different levels. The decoder is the second half of the architecture. The goal here is to semantically project the discriminative features learnt by the encoder onto the pixel space to get a dense classification. The decoder consists of upsampling and concatenation followed by regular convolution operations. Upsampling is done to restore the condensed feature map to the original size of the input image, therefore expanding the feature dimensions. Upsampling is also referred to as transposed convolution, upconvolution, or deconvolution.

 

The U-net architecture offers some advantages over other segmentation techniques. In U-net architecture, the network is input-image size agnostic since it does not contain fully connected layers. This also leads to a smaller model weight size, hence also making it computationally efficient. The architecture is easily understandable, and can be scaled to have multiple classes. Architecture works well with a small training set, due to the robustness provided with data augmentation.

Deep U-net architecture is employed to perform segmentation. Image augmentation is used for input images to significantly increase training data. Image augmentation is also done while testing and mean results are exported.We plan on using Tensorflow Keras with python and its libraries to build our model, which we’ll be running on real-world data.

If you have any questions or comments on our work, please reach out to us through the contact form on the website.

Using Google Earth Engine to map mangroves in Goa

Over the last few days of 2020, I’ve been learning how to use Google Earth Engine (GEE). Guided by the tutorials provided by NASA’s Applied Remote Sensing Training Program (NASA-ARSET) on mangrove mapping in support of the UN’s Sustainable Development Goals, I’ve been attempting to use GEE to map mangroves in my area of interest - St. Inez Creek, Panjim, Goa. While I’ve conducted similar exercises using traditional desktop-based GIS software before, I’m both a new GEE user and new to JavaScript coding.


The first part of the exercise consisted of loading satellite data into GEE. Compared to finding relevant satellite images for an area, downloading them onto my device and loading them into desktop GIS software, the process in GEE was much faster and easier for me to conduct. The next step consisted of drawing polygons for the area of interest. This was similar to creating vector polygons in GIS software, and the intuitive interface made it straightforward to begin and pause polygon creation, as well as to edit existing polygons. Exporting these into kmls though took a lot of time to process, at least on my device.

Fig. 1: Creating polygons for my area of interest in St. Inez, Panjim, Goa.

Fig. 1: Creating polygons for my area of interest in St. Inez, Panjim, Goa.

I was looking at decadal change in the area between the years 2009 and 2019. The script made available with the NASA-ARSET tutorials creates mosaics by first looking for images from a year before and after the designated year of interest, and by then masking clouds. I was only able to do this in GEE because the JavaScript code for this was already written out and available to me, but I found this part of the processing extremely powerful, especially compared to doing it on my own device. I then applied vegetation indices onto these mosaics, creating false colour composites that could be used to identify vegetation in my area of interest between 2009 and 2019.

The fourth major step consisted of creating a Random Forest Model for both the years. For this, I used the false colour composites of the mosaics, derived using the vegetation indices in the previous step, to create categories of mangrove and non-mangrove areas, and marked examples of each using visual identification. Because I had clear instructions available for this part (via the tutorials), this was a straightforward procedure. The mangrove and non-mangrove categories had a property of land cover with a binary value of either 0 or 1. I imagine that such a table would look similar to an attribute table, although I was unable to export it to a shapefile to check.

Fig. 2: Visual classification of mangroves for training data.

Fig. 2: Visual classification of mangroves for training data.

After training the data, I ran the Random Forest Model  JavaScript code in GEE . On viewing the area classified as mangrove extent for the year 2009, it looked like a lot of  what should have been mangroves had been marked otherwise.  An internal test indicated an accuracy of 0.7; ideally, the closer this value is to 1, the more accurate the model. To improve the accuracy, I added more training data and then ran the model again. This time the accuracy was much higher and the area under mangrove extent appeared to be depicted more accurately.

Fig. 3: Mangrove extent in 2009, as determined by the Random Forest Model implemented in GEE.

Fig. 3: Mangrove extent in 2009, as determined by the Random Forest Model implemented in GEE.

The outputs of mangroves appear to be fair estimates of actual ground-level mangrove extent, but would need to be verified using additional data and alternative methods to obtain an objective assessment as to its accuracy. The model estimated that within my area of interest, mangrove extent in 2009 was 29.82 ha while in 2019 it was 28.74 ha. I tried to run an external accuracy test using the Class Accuracy plugin in QGIS, which reviews random stratified data from the random forest to check whether it has been classified correctly. However, I kept receiving errors while trying to produce an error matrix for the classification using the plug in so that’s something I still have to work on.

Fig. 4:  A screenshot of the GEE console displaying the error matrix for the model

Fig. 4: A screenshot of the GEE console displaying the error matrix for the model

The second part of the exercise was to create a GEE application which would allow a user to interact with the data directly, visualising the change in mangrove cover in the Area of Interest within the determined time period. I had some setbacks with this section, which I’ll describe in detail.

I began by exporting the mangrove extents calculated previously into raster images to be used for classification within the GEE app I was creating. The images were then imported into the script, and used as the basis of the visualisation. When I ran the JavaScript code I’d modified, the app appeared but the links from the buttons appeared to be broken; despite picking a year, no layer appeared on the map. The process of looking for errors felt similar to that I’ve encountered in RStudio, where the line of code with the error was highlighted,  and some indication of the error’s nature was provided as well. This definitely made reading and editing the code easier for a GEE/JavaScript novice like me. Having fixed this, I ran the code again and this time the layers appeared; however, instead of displaying mangrove extents, fixed-area blocks appeared within the area of interest for both years (Fig 5).

Fig. 5: The rectangular block error in my GEE app; this should depict mangrove extent, but doesn’t..

Fig. 5: The rectangular block error in my GEE app; this should depict mangrove extent, but doesn’t..

Despite several scans of the script to find errors and understand why this happened, I’m still quite confused.  The issue appears to be in the images that I’m exporting. Even though the image being exported is the area classified as mangrove extent, which appears correctly on the map, when exported as an image, it’s saved as these blocks in the area. I’m still trying to figure out exactly what’s going wrong here.

Overall, this was a fun exercise to learn and work through, and a good introduction to Google Earth Engine’s capabilities for conservation geography. The entire process of actually processing the images, applying indices and using a Random Forest Model was faster in GEE than it would have been on my desktop, thanks to the code available to me via the NASA-ARSET tutorials. With regard to setting up the GEE apps, I still have a lot of trouble-shooting to do over the next few weeks. If you have any leads, please do comment on this post, or send me an email via our contact form.

How we use Excel for geospatial data analysis and visualisation

I’ve been giving a number of online talks over the past few months, talking about both the general nature of our work as well as about how we accomplish specific technical tasks. During one session of the latter type, I mentioned how a lot of our GIS work actually happens in MS Excel and one of the audience members wanted more information on what that actually entailed. I attempted an answer then, but a GIS task this morning really highlighted how much I need and love MS Excel. I’m going to use this blogpost to document exactly what I did, so if I’m ever asked this question again, I’ll have some documented proof to support my response!

In brief, I was provided with an Indian Government gazette notification detailing the locations of a set of offshore mining blocks off the coast of India. This was in PDF format and while it comprised both text and tables, the relevant data was in tables alone. There seemed to be only 60 or so rows of data, with about 9 columns. In the distant past, I would have just hand-coded the entire thing using the num-pad on my keyboard, but this time I used one of my new favourite OCR tools (Convertio) to rip the relevant pages of the PDF into a Word document. The tables were then copy/pasted into Excel, and that’s where the real work began.

The original data columns in the gazette notification PDF

The original data columns in the gazette notification PDF

As can be seen from the image above, the spatial information is in an odd format, not really ingestible by most GIS software which needs, at a minimum, coordinate pairs to represent points. In addition, I prefer working with decimal degrees rather than the degree-minute-second format as I’ve had some traumatic experiences with apostrophes and quotes in GIS software. So, now working only in Excel, I first did a quick check/fix to catch the few errors from the OCR process ( 8’s read as 3’s, 7’s read as 1’s), I created four new columns (Lat_E, Lat_W, Long_S, Long_N). Each deg-min column pair was converted into a decimal degree format in one of the new columns using the standard conversion formula [ Decimal Degree = Degree + (Minutes/60) + (Seconds/3600)]. I also created a unique ID (UID) for each row by combining the grid number with the initials of the area; for example, Block 12 in the Arabian Sea has a UID of 12_AS.

Now, for the more complex part; GIS software can ingest text files and visualise spatial data as points, lines or polygons. My desired output for this task was a demarcated text file which had all the information required to visualise each offshore mining block. One method would involve creating 3 new rows for each block record, where each row would eventually contain the coordinates for the NE, NW, SE and SW points. This could be done manually, using cell-handling commands in Excel but would be a lot of very boring manual labour, and I would then need to combine the points together in a GIS package to obtain my polygons. Alternatively, I could write a short piece of Python code which would convert the Excel sheet into a GeoJSON file with the appropriate geometry attributes. This is the most powerful of all available options, but felt like overkill for this task.

Instead, I created a new column and put together a quick cell-handling formula that converted the spatial information into a Well Known Text (WKT) polygon format that GIS software such as QGIS is capable of reading. The formula itself looked like this

=CONCATENATE("Polygon ( (",O2," ",M2,", ",P2," ",M2,", ",P2," ",N2,", ",O2," ",N2,") )")

where the cell reference numbers refer to the (Lat_E, Lat_W, Long_S, Long_N) columns in the correct pair-grouping to obtain the NE, NW, SW and SE corners of each offshore mining block.

The converted lat-long data in four columns, as well as the WKT-friendly polygon information

The converted lat-long data in four columns, as well as the WKT-friendly polygon information

The file was then saved as a Comma-Separated Value (CSV) file. I used QGIS to read the file, selecting the WKT format as the input option, and the polygons appeared! After a quick geometry repair process, I configured the labels, exported the file in KML format for visualisation in Google Earth Pro and also created a rough static map, and the task was complete.

This is just one among the many ways in which we’ve used Excel to do the initial heavy lifting for spatial analysis and visualisation tasks, reserving the more specialised GIS tools for when they’re really needed.

A rough map depicting the final polygons

A rough map depicting the final polygons