Federal Communications Commission
Home » Blog

Update for /Developer

September 14th, 2010 by Michael Byrne - Geographic Information Officer

Last week we announced the release of four API’s and the site fcc.gov/developer at the Gov 2.0 conference.  We heard great feedback via twitter, direct email and blog comments.  We have taken some of these ideas and implemented the changes right away.  We want to make sure that these services are useful to the developer community and that you know we are listening to your concerns here.  The changes we have made are listed below, but please keep the comments coming.  Your help is required to make these services better.

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:
<Response 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).  

9 Responses to “Update for /Developer”

  1. mByrne says:

    Thanks for these heads up. We are taking a look at your suggestions; in particular the #3 is breaking one. We hope to resolve this today. Sorry about that.

  2. Steven Romalewski says:

    Thanks for the update, Mike.

    I noticed that you're now "versioning" the API, and you're up to version 1.01 (or perhaps one after 1.01). Perhaps you could add the version number to the URL and continue to return data in the old ways for each version. That way if the format changes again, people using the old version(s) wouldn't have to change unless they wanted to (for example, accessing http://data.fcc.gov/api/v100/block/find?latitude=40.0&longitude=-85&format=json would return the JSON identifiers with the @ symbols). Just a thought.

    Either way, it would definitely help if you informed the user community of changes. I signed up on the "Join FCC Developers" list at http://reboot.fcc.gov/developer, but haven't received any emails.

    At the moment I'm using the API for a mobile app I'm testing for personal use, focused on New York City architecture (which I also may expand to cover other cities). It enables me to match a smartphone's lat/lon with the corresponding (non-Census) neighborhood boundary without having to do a point-in-polygon join. With the API I can just match the block FIPS with a list of blocks per neighborhood, rather than having to have my own server-based GIS.

    Professionally, I direct a mapping project at the City University of New York (www.urbanresearch.org), and we may use the API for various online mapping applications we're developing, including one to display changing population patterns based on the latest Census data. It will follow on the www.CensusHardToCountMaps.org project we developed last year.

    Thanks for a great set of APIs!

  3. Richard says:

    The License View API call getLicenses fails to behave according to the documentation in some instances. getLicenses seems to fail with an error message of Internal Server Error on many (most?) inputs which follow the documentation.

    The documentation lists searchValue as the only required parameter, and it specifies that the searchValue may be a name, FRN, or callsign. So the following URL is valid according to the documentation: http://data.fcc.gov/api/license-view/basicSearch/getLicenses?searchValue=0020232716

    I invite the reader to try that URL (which specifies a valid FRN) using an interactive web browser, a command line tool like curl, or an API like Perl's LWP::Simple. I find that it fails in all of these cases with Internal Server Error.

    Furthermore, all attempts I have made to use getLicenses while specifying a format of xml have also failed with a response of Internal Server Error. In each case, I have followed the API documentation without success.

  4. Guest says:

    Actually, #3 is breaking -- you used to be able to get json using http-accept headers, but now you get XML with http-accept for json.

  5. Guest says:

    We still do not see RSS feeds for equipment authorization (OET). Please indicate where these are on your agenda. Very pleased with the RSS feed for Experimental Radio Service.

  6. Guest says:

    Thanks for this update. Really great APIs.

    I noticed that the JSON format for the Census Block Conversion API includes "@" symbols in the identifiers. I think I'm getting "unexpected identifier" errors in my application as a result. Is anyone else experiencing this? Any thoughts on a workaround for parsing the JSON data? Thanks!

  7. Robert R. Henry says:

    The "Full Data Set" downloaded from reboot.fcc.gov/developer/license-view-api contains a 562Mbyte .zip file that expands to a 3.4Gbyte file named fcc_lic_vw.csv

    Unfortunately, what's in this .csv file doesn't seem to conform to the CSV standard in RFC 4180 (http://www.rfc-editor.org/rfc/rfc4180.txt). In particular, some of the fields' values naturally contain instances of double quotes, as for example when (incorrectly) used as a possessive, or when used to mean 'Inches'. These double quotes are not stuttered (eg, turned into two adjacent double quotes) per the CSV standard. There are also fields' values that contain new lines, but that's OK per the standard.

    Can you please fiddle with your data base dumping tools and have them regenerate CSV that more closely follows the standard?

  8. Steven Romalewski says:

    The Census Block API seems to have changed today. Is this by design, or did something go wrong? The identifiers for FIPS codes in the JSON data that's being returned no longer have the "@" sign in front of them (like they do in the examples provided on the website). This of course has broken code, so I'm wondering if it will be changed permanently like this, or if it will go back to the earlier approach. Thanks.

  9. mByrne says:

    Sorry about the change, without the notification. we did indeed change the response. we are permanently changing it this way, and should have notified everyone of the change. It was entirely my fault.

    We love that you are using the APIs, please let us know how you are using them.


Leave a Reply