You are not logged in. LOG IN NOW >

The FCC's New Who's-Licensed-To-Do-What-Where

BY Nancy Scola | Tuesday, September 14 2010

The U.S. Federal Communications Commission is today peeling back the curtain a bit on who owns what communications licenses in the United States. Their new "FCC License View" features cross-bureau data on more than 3 million licenses for broadcast, mobile systems, public safety, wireless networks, and more. "Who's really doing what business where?" is a fundamental question underlaying the current state of media and communications in the U.S., and the FCC's squad of data-loving staffers see today's new tool as part of an ongoing effort to expose the American people to an information-driven view of the way everything from radio to television to broadband Internet actually functions today, in every nook and cranny of the United States.

Above, for example, is the data dashboard on the more than 10,000 FCC licenses held by Verizon Wireless, even where the company is tucked into the FCC's files as, say, "Alltell Cellular Associates of Arkansas."

In other news from the FCC's dance with data, their new media folks send along word that they've heared the complaints about and critiques of the APIs they rolled out on FCC.gov/Developer last week that came in "via Twitter, direct email and blog comments" and they've made some tweaks and fixes in response. With the warning that this is material that will be incomprehensible to the vast majority of us, those details on the API updates they've made are after the jump.

API Updates--

1. Bug fixes
- We heard about a bug in the FRN API that would cause a timeout when querying certain FRNs. Sorry about that, it should be fixed now.
- We head about a bug in the Speed Test API that would cause wrong Wireline Maximum Download and Maximum Upload values in some cases. Again, sorry about that, it should be fixed now.

2. API changes (Block Search)
- You gave us a suggestion that would make the return more compact and usable as we grow the service, so we decided to change the xml and JSON returns. Now the Block Search API returns data in the following structure to facilitate parsing and future expansion. This will break client applications of this method call if you implemented calls already to this API.

New Structure:
XML
<Response executionTime="0.047" status="OK">
<Block FIPS="560239782002133"/>
<County name="Lincoln" FIPS="56023"/>
<State name="Wyoming" code="WY" FIPS="56"/>
</Response>

JSON
{"@executionTime":"0.047","@status":"OK","Block":{"@FIPS":"560239782002133"},
"County":{"@name":"Lincoln","@FIPS":"56023"},"State":{"@name":"Wyoming",
"@code":"WY","@FIPS":"56"}}

JSONP
jsonp({"@executionTime":"0.047","@status":"OK","Block":{"@FIPS":"560239782002133"},
"County":{"@name":"Lincoln","@FIPS":"56023"},"State":{"@name":"Wyoming",
"@code":"WY","@FIPS":"56"}})

3. API Enhancements (Census and Speed Test)
We added the ability to select desired MIME return type from the URL using the parameter format, i.e. format=json. Possible values are xml, json and jsonp (in this last case, the parameter callback should also be used). If no format is specified XML is returned. This change doesn't break the API (old calls would still work, returning XML).