But I’m assuming if you’re reading this then you’re not there yet, so lets talk spatial. Fundamentally there are three spatial types: point, line, and polygon. With these, you can represent every spatial object of interest. A point defines a location. A line defines a path (or in OpenStreet Maps speak, a way). A polygon defines an area.
A spatial object can be multiples of each, existing as a multi-point (collection of points), multi-line (multiple unconnected lines), or multi-polygons (collection of polygons). At the top of the hierarchy is the Geometry Collection that contains any mix of types.
A collection of these objects can exist in a database (like PostGIS, which is the model I’m using for this discussion), or in a shapefile, which is a text-based representation of the spatial data. There are many other formats for spatial data, including KML, an XML-based format used by Google Earth; however with regard to Census data, the spatial data available from the Census Bureau comes either in shapefile format or in Esri’s proprietary geodatabase format. Shapefiles are generally the way spatial data is loaded into GIS programs such as Esri’s ArcGIS (the industry standard) and QGIS (the open source alternative) to display information.
Do you need to display the Census data in a GIS program or store it in a PostGIS database? No. If you’re interested in just getting the data at whatever level of aggregation the Census Bureau provides (Census tract, Zip Code Tabulation Area, Metropolitan Statistical Area, State, Nation, etc), then all you need to do is key on that value (Census tract ID, zip code, city name, etc.) and retrieve the demographic data you’re interested in from your plain vanilla database.
But what if you’re trying to build something that will retrieve data based on your own values? Say a customer address or a buffer around your current stores? My next blog post will address these questions.