PUMS areas? We got ’em.

After some great brainstorming and the helpful feedback of folks at CityCamp, I’m happy to report that the core concept of MCIC‘s first web service is now emerging.

There are tons of APIs that will return the zip code, neighborhood, city, county, or state of a lat/long or address, but none that also offer police beats, police areas, wards, community areas, census tracts, census block group, and PUMS areas as well. These geographies are at the core of many MCIC data sets, and such a service would not only be useful in and of itself but at the heart of the still-in-the-works data service.

What has excited me the most about working with MCIC is the care and feeding provided to the data they work with. After they’re done, it’s not uncommon to see a 7-8% improvement in geocoding success. These are the folks who meticulously clean the boundaries of every arcane geography, ensuring that the each side of a street is in its proper place and overlaps/gaps are removed. And they’re excited to see what you will do with it.

Your thoughts and comments on the details are welcome:

-What formats to you want to see?
-What additional information should we provide?
-How can we design the API and write documentation to make your lives as developers easier?
-What kinds of data should we prioritize next? (vote here)

We’ll be testing this API soon; if you’re interested in early access please let us know in the comments.


more on PUMS areas

4 thoughts on “PUMS areas? We got ’em.

  1. Format: presumably GeoJSON is the most useful/flexible. Maybe also KML?

    Additional information: if the input is anything other than a lat/lon pair, then you need to give feedback on how the input string was geocoded, hopefully how accurate the geocoding is considered, and possibly a list of alternative possible answers?

  2. Thanks Joe!

    The idea is to start with requiring lat/lon as the input but, if there’s demand, I don’t see a reason why the service couldn’t also accept an address and return lat/long + geographies. Good idea on the accuracy; would returning an annotation that “point is near a boundary line for __ geo” + including in the metadata for each boundary set the geocoding success rate be enough?

    On this thread, we’re also thinking about returning overlapping boundaries for a polygon input, but there’s significantly more development involved in that. In the beginning, it will be just points.

  3. This might be apropos: http://wiki.open311.org/GeoWeb_DNS — the idea is a service that returns areas given a point. I’ve just imported some NYC data into it (at http://wiki.open311.org/GeoWeb_DNS), but it’s a matter of rounding up the appropriate data.

    This doesn’t take the place of exports, but it’s more the kind of thing that can be done with exports, and making the results easier for people to use.

    The site itself is young, not sure where exactly it’ll go, but it’s open source and I believe fairly easy to work with (an appropriately small codebase).

Leave a Reply

Your email address will not be published.