Three maps, three lies

A lie told about space
Link: Population Density - Derek Watkins

This map shows the world's population density using a slider to move through the various density levels. Viewed at the slider's lowest density threshold, the world's continents are clearly visible. However, when the slider is set at the maximum density, the map is pretty meaningless. Plus, the extreme minimalism and low resolution of this map is very misleading. At 500 people per square kilometer, we should be able to see hundreds of metropolitan areas in the United States (Reno, Nevada is at about 800 people per square kilometer), not to mention plenty of other places in the world.

An unintentional lie
Link: US Stream Names - Derek Watkins

This map is one of a trend of maps showing local terminology across the country, in this case the names of natural watercourses. Because of the high-contrast visual design, it's easy to assume that the blackout areas either have no corresponding data, or that they don't have one predominant nomenclature. This isn't true, though - buried as a footnote to the map description, the gray and black areas are where the terms "river" and "stream" are most common. This map has essentially removed from view the largest data points in favor of the more uncommon names. I think this was an unintentional result of the visual design, as this map would've been just as interesting.

A clear distortion of the truth
Link: A Texan's Map of the United States

Novelty maps often distort reality for comedic effect. This map does exactly that by enlarging the geography of Texas in relation to the rest of the U.S., mimicking the stereotype of the proud Texan's perception of non-Texan areas as inferior and/or physically smaller. The labels also reinforce stereotypical prejudices of Texans.

Abstract noise map

Link: Can you hear me now?

In order to make a map that changed depending on the user, I used browser geolocation to center a map over the user's current location. Then I zoomed in as far as I could into the visualization I created, which paired U.S. county shapes with population density for each U.S. county.

I made a choropleth to try to estimate the average noise level for a user's current location based on the population density of the corresponding U.S. county. While the link is tenuous at best, it abstracts the idea of distinct zones of noise that I think make sense to most people.

After the browser detects your current location, you will see a huge area of bright color (because of the high zoom level). You can compare this color to the scale in the legend at the bottom-right of the map to see how your location's noise "profile" stacks up against the rest of the country. I wanted to make the visual aspect as simple as possible and I think I at least succeeded on that level.

Here's an embedded version (for geolocation please visit the link at the top of this post):

A more personal mapping experience

There is a base level of service that all Google Maps experiences provide, but being signed into a Google account really changes the amount of information available to, and usable by, the user.

One of the obvious areas where personalization can be seen is during a search. Google indexes not only your contacts but your map history to provide the most relevant location results possible (this is why I always try to save my contacts' addresses).

Another way Maps can be tailored to your needs is the inclusion of calendar event information displayed on the map. If I have an appointment on the same day, and the location of the appointment (again, needs to be stored in the calendar event) lies within current map view, Maps will display a marker showing the appointment time and estimate of travel time. I couldn't get a screenshot because it seems to take a bit of time to index this information.

You can also explicitly tell Maps about your favorite locations, like Home and Work. Keeping this up to date ensures that Maps will always try to anticipate your commute across other services like Google Now.

The bottom line is: always save address so that Google Maps can make your life easier!

Instructional "thing" on the web

Link: Print-your-own piano helper template

Part 2 of the instructional “thing” assignment was to make it accessible on the web. I wanted to make the piano template I created into a web page so that anyone with a printer could print out the design at actual size and cut it out themselves without having to measure anything.

I used some HTML5 canvas elements, JavaScript, and CSS. This was my first time using HTML5 canvas and I found it to be unintuitive. My experience with the Java-based Android canvas helped a fair amount but there were more than a few things that baffled me.

By far the biggest problem I had was that I couldn't figure out how to make an element print at an exact physical size. It turns out that the CSS in (inch) units are just multiples of fixed pixel amounts. I have a pending question on Stack Overflow and will update this post if I get an answer.

After getting things close to correct, I added instructions for the templates' use. I realized that not everyone would know a piano keyboard well enough to identify one octave starting at C, so I found an SVG image of such an octave so that people could identify this better.

One improvement I want to make is to include the physical measurements on the template so that people can measure and draw their own templates without needing a printer. Assuming that everyone has access to a printer was a major oversight.

Visualization of Citi Bike station node influence

My group's midterm is based on pruning "weak" stations and/or adding supplementary stations to the Citi Bike network in the hope of improving the system overall. The first step in this process is to identify weak stations that might be candidates for pruning, so I decided to make a visualization to get this information.

I used Gephi to create my visualization. Gephi worked best when I gave it separate data tables for nodes and edges. I loaded the Citi Bike station data (nodes) and trip data for February 2014 (edges) to form a graph.

One of the first things I realized was that the nodes could be easily divided into Manhattan stations and Brooklyn stations just by looking at the network's modularity (the strength of division of a network into modules). There are of course thousands of trips that start in Manhattan and end in Brooklyn, and vice versa, but the vast majority of trips start and end in the same borough. In the graphic below, Gephi grouped the nodes in this shape after I ran a modularity analysis (with a resolution of 2.0).

This means that pruning the weakest node overall might not affect the network as much as we had hoped it would. However, focusing on each module specifically is bound to have better results.

To determine the weakest nodes I looked at eigenvector centrality (Google's PageRank is a variant of this metric), which is "a measure of the influence a node." Connections to higher-scoring nodes are valued higher than those to lower-scoring nodes. The results (after 1,000 iterations) can be seen below. Gephi has several layout options to optimally display the network graph based on the chosen measurement (in this case eigenvector centrality). The Brooklyn visualization used a different layout for improved legibility.

Red nodes have higher scores and blue nodes have lower scores. The visualization makes it obvious which nodes are candidates for pruning; Railroad Ave & Kay Ave in Brooklyn and Leonard St & Church St in Manhattan are the lowest-scoring nodes in their respective boroughs.

This is accurate for trips made in February 2014. However to really get a sense of the all-time weakest nodes we would need to use all available data in these algorithms. There are likely seasonal changes in ridership that make certain stations less utilized in the winter.

A map of noise for the rest of my day

Making a map for the "rest of my day" was complicated by the fact that I am stuck at home sick, so I focused my efforts on understanding the noise in my own living space.

First I identified the major noise generators: coffee grinder, air conditioning, television, alarm clock. Then I eyeballed a radius for each, based my own perceptions while living here. Finally, I color-coded their respective regions.

The result is a cool-looking map that can support quite a few lies. I wanted this map to be as simple as possible so I sacrificed things like exact noise level, exact boundaries, exact measurements, and pretty much anything else that required me to leave bed.

One thing that I learned is that overlapping colors become very confusing. Originally I wanted the coffee grinder red to cover the entire apartment because the coffee grinder can be heard in all rooms. The problem was that you couldn't then tell where it started and ended, even with the red dot denoted the source of the noise. It just tinted all of the other colors red without any indication it was doing so.

Another thing became obvious in that you really need to decide ahead of time what you want to focus on. Do you treat each noise as a distinct sound? Or do you treat all noise equal and just focus on area? Or do you do both, but incorporate measurements of the noise levels to differentiate them? Or do you...

This was never meant to be a highly accurate map, but even making this inexact map made me think about exacting requirements for other mapping endeavors.

Project overview: Sonome module

Concise description
To design, construct, and implement a module for transmitting noise levels wirelessly in an urban environment.

Target user
The module is for my personal use.

User feeling
I want to feel empowered to increase the scale of my project, and confident that I can achieve my goals using the module.

User action
Once programmed, I desire to "set and forget" the module; that is, the module should require minimal tinkering after correct programming, even in failure cases.

User knowledge
I want to know that the module is operating correctly. I also want to know the noise levels where the module is located, and this information should be easily accessible to me (as the developer) even without a visualization.

Problem to solve
In order to create a realtime noise map, realtime noise data is necessary. The primary function of the module is to measure the ambient noise level in a given location and transmit this information wirelessly to a server. However, the module also needs to be robust to exist outdoors,

Recommended solution

1. Start with a homemade piezo microphone and an Arduino to measure the efficacy of such a microphone in measuring this kind of data.
2. Make the Arduino wireless, likely using a WiFi shield.
3. Measure power consumption during normal usage (reading & transmission every 200ms) and experiment with optimal settings.
4. Determine definitive power needs (batteries or solar?).
5. Finalize all components and eliminate excess
6. Iterate designs and materials for an enclosure
7. Test in real world...

Opportunities in problem space
Realtime noise maps basically do not exist for the general public. There are proprietary systems that provide such information but these are limited to professional applications. Providing this information on a democratized platform (i.e. any web browser) would promote a discussion of the role of noise in urban spaces in an accessible way. The only way to achieve this is to create a module capable of supplying this information.

General challenges in problem area
Gathering live data over a relatively large physical space is not an easy task, which I'm guessing is why realtime noise mapping is not more common. And even if you are able to deploy an array of sensors, keeping track of and presenting the data is always a concern.

Specific challenges
The main problem is requirement that the module must run and transmit data wirelessly in a variety of physical environments. Power is a significant concern because either the device needs to be self-sufficient (i.e. solar-powered) or it should run at least several months on batteries.

Another concern is mounting the module in the physical environment. The module should allow for a variety of mounting situations and weather conditions; this may suggest that the mounting system should be decoupled from the primary module design.

Research
stillspotting nyc – Non-realtime noise map focused on finding quiet areas
SoundPLAN – Proprietary software packages for grid and meshed noise map simulation
Navcon – Engineering consultants utilizing SoundPLAN software
DataKustik – CadnaA (Computer Aided Noise Abatement) proprietary software offers up-to-the-hour dynamic noise mapping
2012 Manhattan Noise Complaints – Self-explanatory static map by Karl Sluis
Citygram – "Visualizing Urban Non-Ocular Ecology" (possibly defunct)
CONTACT – Hannah Mishin's PDS project from last year that visualized sound inside ITP
WideNoise – App for reporting and displaying chronologically-disparate sound data

Technical, spatial, and interactional requirements
Technical:

• Handle a wide range of noise levels
• Run in a wide range of temperatures
• Handle failure cases without crashing
• Employ modular codebase to speed development and testing
• Queryable status

Spatial:

• The shape of the enclosure minimizes or negates effect of precipitation
• The effect of echo off or vibration of the surface on which to be mounted
• Inconspicuous design shouldn't attract unwanted attention

Interactional:

• Minimize the sensitivity of module to hyperlocal noise (e.g. "noise vandals")
• Needs to have a "set it and forget it" interaction style (for me)

Criteria/evaluation of success

1. Accurately measure the ambient noise level in the sensor’s vicinity
2. Transmit data wirelessly over Wi-Fi or GPRS several times per second
3. Easily and safely mount in a variety of built environments
4. Be quickly and economically manufactured

Besides #2, all of these criteria are subjective. For #1, a tolerance will be determined in conjunction with the proposed visualization of this data. I will define #3 through the process of creating and mounting the module. I will define #4 by researching potential materials and technologies and putting a cap on the total cost per module.

Draft timeline

Week 1 – Write project description

Week 2 – Research microphone

Week 3 – Build microphone prototype

Week 4 – Test microphone

Week 5 – Finalize microphone

Week 6 – TAKE A BREAK

Week 7 – Research wireless Arduino

Week 8 – Configure wireless Arduino

Week 9 – Finalize all electronic components

Week 10 – Research enclosure

Week 11 – Build prototype enclosure

Week 12 – Finalize enclosure

Week 13 – Final testing

Instructional "thing"

For my instructional "thing" project I attempted to create a simple device, made from a sheet of copy paper, intended to help the user learn to play the piano. "Learn" is a strong word in this case; future versions of this prototype could possibly teach piano fundamentals but my focus here was just on enabling the user to play pleasant sounds rather than nothing at all.

The basic device is a paper cutout that fits over the span of one octave starting at any C key. This is important because the C major scale is generally the first scale encountered when learning the piano as it does not include any black keys. It provides key labels for the user, but it allows acts as a base for a number of possible "shields." The basic device and a shield are shown above.

The chord shield helps the user find simple triad chords within the major C scale. Though the visual language needs improvement, the basic idea is to show finger positions of the I, IV, and V chords so that the user can quickly play a more substantial-sounding piece of music. I developed an additional shield for learning "Mary Had a Little Lamb" but, again, the visual language is at this point non-standard and could be more confusing than helpful.

Overall, I think there is potential in such a template that anyone could print or measure and draw themselves. It would be a good exercise for kids to use math in the creation of the paper cutout, and then give them a reward by enabling them to play notes and chords on a piano without needing any formal instruction.

Financial management and the poor

Chapters 6 and 7 of Poor Economics deal with the many financial risks faced by the poor. The poor are likened to hedge-fund managers in that their "portfolios" possess great risks. But unlike most hedge-fund managers, who are liable for a fraction of the assets they manage, the poor are liable for 100% of their own assets.

The poor tend to diversify their activities in the same way an investment portfolio might be diversified. This is a necessary precaution to spread risk over several domains. However, this creates a roadblock to acquiring greater skills and experience because it's "hard to become a specialist in anything without specializing in it." It seems that doing many things at a low skill level is less profitable than doing one thing at a high skill level.

The concept of informal insurance predominates as insurance plans as we know them are simply unavailable. Informal insurance refers to a system of communal sharing and lending that acts as a safety net for those in the community who have fallen on hard times, as well as those who may fall in the future. A constant circulation of informal aid can be vital to sustaining all members of such a community. Furthermore, informal insurance is usually performed on individual bases; that is, direct assistance rather than a "common pot."

Similar to micro-credit, micro-insurance schemes have been tested in poor communities with mixed results. There are major risks involved for the lenders:

"Offering reimbursement-based health insurance for outpatient care in a country where health care is at best weakly regulated, and where anybody can set up shop as a 'doctor,' seems like the first step toward bankruptcy."

Additionally, rampant corruption, commonplace in many countries, undermines any trust the poor might have in financial institutions. Government subsidies may prove to help acceptance of traditional insurance take hold by making it more affordable.

In general, "banks are unwilling to touch the poor" for a variety of reasons, but the main constraint is the cost of gathering information about the creditor. Large institutions are not equipped for the groundwork necessary in verifying a poor creditor's standing in a small rural community. This increases the interest rate and eventually boxes out the poor from even trying for a loan.

Micro-credit has been proven to be a viable option, and can more than sustain itself as a business for the lender. Unfortunately it is quite susceptible to rumor and groupthink – it can be dismantled overnight by false information spread by bureaucratic and/or political opponents of such schemes. It also puts medium-sized businesses in a tough spot; too big for micro-credit financing but still too small for large bank finance.

Class 1 response (Mobility on Demand Systems)

Intelligent urban system

Smart trash receptacles

The BigBelly Solar trash compactor is a "smart" receptacle that makes garbage collection more efficient by 1) increasing the density of the garbage to be picked up and 2) providing the status of its current capacity electronically.

Basic feedback loop

1. Receptacle accrues garbage
2. Receptacle capacity monitored by city
3. If receptacle near maximum capacity, city collects garbage

Form of governance

The receptacles are created by BigBelly Solar and controlled by the city government. The city government expects that the use of these receptacles will reduce inefficiencies and cost of garbage collection. Stakeholders include:

• BigBelly Solar (desire publicity for its product)
• City government (desire to recoup their investment and improve eco-friendly image)
• Citizens (desire improved system of garbage collection)

In practice

These particular receptacles have drawn criticism for the fact that they require the user to touch a handle on the receptacle, as opposed to ordinary garbage receptacles with an open top. This has caused a backlash against the use of the receptacle, even though the handle issue seems at a glance to be extremely superficial. Citizens have voiced concerns that it improves the aggregate garbage collection at the expense of the citizens' health (i.e. touching the surface of the receptacle could lead to illness).

Driverless cars as a mobility on demand solution

While I think driverless cars are important in the development of autonomous/intelligent vehicles in general, I don't think they are a great solution for improving urban mobility. They may seem like a natural choice given the configuration of most cities, but I believe that there are even better options if we were to consider alternative urban architectures.

The fact that urban space is made of roads greatly limits the imagination when dealing with mobility, especially the last-mile problem; that is, how to travel the last mile of your journey to a destination. If we created more urban space in which roads didn't exist, we could develop new locomotive mobility systems (e.g. moving walkways) that allowed us to move our own bodies freely through urban space without needing an external vehicle.

If all taxis in NYC were replaced with driverless analogues, we would still have many of the same problems, like traffic, refueling, pollution, and safety. However, if the number of roads was reduced, and focus was instead turned toward creating space for humans instead of automobiles, we could reduce the need for the latter and provide a more fulfilling environment for the former.

The lie and story of a Symap

A Symap is a map which uses the densities and shapes of typographical characters to convey scale data. They were commonly used in the heyday of typewriters and character-based printers which could print "graphics" by using contrasting ASCII characters.

My attempt at a Symap deals with NYC noise complaints per capita per borough, as seen below (full-screen version here):



There are a number of problems with this map. Though the characters are not nearly different enough to make a convincing story, the bigger issue is the per capita scale. The five boroughs vary greatly – 26 complaints per thousand residents in Manhattan versus less than 5 complaints per thousand residents on Staten Island, with Brooklyn, Queens, and the Bronx all somewhere in the middle.

Unless I am explicit in my terminology, I could unintentionally mislead you by showing a graphic derived from one calculation while you assume it comes from another. In this graph I used the borough populations so as to only compare the boroughs to themselves (e.g. 42,048 complaints divided among 1,626,159 residents in Manhattan gives the Manhattan per capita value). However, per capita often suggests a comparison to a whole (perhaps the entire city), espcially when the entire city is shown on the map.  In this case, we would take 42,048 complaints and divide among 8,405,837 city residents, and get a different value.

NOISE COMPLAINTS PER THOUSAND RESIDENTS
Borough	Borough- centric	City- centric
Manhattan	26	5
Brooklyn	10.5	3.3
Queens	6.3	1.7
Bronx	7.5	1.3
Staten Island	4.9	0.3

As seen in the table above, the choice of calculation can alter the "facts". Borough-centrically, the Bronx has more complaints per capita than Queens. But city-centrically, it is reversed. This data, once mapped, becomes the story.

Furthermore, we can simplify the story for the sake of a concise headline and say (in one case) that "the Bronx is noisier than Queens" without ever giving thought to what a noise complaint means. Does it mean that the Bronx is actually louder than Queens, or might it mean that Bronx residents are more inclined to complain, regardless of noise level?

This Symap is incredibly simple, but through analyzing the Lie and the Story we can see that there is an unbelievable amount of room for opinion, persuasion, and plain old error. Taking on larger and more complex mapping projects will require me to always question my methodology, even before the data makes it onto my map.

Fall 2014 courses

Building for Learning (Aidan Feldman)

The web has already revolutionized the way that people consume information, but only recently has it been taken seriously as an avenue for teaching. MOOCs, online tutorials, and interactive applications all offer different means of learning, from the highly structured to the exploratory. They raise new questions around evaluation and assessment, while providing new avenues for collaboration and opportunities for students outside of traditional learning environments. In this class, we will examine various educational platforms and tools, and get the opportunity to speak with their creators. What can we offer to teachers to make their lives easier? What features increase and sustain student engagement? The course will be largely project-based, where students will learn frontend web development skills to build new web-based learning experiences and tools.


Cloudcommuting: Rethinking Point-to-point Urban Mobility Systems (Dimitris Papanikolaou)

This course introduces the theory, underlying technologies, and operational challenges of intelligent mobility on demand (MoD) systems, using NYC City Bike sharing program as a living laboratory.

MoD systems utilize networks of parking stations and shared fleets of vehicles (bikes, scooters, automobiles) allowing users to make point-to-point trips on demand. Today, more than 650 bike sharing systems around the world mobilize 3 million trips every day while at least 200 additional systems are planned. Despite their seeming convenience and advanced technology, asymmetric trip patterns cause many stations to temporarily deplete from bikes while others from parking spaces decreasing reliability and level of service in the system. Operators spend their entire usage revenues paying gas, trucks, and workers to manually move bikes from full to empty stations. Yet, level of service is often low. In Paris 48% of users find no bikes and 58% of users find no parking spaces available. In Barcelona, 50% of the stations are either empty or full during 30% of the time.

In this course we will explore how information technology, social mechanism design, and game theory can be used to design the next generation of intelligent self-organizing MoD systems that motivate their own users to rebalance the fleet using price incentives. The course will combine lectures, readings, technical skill workshops, and a hands-on experimental project in a collaborative studio environment.


Frugal Innovation (Catherine Muther)

This course gives students conceptual and practical experience in developing ideas, tools, products and processes to augment and improve the lives of the global poor. We will use a variety of resources and methods to explore the emerging field of Frugal Innovation, beginning with an understanding of the context and constraints of living on less than $2.00 a day. Students will learn to identify key principles and challenges of designing for the Bottom of the Pyramid; for example, relentless pursuit of affordability. What are innovative models of using communications technologies to serve an illiterate market?

We will use Case Studies that address real life problems in emerging markets, particularly in healthcare and financial inclusion, where the use and potential of communications technologies is proliferating. Classes will feature cases of actual products or processes developed to solve a problem or meet a perceived need– some successful and others not. Why? How do we know what success looks like? We will look at metrics, methods and markets to explore the question of measuring impact. Entrepreneurs and field leaders will come to ITP as guests to share their knowledge and experience, and engage with students. Student teams will work on a project to create a frugal innovation for a critical challenge in the lives of the global poor.


Maps, Lies and Storytelling (Andrew Hill)

Maps have an incredible potential to do good and evil. Throughout history access to a map has been synonymous with power. In this course we will look at why that has been true, how it has changed through the digital revolution, and how we can harness mapping to gain power. The course will take a critical approach to maps and mapmaking, trying to pick apart all the ways they can be evil and be used to do evil. Through that critical approach, we will learn how to use maps effectively to communicate data, create knowledge, and tell stories. Students will also learn how maps are changing. We will try to find innovative new maps to create, both unassuming and controversial, and share those with a broader mapping community to create a public dialog. Students will learn the fundamentals of mapmaking, using tools from a pencil to Javascript, to create original maps from original data. We will create interactive maps with tools such as Leaflet and CartoDB to make maps from our imagination. We will also look at collecting or creating new geospatial data to make original maps never seen before.


Project Development Studio (Despina Papadopoulos)

This is an environment for students to work on their existing project ideas that may fall outside the topic areas of existing classes. It is basically like an independent study with more structure and the opportunity for peer learning. This particular studio is appropriate for projects in the area of interactive art, programing, physical computing and digital fabrication. There are required weekly meetings to share project development and obtain critique. Students must devise and then complete their own weekly assignments updating the class wiki regularly. They also must present to the class every few weeks. When topics of general interest emerge, a member of the class or the instructor takes class time to cover them in depth. The rest of the meeting time is spent in breakout sessions with students working individually or in groups of students working on related projects.