The US Census now has an API
census.gov
census.gov
Hmmm... looking at the example of this I can't help but think there has got to be a better way. This is more just a standard CSV (first row is header, all other rows are data). Using JSON for data formatted as such is kind of a waste of JSON. If you pass that example into a JSON decoder you get an extremely more difficult to use object. Am I missing something? or is this just typical "the government doesn't do tech properly" stuff?
EDIT: sorry, I try to be less negative but sometimes it is hard. I do applaud them for at least making the info available. I don't have a use for it but if some else does then dealing with a stupid format is better than not having data at all.
EDIT2: (to clarify) I was not saying the data should just be CSV... I'm saying it is and that defeats the purpose of using JSON. They should still use JSON but with their data formatted differently. Using their example, properly closed but truncated to just to first 2 records, the PHP function json_decode() turns it into this array:
array (
0 => array (
0 => 'P0010001',
1 => 'NAME',
2 => 'state',
),
1 => array (
0 => '710231',
1 => 'Alaska',
2 => '02',
),
2 => array (
0 => '4779736',
1 => 'Alabama',
2 => '01',
),
)
1) Whether it's user-friendly or not, it's still JSON, which makes JSON-P possible (they support JSON-P).
2) It probably mirrors the way they store their data (in tables, whether SQL or Access or Excel, doesn't really matter).
3) It's more compact than traditional JSON, which means less bandwidth, which means less cost. Keep in mind that this is essentially a not-for-profit API from a not-for-profit organization with the worst possible budgeting scenario. Yes, Gzip would basically eliminate this benefit, but they don't have gzip enabled and enabling it may be difficult or impossible under whatever constraints they operate under.
Also, it's entirely possible that this API has existed privately for a long, long time in a CSV format, and they simply made a minor enhancement to make it JSON and JSON-P compatible and open up the endpoints to the public.
- I daresay Census is sitting on some _large_ data sets. Fancy data structures are one thing when you want the population of California, another when you're trying to get California, by ethnicity and age group, by zip code.
- Data structure compactness will matter less to HN readers than to someone sitting on the other end of a phone dial-up in Oklahoma.
- I am but an egg but don't fancier data structures require particular decisions for implementation on particular tables? Census has a lot of tables -> a lot of decisions.
- God only knows how many different systems are involved holding all their data. The simpler the data structure, the less they have to get into those -- and / or the simpler a layer they between some mainframe and the API output.
Also, it may not seem very friendly to HN readers. But it is stupid simple, you can _see_ how it is organized, making it accessible to a wider audience. And it's so simple that it can be adopted by any agency publishing tables. Note that there are a lot of agencies with a lot of tables -- something like this has a chance of becoming standard among all of them.
A public agency has special accessibility concerns, and it's just a reality that government agencies have particular legacy technology issues. A lowest common denominator format helps get the data over those obstacles.
Maybe they can do better in places, and they're free to, there is no reason they can't support other formats too. But this will be available for whatever subset isn't served by those extensions.
{
P0010001 : [
'710231',
'4779736',
// ... etc.
],
NAME : [
'Alaska',
'Alabama',
// ... etc.
],
state: [
'02',
'01,
// ... etc.
],
// ... etc.
}1. CSV is not a single well-defined format. Some people use rfc4180, but not everybody does.
2. JSON is easier to parse than CSV for JavaScript clients, i.e., browsers. On the other hand, JSON is not a subset of JavaScript.
It's also a very agnostic format.
INSERT INTO table ('P0010001','NAME','state') VALUES (?,?,?)
Under US law, the federal government can't claim copyright on works produced via tax dollars (makes sense). Since the feds can't require us to provide attribution for all this helpful data, how do we as a community advocate for more open data like this?
Also, for further reading on the topic of .gov APIs, http://ben.balter.com/2012/06/02/publishing-government-data-... is a great start.
I went to the Computer History Museum a few months back, and when we were looking through the origins of the modern computer, a lot of it traces back to census needs: we needed to automate the counting of large quantities of uniformly formatted data, so we used punchcards to tally up the data.
Fast forward to 2012, and the census is now getting an API. Weird how that works.
If there's any problem with their downloadable data offerings, it's that they have so many of them that it can be difficult to figure out exactly which one has the data you're looking for.
this data is already available as a downloadable file. Check out ftp://ftp.census.gov/ It's CSV, and it's kinda ugly-looking, but it's available.
The 'full' data set is ...rather huge. The full data set for any particular report is rather huge.
The advantage of this API, I expect, is it allows people to make quick, machine readable queries for useful subsets of the data. If you want a JavaScript mashup that tells you the number of people who live on your block, use this. If you want to know the population of every block everywhere for data-crunching purposes, just download the CSV.
The bad news is that it appears to be SOAP-based.
It's great to get excited about the data format, but actual use-cases currently seem a little limited to me. Of course this will hopefully change as more and more datasets become available.
Looking forward to many more visualizations and analysis thanks to the API :)
I can imagine only 3 reasons for this: (1) they want to make you agree to the Terms & Conditions, (2) it gives a way to choke off a DDOS attack that makes repeated complex queries, or (3) the census bureau wants to track how you are using its service.
The key is indeed easy to get, but I observe that Google would have exactly the same concerns as 1,2,&3 above, yet they somehow manage to stay in business without making their users sign up to do a web search.
The federal government always makes things a little more complicated.
However, both require that their users signup for an API key to do automated querying. (In fact, Google charges for its Web Search API now.) It's pretty standard for any API to want to be able to identify and potentially meter usage.
Besides, this is the 2010 American Community Survey. Pretty sure it's moved all the markets it's going to move by now.