why they don't use shapefiles for datasets with lots of content is the 255 field limit in dbf files that are part of shapefiles.
And also a factor is the gross limit on size for shapefiles. File geodatabases can be much bigger. But that doesn't affect most vector data sets that Census publishes because those tend to be small and fit within the limits of shapefiles. 2GB of vector data is bigger than most desktop applications can handle so Census tends to distribute vector data sets in much smaller pieces. Shapefiles are fine for those. QGIS does indeed use GDAL which incorporates ESRI's API for file geodatabases and which indeed does not include support for rasters in file geodatabases. That is not a factor for census block groups since those are vector data and not rasters. But by way of discussion I can understand why there might have been some confusion over whether the API supports rasters or not. When ESRI's API for the file geodabase was announced in 2010 it was noted the API was provided with limitations and that the "initial release" would not support rasters. More recently (for example in March, 2016) presentations on the API are almost word-for-word identical to the initial discussion of limitations but do not mention "initial release" and simply say the API "does not" support rasters. The exact language is: --------- File Geodatabase API / Features Not Supported While the File Geodatabase API supports reading the schema and data of complex geodatabase types, the API does not honor geodatabase behavior on inserts, deletes or updates to the following dataset types: - Annotation and Dimension feature classes - Relationship Classes - Networks (GN and ND) - Topologies - Terrains - Representations - Parcel Fabrics File Geodatabase API / Features Not Supported - Raster Datasets, Raster Catalogs, Mosaic Datasets and Raster Attributes are not supported. - Spatial queries are limited to the envelope-intersects operator. - Attachments are not be [sic] supported - Joins are not supported An earlier description, still applicable, includes this: "The API will not prevent users from attempting to edit objects with complex behavior, the onus will be on the developer to understand what they should and should not edit through the API and avoid editing datasets that have geodatabase behavior." --------- For rasters, the preferred path can be inferred from the official description of the API: "This API does not replace ArcObjects as the recommended approach to interacting with the geodatabase." Therefore if you want to work with raster data sets in file geodatabases you use ArcObjects, which is a commercial product offered by ESRI and not a free API. To branch off into a different direction I respectfully note that there was a lot of happy talk around the original issuance of the file geodatabase API as being intended to make it freely available to anyone who wanted to code an application that could "open File Geodatabase tables in non-ESRI applications to view or modify data." But the actual license, as more alert people at the time noted, did not allow that. It was surprisingly restrictive in many ways, for example, for years blocking use by ESRI competitors. The good news is that ESRI has changed the license for the API to what is one of the best and most straightforward licenses around. Now the license for the API does indeed open the API for use by anyone, including ESRI competitors. Kudos to ESRI for moving to genuinely and professionally opening up the API for use by anyone. It will be in Radian and 9, for example. Good work ESRI. Unfortunately the raster bit is not in the API. But what is in there already is very useful and good for the world GIS community.
|