A GIS Interface for Learning Math through Social Justice Inquiry

Categories:  Kathleen Tully
Tags: ,

We are working excitedly to get our Social GIS tool live in the next few weeks. This tool allows students to explore and compare geographic data. It includes data from a variety of freely available sources such as Census demographics information, the New York State Open Data Initiative, such as the locations of food stores and restaurants, or the Envirofacts Biennial Report which provides locations of hazardous waste sites. Students can compare the demographics information other features of a neighborhood’s landscape. For example, if we compare the racial makeup and the household income of a neighborhood to the number of supermarkets where fresh produce is available, are there larger gaps in poorer neighborhoods or those populated by most minorities? Allowing students to explore in this way gives students a task rooted in a real-world problem that may even be affecting their everyday lives, ownership of the data as they tag which markets have or don’t have fresh vegetables, and encourages critical thinking as students must assemble the data to support their own conclusions. This semester, I’m also working with undergraduate students in environmental justice who were looking to find a way to analyze the locations of hazardous waste sites and the demographics of those living closest to these sites.

SGIS screenshot

Follow our code as it develops! The backend code is here and the frontend is here.

Aqueous Sensor Nodes

Categories:  Andrew Ellis, Culturally Situated Community Sensing, James Davis, Kathleen Tully, Photos, Uncategorized

In cooperation with the Sawyer Working Group, a new version of the culturally situated sensors is currently in development for deployment in rivers and lakes. These networks will hopefully provide an inexpensive means of constantly collecting data on contamination and pinpoint and eliminate sources of contamination. These sensor nodes are to have new sensors developed by Professor Sawyers team for detecting bacteria, but will build off of the platform developed previously. This project will hopefully proceed to a test deployment in Poestenkill and then potentially Lake George or the Hudson River In collaboration with Professor Chris Bystroff and Toby Michelena. It is our hope that we can get a version of this into the water by the end of the fall semester, although truthfully, it may not happen until early spring. Further deployments will follow in the spring. Once a successful deployment has been made, it is hoped that students at Albany High school can be involved by having them help develop a new generation of nodes for use at school or for deployment at one of the aforementioned locations.

While the GIS components should fit in with the work being done by Kathleen Tully. I, James Davis, am currently developing the physical nodes and software. The project breaks down into 5 parts: Communication, Power, Enclosure, Flow cell, and Sensors.

Communication:
An Android application that connects to Arduinos and downloads data has been developed, with progress being made toward Arduino to Arduino communication (so that one need not wade into the middle of a lake or large river to collect data). Hopefully this additional functionality will be completed by 10/28.
Screenshot_2014-10-21-19-49-23
Power:
Sensor nodes will be largely solar powered. The components for this have been delivered and a test setup was made to confirm viability. Assembly of the full prototype and testing has been handed of to former fellow Andrew Ellis of the Sawyer Working Group.

Enclosure:
A buoy and anchor for the first prototype have been acquired by Toby Michelena, and starting 10/23 construction on the enclosure should begin.

Flow Cell:
A flow cell is slated to be built and tested, but the necessary components are still on order and may not arrive until 10/28.

Sensors:
The bacterial sensor is currently being upgraded by several generations of sensors to one developed by Dr. DaLi Shao that is more robust, sensitive and accurate. A new PCB has been designed, fabricated, and tested for the implementation of these sensors, and a second generation is currently under review.

20140918_114449
Further sensors for turbidity and temperature are being tested as part of the system. And will be integrated before deployment.

Instructions for Arduino Temperature Sensing: Compost Computing

Categories:  Culturally Situated Community Sensing

Arduino-Compost Handout

Click the above link to download a handout detailing the set up and use of an Arduino temperature sensor and countertop compost bucket.  Use the temperature sensor to explore how the heat level of the compost changes over time!

On licensing our code

Categories:  Brian Callahan

One of the more publicly visible outputs of the 3Helix project is the computer code we produce. At the center of our code output is the CSnap project. The core of CSnap is to create an environment for computer science and mathematics that allows exploration of these important STEM concepts through an awareness that cultures operate within these mathematics. Two particularly powerful examples are Cornrow Curves [0] and Adinkra carving simulations. [1]

But 3Helix is more than just CSnap! There is a plethora of other code that makes up the 3Helix program: controlling Arduinos, GIS databases, and web front-ends are just some of the examples of other code developed to promote STEM academics and social justice. But with all these independent code projects comes an important question that has implications for the spread of social justice on the broad scale, as well as securing the future of the 3Helix program more locally. What licensing is most appropriate for these projects? A critical aspect of the social justice aspect of the 3Helix program is focused on making our code available to everyone in order to have this code produce socially beneficial outcomes that we as fellows could never imagine. Free Software licensing is the socially responsible way to achieve this goal. However, Free Software licensing is a much more nuanced endeavor than simply announcing “our code is free for everyone to use!”

As a Free Software developer, this nuance is a focused interest of mine. Not licensing the code is not an option: failure to license code retains all rights to the author, effectively killing any hopes for reuse.

For reasons of inheritance, the code for CSnap is licensed under the GNU Affero General Public License, (AGPL), [2] specifically version 3 of the license or any later version, a spin-off of the more popular GNU General Public License (GPL). [3] Both licenses say that when a user is given a program, they are also entitled to the source code that created the program. The primary difference between the two licenses revolves around the question of “Who is a user?” For the GPL, a user is someone who receives a copy of the program in a local manner: think on a CD or downloaded to one’s hard drive. The hole in this definition is that software that is used solely online, things like Facebook, have no users as defined by the GPL. The AGPL closes this hole by redefining a user by anyone who uses a piece of software, regardless whether or not that person has received a physical copy of the program.

What this means for CSnap is that anyone who uses CSnap is entitled to a copy of the source code. This entitlement is fulfilled by the offering of CSnap source code on our GitHub repository. [4]

The problem going forward, however, is what license to choose for our other projects. The AGPL is not always an easy license with which to comply: it forbids linking code licensed under the AGPL with code licensed under a different license. The only exception to this is the GPL itself, but only if using the most recent AGPL and GPL versions and only because the authors of both licenses had to explicitly write in that exception; in code lingo, they wrote in a “hack” to make the exception work.

While relicensing CSnap to another license is likely impossible, as it would require all previous authors to agree to such a change, we should turn our attention to our other codebases in the 3Helix program. While the AGPL and GPL can be good licenses to proliferate code, it is probably not the best route for the 3Helix code: it would, almost counterintuitively, reduce the ability for our code to be used for social justice. Both the AGPL and GPL may impose too many restrictions for others to reuse the code.

Instead, more permissive licenses, such as the 2-clause [5] or 3-clause [6] BSD or MIT [7] licenses, allow for greater use and reuse of our code. These licenses establish minimal barriers for code reuse. If our initiative is to generate social justice, the greater number of hands we can get using our code the better we can achieve these goals.

 

[0] https://community.csdt.rpi.edu/projects/24

[1] https://community.csdt.rpi.edu/projects/131

[2] https://www.gnu.org/licenses/agpl.html

[3] https://www.gnu.org/licenses/gpl.html

[4] https://github.com/GK-12/Snap–Build-Your-Own-Blocks

[5] http://opensource.org/licenses/BSD-2-Clause

[6] http://opensource.org/licenses/BSD-3-Clause

[7] http://opensource.org/licenses/MIT