How It’s Made: NY World POPS Map

In October, The New York World began a collaboration with WNYC and the Brian Lehrer Show to crowdsource ratings of New York City’s several hundred privately-owned public spaces. To facilitate and catalog this process, The New York World’s Michael Keller developed an interactive map of these spaces, which served as both a guide and a repository for audience contributions. Below, he discusses the process and technologies used to create this piece. Complete coverage of the project can be found here.

1. Where did the idea come from?

The Occupy Wall Street in late September was probably what brought the term “privately owned public space” to most New Yorkers’ attention. These spaces — like Zuccotti Park — were created from land deals made between developers and the city: if developers ceded some land for public use such as a plaza, they could build taller skyscrapers or get other incentives potentially worth millions of dollars. For my part, though, the sudden notoriety of Zucotti Park reminded me of a file I had seen a few months ago on the NYC Datamine entitled “Privately Owned Public Spaces” — or POPS.

I mentioned this find to Yolanne Almanzar, the New York World’s public space reporter, who was looking into other POPS and found that a 2008 Manhattan Community Board 6 survey found that many such spaces in midtown were actually closed to the public or in poor condition.

After locating and converting the Datamine Access file to a spreadsheet, I found it contained the 391 addresses of all of the POPS in the city. From there we had a question to answer: were landlords living up to their end of the deal in providing useable public space? Our editors Alyssa Katz and Amanda Hickman pitched the idea to editors at WNYC that week as a collaborative crowdsourcing project. They liked it and we went from there.

2. Who worked on it?

Working with WNYC’s map wizard John Keefe, I used Google Fusion Tables to map the addresses from the Datamine and then used JavaScript to add features like the progress bar, address finder, and GPS locator.

Once the map was developed, Yolanne and I worked with the WNYC producers Jody Avirgan and Paige Cowett to figure out what specific questions we wanted New York World readers and WNYC listeners to answer. Yolanne also went on the Brian Lehrer show to discuss the project twice — at the beginning and end of the month-long crowdsourcing phase.

Once we started getting responses, Yolanne and I used twitter and email to follow up on interesting sites.

3. How long did it take?

The initial map took a few days to conceptualize and code but the whole project is still ongoing. A crowdsourcing project is a differs from a traditional story because you spend a great deal of time planning and reviewing information before you have enough information to know what the story is.

We stopped accepting new reader reports at the beginning of November and are now pulling building records to see exactly what these sites were supposed to offer to the public and what they got in return. For me, it’s a great way to work because you’re in touch with readers, and you’re both invested in the project and anxious to see what comes of it.

4. What processes or technologies were used?

We used Google Fusion Tables to map the POPS, but first I had to format and verify the data.

I used Microsoft Excel’s “=CONCATENATE()” function to add “New York, NY” to the addresses so that Fusion Tables could properly geocode them — convert them to latitude and longitude so that they can be mapped.

Oddly, Zuccotti Park at 1 Liberty Plaza didn’t geocode correctly and was placed in the middle of the South Tower at the WTC memorial. ProPublica’s Al Shaw pointed out that sometimes Google doesn’t work nicely with addresses that start with a single number. By changing the “1” to a “One” it geocoded properly. To be safe, I manually spelled out all of the single number addresses. (This glitch also comes up using normal Google maps. Type in “1 Liberty Plaza New York, NY” and see where it drops the pin.)

We spot checked a few other locations, and manually geocoded their position where necessary. Out of 391 entries, about a dozen were incorrectly placed by Fusion Tables. Reader feedback helped us find a few, too.

One of the big challenges with this dataset was getting the infowindows — the little info bubbles that appear when you click — to appear in a standardized way since the data weren’t consistent: some spaces contained a building name and an address whereas others just showed an address.

To get around this, I made two new columns in my Excel spreadsheet called displayName and displayAddress. displayName would contain the site name if it had one, or the address if it didn’t. displayAddress would have an address if a site had a name, otherwise I left it empty. Although Because Fusion Tables won’t allow JavaScript in infowindows, I used CSS to style the site name and address as elements of an unordered list with each line styled to

float:left;clear:both;”

While the default infowindow layout puts break tags at the end of each line, my list layout meant that if displayAddress were blank it wouldn’t leave an awkward empty line in the text.

I also collapsed additional details of each site into a new column and used that for the infowindow so it would be consistent for all of the entries.

To create the progress bar for the map, I used the Fusion Tables SQL API to query our fusion table and count the number of columns that have been marked as visited.

Through the Google Maps API documentation, I found that you can relatively easily add GPS functionality to a site with javascript. I added this feature to help people use the map when they were out reporting on these spaces. And similar to the address finder, I see it as a way the story can be personalized for people who want to find spaces near where they live or work.

For the address locator, I borrowed some javascript code from John Keefe at WNYC.

Because mobile was a big concern for the map, I made a second stylesheet that showed only the address finder and the GPS button when it was viewed on a mobile device. Though creating the second stylesheet wasn’t difficult, making sure it was showing up correctly across devices required a bit of a hack.

For most devices, I could detect the mobile device using:

media='only screen and (max-device-width:480px)'

For iPad or horizontal views on those devices I added:

media='only screen and (max-device-width:768px) and (max-device-width:1024px)'

To make sure those dogged infowindow didn’t show up super small on mobile devices, Keefe sent along this piece of code to go in theof my page to scale the viewport appropriately:

That did the trick.

5. What was learned from it?

We used Google Forms to get the reports from our readers and listeners, which was a good solution in that WNYC was familiar with it and it’s easily embeddable. But we spent a lot of time curating reader responses so it would have been much nicer to input our responses into a database whose results we could query and sort. The Google Form inputs our results into a spreadsheet that we had to then manually arrange and create lists from, which was a time-consuming process.

It would also have been nice to have a more robust wrapper for our fusion table so that we could easily pull in comments or media from our reader-submitted database and display them alongside the map. This would have meant designing a flexible layout to handle multiple content types as well as a backend database to categorize this information, but this was far beyond what our timeframe allowed.

A recurring lesson on this and other projects has been that designing user-interfaces is much like the scene in Alice in Wonderland where Alice is racing the Red Queen. Alice runs as fast as she can but she doesn’t move from where she stands. The Red Queen says: “Now, here, you see, it takes all the running you can do to keep in the same place.” When starting with messy data, it takes a lot of thinking just to get an interface that works without giving the reader a headache.