CategoryWeb Applications

Inclusionary zoning calculator will tell you how many units a developer can afford to make “affordable”

An “inclusionary zoning” calculator can help you determine how much affordable housing your town should require that developers build in their new construction residential buildings.

I learned about Grounded Solutions Network’s Inclusionary Housing Calculator at the second-ever YIMBYtown conference in Oakland, California, two weeks ago.

YIMBY (yes in my back yard) is a movement to reduce barriers to building more housing in order to be able to house everyone at a level they can afford. It’s a movement for other things, and it means a lot of different things to a lot of different people but the end result is that more housing needs to be built.

An interested person inputs a lot of values relevant to their local housing market into the IHC and it will calculate the cost of construction per unit and the rental income from those units, and then will figure the profit margin for the developer. What makes this “inclusionary” is that one also needs to enter the desired portion of units that are set aside as “affordable” (to people making a certain income) and subsidized by the developer’s rental income.

I put the IHC through a real world exercise by inputting as much data as I knew about a rejected proposal in Pilsen.

The first proposal from Property Markets Group had 500 units, and 16 percent of them were set aside (news on this and their subsequent proposals). Chicago’s Affordable Requirements Ordinance, or ARO, requires that 10 percent of the units are affordable, and that 25 percent of those 10 percent must be built on site. The other 75 percent can be built on site, or the developer can pay an in-lieu fee per unit.

Needless to say, 16 percent on-site is much, much higher than 25 percent of 10 percent. A neighborhood organization, the Pilsen Land Use Committee, however, requires 21 percent in the area, and the city council member, Danny Solis, 25th Ward, adheres to.

PMG said they couldn’t go that high, and that’s what I wanted to test.

According to this Inclusionary Housing Calculator, could the developer make enough profit (considered as 10 percent) if the building had 21 percent of units as affordable?

In this exercise, the answer was “no, PMG could not make a profit if they had to set aside 21 percent of the units as affordable.”

But the calculator showed that they could earn a 12 percent profit if 16 percent of the units were affordable. 

Some of the inputs are actual, like the sale price of the land (found in the Illinois Department of Revenue’s transactions database), but I had to make up some inputs, including the apartments’ bedroom mix, and the future rental prices of those apartments.

Further reading

  • It’s tough for people to move into one of these set-aside apartments in Chicago (DNAinfo Chicago, July 28, 2017)
  • Inclusionary zoning cannot create enough affordable units (City Observatory, February 11, 2016)
  • Other housing cost calculators like this one (City Observatory, July 26, 2016)

The U.S. DOT should collaborate with existing “National Transit Maps” makers

The U.S. DOT demonstrated one idea for how a National Transit Map might look and work at a conference in February.

The Washington Post reported this month that the United States Department of Transportation is going to develop a “National Transit Map” because, frankly, one doesn’t exist. The U.S. DOT said such a map could reveal “transit deserts” (the screen capture above shows one example from Salt Lake City, discussed below).

Secretary Anthony Foxx wrote in an open letter to say that the department and the nation’s transit agencies “have yet to recognize the full potential” of a data standard called the General Transit Feed Specification that Google promoted in order to integrate transit routing on its maps. Foxx described two problems that arose out of not using “GTFS”.

  1. Transit vehicles have significantly greater capacity than passenger cars, but are often considered just vehicles because we are unable to show where and when the transit vehicles are scheduled to operate. The realistic treatment of transit for planning, performance measures, and resiliency requires real data on transit system operations.
  2. One of the most important social values of transit is that it makes transportation available to people who do not have access to private automobiles, and provides transportation options for those who do. Yet, we cannot describe this value at a national level and in many regions because we do not have a national map of fixed transit routes.

“The solution is straightforward”, Foxx continued, “[is] a national repository of voluntarily provided, public domain GTFS feed data that is compiled into a common format with data from fixed route systems.”

The letter went on to explain exactly how the DOT would compile the GTFS files, and said the first “collection day” will be March 31, this week. As of this writing, the website to which transit agencies must submit their GTFS files is unavailable.

What Foxx is asking for has already been done to some degree. Two national transit maps and one data warehouse already exist and the DOT should engage those producers, and others who would use the map, to determine the best way to build a useful but inexpensive map and database. Each of the two existing maps and databases was created by volunteers and are already-funded projects so it would make sense to maximize the use of existing projects and data.

“Transitland” is a project to host transit maps and timetables for transit systems around the world. It was created by Mapzen, a company funded by Samsung to build open source mapping and geodata tools. Transitland is also built upon GTFS data from agencies all over the world. Its data APIs and public map can help answer the question: How many transit operators serve Bay Area residents, and what areas does each service?

For the United States, Transitland hosts and queries data from transit agencies in 31 states and the District of Columbia. In Washington, D.C., Transitland is aware of four transit agencies. It’s a great tool in that respect: Not all of the four transit agencies are headquartered in D.C. or primarily serve that city. The app is capable of understanding spatial overlaps between municipal and regional geographies and transit agencies.

Transitland has a “GUI” to show you how much transit data it has around the world.

“Transit Explorer” is an interactive map of all rail transit and bus rapid transit lines in the United States, Mexico, and Canada. Yonah Freemark, author of The Transport Politic, created the map using data culled from OpenStreetMap, the National Transit Atlas Database (administered by the DOT and which shows fixed-guideway transit), and his own research. I wrote the custom JavaScript code for the Leaflet-powered map.

No other agency or project has collected this much data about fixed-guideway transit lines in any of the three countries, since the map includes detailed information about line lengths, ridership, and other characteristics that are not included in GTFS data. Transit Explorer, though, does not include local bus service or service frequencies, which the DOT’s map may if it incorporates the full breadth of GTFS data.

Transit Explorer also goes a step further by providing data about under construction and proposed fixed-guideway transit lines, which is information that is very relevant to understanding future neighborhood accessibility to transit, but which is not available through GTFS sources.

Finally, “GTFS Data Exchange” is a website that has been storing snapshots of GTFS feeds from agencies around the world for almost a decade, or about as long as GTFS has been used in Google Maps. The snapshots allow for service comparisons of a single agency across time. For example, there are over 100 versions of the GTFS data for the Chicago Transit Authority, stretching back to November 2009; new versions are added – by “cta-archiver” – twice a month.

Josh Cohen, writing in Next City, highlighted the significance of Google’s invention of GTFS, saying, “Prior to the adoption of GTFS, creating such a map would’ve been unwieldy and likely produced an out-of-date product by the time it was completed.” The DOT’s own National Transit Atlas Database includes only fixed-guideway (a.k.a. trains) routes, and hasn’t been updated since 2004.

Not all GTFS feeds are created equal, though. Some transit agencies don’t include all of the data, some of which is optional for Google Map’s purpose, that would make the National Transit Map useful for the spatial analysis the DOT intends. Many agencies don’t include the “route shapes”, or the geographic lines between train stations and bus stops. Researchers are able to see where the vehicles stop, but not which streets or routes they take. Foxx’s letter doesn’t acknowledge this. It does, however, mention that transit agencies can use some federal funds to create the GTFS data.

David Levinson, professor at the University of Minnesota, believes the map will bias coverage (geographic reach of transit service) over frequency (how many buses are run each day that someone could ride).

The U.S. DOT’s chief data officer, Dan Morgan, whom I met at Transportation Camp 2015 in Washington, D.C., presented at the FedGIS Conference this year one idea to demonstrate coverage and frequency in Salt Lake City, using the GTFS data from the Utah Transit Authority.

Levinson also tweeted that it will be difficult for a national map to show service because of the struggles individual transit providers have symbolizing their own service patterns.

Foxx’s letter doesn’t describe how planners will be able to download the data in the collection, but whichever app they build or modify will cost money. Before going much further, and before spending any significant funds, Foxx should consult potential users and researchers to avoid duplicating existing projects that may ultimately be superior resources.

Foxx can also take advantage of “18F” a new agency within the General Services Administration to overcome government’s reputation for creating costly and difficult to use apps. The GSA procures all kinds of things the federal government needs, and 18F may be able to help the DOT create the National Transit Map (and database) in a modern, tech and user-friendly way – or write a good RFP for someone else to make it.

Look for the National Transit Map this summer.

How to make a map of places of worship in Cook County using OpenStreetMap data

The screenshot shows the configuration you need to find and download places of worship in Cook County, Illinois, using the Overpass Turbo website.

If you’re looking to make a map of churches, mosques, synagogues and other places of worship, you’ll need data. The Yellow Pages won’t help because you can’t download that. And Google Maps doesn’t let you have a slice of their database, either. That’s where OpenStreetMap comes in. It’s a virtual planet that anyone can edit and anyone can have for free.

First we need to figure out what tag people use to identify these places. Sometimes on OSM there are multiple tags that identify the same kind of place. You should prefer the one that’s either more accurate (and mentioned as such in the wiki) or widespread.

The OSM tag info website says that editors have added over 1.2 million places of worship to the planet using “amenity=place_of_worship”.

Now that we know which tag to look for, we need an app that will help us get those places, but only within our desired boundary. Open up Overpass Turbo, which is a website that helps construct calls to the Overpass API, which is one way to find and download data from OSM.

In the default Overpass Turbo query, there’s probably a tag in brackets that says “[amenity=drinking_fountain]”. Change that to say “[amenity=place_of_worship]” (without the quotes). Now change the viewport of the map to show only the area in which you want Overpass Turbo to look for these places of worship. In the query this argument is listed as “({{bbox}})”.

The map has a search bar to find boundaries (cities, counties, principalities, neighborhoods, etc.) so type in “Cook County” and press Enter. The Cook County in Illinois, United States of America, will probably appear first. Select that one and the map will zoom to show the whole county in the viewport.

Now that we’ve set the tag to [amenity=place_of_worship] and moved the map to show Cook County we can click “Run”. In a few seconds you’ll see a circle over each place of worship.

It’s now simple to download: Click on the “Export” button and click “KML” to be able to load the data into Google Earth, “GeoJSON” to load it into a GIS app like QGIS, or “save GeoJSON to gist” to create an instant map within GitHub.

Use Turf to perform GIS functions in a web browser

Turf's merge function joins invisible buffers around each Divvy station into a single, super buffer.

Turf’s merge function joins invisible buffers around each Divvy station into a single, super buffer –all client-side, in your web browser.

I’m leading the development of a website for Slow Roll Chicago that shows the distribution of bike lane infrastructure in Chicago relative to key and specific demographics to demonstrate if the investment has been equitable.

We’re using GitHub to store code, publish meeting notes, and host discussions with the issues tracker. Communication is done almost entirely in GitHub issues. I chose GitHub over Slack and Google Groups because:

  1. All of our research and code should be public and open source so it’s clear how we made our assumptions and came to our conclusions (“show your work”).
  2. Using git, GitHub, and version control is a desirable skill and more people should learn it; this project will help people apply that skill.
  3. There are no emails involved. I deplore using email for group communication.*

The website focuses on using empirical research, maps, geographic analysis to tell the story of bike lane distribution and requires processing this data using GIS functions. Normally the data would be transformed in a desktop GIS software like QGIS and then converted to a format that can be used in Leaflet, an open source web mapping library.

Relying on desktop software, though, slows down development of new ways to slice and dice geographic data, which, in our map, includes bike lanes, wards, Census tracts, Divvy stations, and grocery stores (so far). One would have to generate a new dataset if our goals or needs changed .

I’ve built maps for images and the web that way enough in the past and I wanted to move away from that method for this project and we’re using Turf.js to replicate many GIS functions – but in the browser.

Yep, Turf makes it possible to merge, buffer, contain, calculate distance, transform, dissolve, and perform dozens of other functions all within the browser, “on the fly”, without any software.

After dilly-dallying in Turf for several weeks, our group started making progress this month. We have now pushed to our in-progress website a map with three features made possible by Turf:

  1. Buffer and dissolving buffers to show the Divvy station walk shed, the distance a reasonable person would walk from their home or office to check out a Divvy station. A buffer of 0.25 miles (two Chicago blocks) is created around each of the 300 Divvy stations, hidden from display, and then merged (dissolved in traditional GIS parlance) into a single buffer. The single buffer –called a “super buffer” in our source code – is used for another feature. Currently the projection is messed up and you see ellipsoid shapes instead of circles.
  2. Counting grocery stores in the Divvy station walk shed. We use the “feature collection” function to convert the super buffer into an object that the “within” function can use to compare to a GeoJSON object of grocery stores. This process is similar to the “select by location” function in GIS software. Right now this number is printed only to the console as we look for the best way to display stats like this to the user. A future version of the map could allow the user to change the 0.25 miles distance to an arbitrary distance they prefer.
  3. Find the nearest Divvy station from any place on the map. Using Turf’s “nearest” function and the Context Menu plugin for Leaflet, the user can right-click anywhere on the map and choose “Find nearby Divvy stations”. The “nearest” function compares the place where the user clicked against the GeoJSON object of Divvy stations to select the nearest one. The problem of locating 2+ nearby Divvy stations remains. The original issue asked to find the number of Divvy stations near the point; we’ll likely accomplish this by drawing an invisible, temporary buffer around the point and then using “within” to count the number of stations inside that buffer and then destroy the buffer.
Right-click the map and select "Find nearby Divvy stations" and Turf will locate the nearest Divvy station.

Right-click the map and select “Find nearby Divvy stations” and Turf will locate the nearest Divvy station.

* I send one email to new people who join us at Open Gov Hack Night on Tuesdays at the Mart to send them a link to our GitHub repository, and to invite them to a Dropbox folder to share large files for those who don’t learn to use git for file management.

Meet Chicago’s newest street view fleet: bikes

Bicycle holds an iPhone to take street view-style images

This position gives the smartphone an unimpeded view of the street but prevents the user from manipulating it.

I first used the Mapillary app on iPhone last fall, in August, and I uploaded one photo, of my arm, which I can’t delete from the website. I uploaded a couple more photos from a street in Roscoe Village in November.

This week, though, I uploaded 500 photos from a three mile journey on California and Milwaukee Avenues in Chicago – streets that no one else had photographed for the Mapillary street view service.

Mapillary is an open source (sort of) street view service, originally developed in Sweden, which allows the public to contribute photos taken with their smartphone app.

What’s “sort of” about Mapillary being open source is that it appears that the company owns the photos once you upload them. People are free to use the photos to edit OpenStreetMap, or publish elsewhere – for personal use only – with attribution that adheres to Creative Commons 4.0. People who want to use the photos in a commercial application must subscribe to a pay service.

Mounting an iPhone to a bicycle

I took the jump from contributing nothing to uploading a whole lot because I bought an iPhone mount for my bicycle. After months of research – okay, chalk it up to my being lazy and it being really cold outside – I settled on the DgRock Universal Bicycle Mount from Amazon for $9. I was perplexed that there was a gap in choices between this decent $9 product and the next group, hovering around $30-40.

After three days of use, I’m satisfied, despite limitations that are present in all mounts I surveyed. The DgRock mount is solid, barely moves even as the bike bounces along Chicago’s pothole-ridden streets, and securely holds the iPhone with a strong, spring-loaded grip. It’s universal in two ways: it holds nearly any smartphone (it probably can’t hold one with a screen 5″ or larger) and it attaches to most bicycle handlebars.

The first day I used the DgRock mount Mapillary complained with a red icon that it couldn’t get a proper fix on its location and therefore it wouldn’t start photographing. Fine, I was in downtown Chicago where connecting to GPS satellites can be hard. I figured the wifi positioning system that all smartphones and tablets use would suffice.

There are problems with the mount, but I think these apply to all bicycle smartphone mounts: When the phone is in position to take photos, meaning its horizontal and level to the ground, you can’t see the screen. That’s because the screen, mounted on the handlebars, is much lower than your eyes and faces vertically, instead of angled towards your face. The only way around this, I believe, is to either get an upright bicycle (like my WorkCycles Fr8) or an adjustable lens (I can’t find any).

Smartphone mount holding an iPhone on a bicycle

This position allows the user to manipulate the smartphone but you cannot take street view-style images.

The possible position angles of the smartphone when held by the mount was my main concern as I was shopping on Amazon: The mount need to have the flexibility to position the smartphone so its rear camera could be level with the ground. Smartphone mounts, though, are made to put the device in a position to be used and viewed frequently by the bicycle rider – it was unclear if many of the other smartphone mounts could accommodate the street view angles requirement.

The DgRock has no issue moving the iPhone into the right position, as you can see in the photos from my journey (or scroll to the end). Its issue, though, is that you have to put the smartphone in “backwards” so that the claw covers up part of the screen. I call it an issue but it doesn’t disturb the mount’s primary purpose when using Mapillary – the phone still has a clear view of the street.

Even with an upright bike like mine, though, it’s difficult to see the screen. I believe that Mapillary can actually design its app to help overcome this physical limitation.

Using Mapillary

The Mapillary app has improved greatly since the first version. It allows you to delete bad or undesired photos before uploading, and it has a simpler interface to go from opening the app to making your own street view. There are a couple changes I think would improve the user experience and lead to more contributions.

I would like to be able to turn off the screen while using Mapillary to save battery life. I think that the screen could fade to black and a small white dot or halo appears frequently to remind you that it’s working. I’d also like it to chime when iOS throws the “low storage” warning. Otherwise I may be riding along, thinking Mapillary is capturing the street, when iOS had actually run out of storage 10 minutes ago.

This is why we need more people editing OpenStreetMap

Unmapped homes in the Irving Park community area

These homes were built after the City of Chicago’s building footprints dataset was created (2010?). Ian Dees imported the dataset in 2012. Many of the buildings that you can now see on Bing Maps have not been present on Bing’s satellite imagery since at least 2012.

1. OpenStreetMap is the world’s most complete free map, to which anyone can contribute their “ground truth” data (the location of wells and convenience stores, road names, and whether Lula Café at 2537 N Kedzie Boulevard in Logan Square has outdoor seating).

2. OpenStreetMap is used by thousands of non-profit and non-governmental organizations, corporations, apps, and people daily to locate themselves, locate others, get directions, and find places.

3. Nearly every map is out of date the moment it is published, including online, “current” maps like Google Maps, Bing Maps, their competitors, and OpenStreetMap.

4. Bing Maps provides its satellite imagery to OpenStreetMap editors – you and me – so that we can trace (copy) things on the planet to be things on the map. Google Maps doesn’t allow tracing (copying).

5. Bing updated its satellite imagery for Chicago (and probably a lot of other places) within the last six weeks…and there are hundreds of objects that aren’t yet mapped in OpenStreetMap. In Chicago most of these buildings are newly constructed houses.

Those hundreds of houses now need to be added to OpenStreetMap, with addresses, to complete the buildings collection in Chicago, and to expand the gazetteer (an address book) of places in Chicago.

I’m glad you want to help me do it! Here are two helpful things you can do:

  1. Start tracing the buildings yourself (here’s how new mappers can get started), or
  2. Leave notes at buildings which aren’t yet mapped so that map editors like myself know where to look to trace buildings.

Update: There’s a bonus third thing you can do, and that’s come to the next MaptimeCHI event on Thursday, February 26th, at the Chicago Community Trust (225 N Michigan, 22nd floor). RSVP for Anatomy of a Web Map. The Trust will also provide food and beverages. I’ll be there to teach new mappers and assist generally.

Adding notes is extremely helpful

You can contribute without editing by adding notes describing new things, or identifying problems with existing things. Click the “Add a note” button on OpenStreetMap.org.

Mapping a campground that doesn’t exist: a before and after view of OpenStreetMap

Pretty soon there will be a campground shown in OpenStreetMap, and added to its geocoding database, when I’m done adding it.

I temporarily become addicted to mapping places on OpenStreetMap. In my quest to find and map all campgrounds in Chicagoland – in order to publish them in the Chicago Bike Guide – I came across a campground that was constructed this year and opened in August 2013. This is the story of figuring out how to map the Big Rock Forest Preserve campground in Big Rock, Illinois.

I found on the Kane County Forest Preserve District website that the organization operated a campground at Big Rock Forest Preserve. I couldn’t locate the campground in Google Maps by the address the website gave. I couldn’t find it in OpenStreetMap, either, because no one had mapped it, but it’s there now.

When I searched for the park by name, Google Maps zoomed me to the main entrance of the park, but I still couldn’t see a campground. I downloaded the forest preserve district’s park map (always as a PDF) and followed the roads in Google Maps until I came across the campgrounds approximate position. There was a new road here so I followed that to find a campground under construction.

Google Maps shows the campground and artificial lake under construction.

Google’s imagery of the under-construction campground was taken on May 23, 2013 (get the date from Google Earth). This was great because now I could open JOSM, a powerful desktop OpenStreetMap editor, and locate the site, load Bing’s imagery and start tracing the campground to upload to OSM.

Bing’s imagery in JOSM, the OpenStreetMap-editing app, doesn’t show the campground.

The problem was that Bing’s imagery – and this is typical – was outdated. I could easily compare the imagery side-by-side and based on other landscape features (like the forest edge) guess where to trace the campground, but OSM needs better quality data. Enter MapWarper.

Read the rest of this post on Web Map Academy.

CDOT misses the lesson on open data transparency

Publishing the wrong measurement as a PDF isn’t transparency.

The Chicago Department of Transportation released the first progress report to its Chicago Forward Action Agenda in October, two and a half years after the plan – the first of its kind – was published. I’ve spent an inordinate amount of time reading it and putting off a review. Why? It’s been a difficult to compare the original and update documents. The update is extremely light on specifics and details for the many goals in the Action Agenda, which should have organizational (like record keeping and efficiency improvements) and public impacts (like figuring out which intersections have the most crashes). I’ll publish my in-depth review this week.

Aside from missing specifics and details, the update presents information differently and is missing status updates for the three to five “performance measures” in each chapter. It was difficult to understand CDOT’s reporter progress without holding the original and update side-by-side. I think listing the original action item, the progress symbol, and then a status update would have been an easier way to read the document.

The update measures some action items differently than originally called for, and the way pothole repair was presented, a problem for people bicycling and driving, caught my analytical eye.

CDOT states a pothole-filling performance measure of the percentage, which it desires to be increased, “patched or fixed within 72 hours of being reported” but the average, according to the website Chicago Potholes, which tracks the city’s open data, is 101 days*. The update doesn’t necessarily explain why, writing “the 72 hour goal for filling potholes is not always feasible due to asphalt plant schedules” and nothing related to the performance measure.

As originally written, the only way to note the performance would be to list the percentage of potholes filled within the goal time, at the beginning and in the update. This performance measure has a complementary action item – an online dashboard – which could have provided the answer, but didn’t.

CDOT published that dashboard this summer as a series of six PDF files that update daily and you can hardly call it useful.

Publishing PDF files in the day and age of open government data – popular with President Obama and Mayor Rahm Emanuel – is unacceptable. Even if they are accessible – meaning you can copy/paste the text – they are poor outlets for data given the nationally-renowned civic innovation changes that Emanuel has succeeded in establishing.

There’s another problem: the dashboard file for pothole tracking doesn’t track the time it takes to close a pothole request, nor the number of pothole requests that are patched within 72 hours. It simply tells the number completed yesterday, the year to date, and the number of unpatched requests. (I’ve posted the pothole-tracking file to Scribd because the dashboard [PDF] doesn’t work in Safari; I also notified city staff to this problem which they acknowledged over three weeks ago.)

The “Chicago Works For You” website reports a different metric, that of the number of requests made each day, distributed by ward.

I discussed the proposed dashboard with former commissioner Gabe Klein over two years ago. He said he wanted to create a dashboard of projects “we’re working on that’s updated once a week.” Given Klein’s high professional accessibility to myself, John Greenfield and other reporters, I’ll give him and CDOT a pass for not doing this. But Klein also said, “I’m really big on transparency and good communication. When I left [Washington,] D.C. our [Freedom of Information Act Requests] were dramatically lowered.”

I’ll consider the pothole performance measure and action item “in need of major progress.”

* For stats geeks, the median is 86 and standard deviation is ±84.

Get out of Googleville: my presentation on web mapping

Alternate headlines: Google Maps versus OpenStreetMap; why OpenStreetMap is better than Google Maps

I presented to the Chicago GIS Network Meetup group on February 5,2013, about alternatives to Google when it comes to mapping on the web. I created the presentation and outline a couple hours before giving it and came up with this slideshow with three frames.

Googleville 1 of 3

Google Maps and its data is a one-way street (or many one-way streets). Google will take data but won’t give it back.

Googleville 2 of 3

Google Maps has all of these features, but they’re easier to manipulate when you use an alternative. Alternatives like: MapBox, TileMill, OpenLayers, OpenStreetMap (made easy with JOSM), GeoCommons – I’m sure there are plenty more.

Googleville 3 of 3

OpenStreetMap is the Wikipedia of online mapping and geographic data. Considering switching to OSM.

Mapping guns in your town: is that okay?

This screenshot shows the pistol permit holders in Westchester County, New York. The highest density of permit holders appears to be at the border with Bronx County, also known as the northern edge of New York City. 

An ABC News story I read through the Yahoo! News website tells about The Journal News, covering Westchester (Yonkers, New Rochelle) and Rockland (New City, Pomona) counties in New York, posting the names and addresses, on a map, of gun permit owners. The map contains:

…the addresses of all pistol permit holders in Westchester and Rockland counties. Each dot represents an individual permit holder licensed to own a handgun — a pistol or revolver. The data does not include owners of long guns — rifles or shotguns — which can be purchased without a permit. Being included in this map does not mean the individual at a specific location owns a weapon, just that they are licensed to do so. [Notice that some dots are outside the county.]

This article is interesting to me for two reasons:

1. The article has hyperlinks to the (alleged?) Facebook profiles of two people who commented on The Journal News’s website. I predict this will only become more common. I don’t have a Facebook profile to link to.

2. The rationale to make a map seems reasonable: so people know where there are potentially guns in their neighborhood. It seems reasonable that people want to know where there are potential sources of danger and harm near them.

The names and addresses were obtained through “routine” (their words, not mine, but it is pretty routine and normal) Freedom of Information Act (FOIA) requests. The quantity and types of guns are not considered to be public record, although this may not be true, according to the ABC News article.

© 2017 Steven Can Plan

Theme by Anders NorénUp ↑