Comment on page

Reference Data Index

Below is a table of the reference datasets mentioned in this document. View all the reference data below in the open data portal.
Description and Constraints
Reference Columns
The EAS is the system of record for DBI when assigning official addresses. Coordinates are most often associated with the center of a parcel or close to it, rather than at the door or entry. This still allows associations, but it means that in certain cases a building footprint cannot be spatially matched via intersection or "point in polygon" with it's address(es).
Same general limitations as the Addresses dataset above, but also includes sub-addresses like units. Unit numbers are formally referenced for condos because the City records these for the purposes of properly tying deeds and other property records to a specific unit and owner. Rental units are not formally recorded by the City.
The footprint extents are collapsed from an earlier 3D building model provided by Pictometry of 2010, and have been refined from a version of building masses publicly available on the open data portal for over two years. The building masses were manually split with reference to parcel lines, but using vertices from the building mass wherever possible. These split footprints correspond closely to individual structures even where there are common walls; the goal of the splitting process was to divide the building mass wherever there was likely to be a firewall. An arbitrary identifier was assigned based on a descending sort of building area for 177,023 footprints. The centroid of each footprint was used to join a property identifier from a draft of the San Francisco Enterprise GIS Program's cartographic base, which provides continuous coverage with distinct right-of-way areas as well as selected nearby parcels from adjacent counties.
sf16_bldgid unique identifier for footprint mblr for reference to property identifiers including parcels and right of way
These department codes are maintained in the City's Financial System of Record. Department Groups, Divisions, Sections, Units, Sub Units and Departments are nested in the dataset from left to right. Each nested unit has both a code and an associated name. The dataset represents a flattened tree (hierarchy) so that each leaf on the tree has it's own row. Thus certain rows will have repeated codes across columns. Data changes as needed.
Nested (right to left): department_group_code division_code section_code unit_code sub_unit_code department_code
These are the current active recorded parcels. The geography can be used as reference but should not be used for anything requiring precision.
block_num lot_num blklot
A list of street segments and intersections sorted by street name and ascending address number. This data set is based on the City's GIS basemap and contains CNN id numbers for each record.
cnn as number For segments: from_cnn and to_cnn define the node IDs at each end
These are the current and historic parcels with recorded dates. Historic parcels only go back to about 1995 with some exceptions. Useful for tying historic administrative records to a location. The geography can be used as reference but should not be used for anything requiring precision.
block_num lot_num blklot
Just the blocks without lots
A geographic reference of the all basemap streets including centerline node network identifiers and jurisdictions and street names by segment
cnn as number cnntext as text f_node_cnn as the starting (from) node ID t_node_cnn as the ending (to) node ID fullstreetname composed of streetname & streettype
Contains a list of officially valid street names contained in the City's Basemap
fullstreetname composed of streetname & streettype
A list of Street Segment and Intersection (CNN) changes including new, dropped, realigned, divided and split records.
oldcnn as number newcnn as number