9 Responses to “Update for /Developer”

1. mByrne says:

   September 20 2010 at 9:45 AM

   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:

   October 12 2010 at 9:46 PM

   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:

   October 09 2010 at 9:32 PM

   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:

   September 15 2010 at 12:01 PM

   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:

   September 27 2010 at 2:17 PM

   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:

   September 15 2010 at 9:51 AM

   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:

   September 23 2010 at 1:08 PM

   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:

   October 05 2010 at 8:40 PM

   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:

   October 11 2010 at 9:04 AM

   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.
   
   mike