ZIP Codes in the United States are a great way to explore local data below the level of a city or town. They’re also an easy way to identify a location, since all ZIP Codes are unique. There are exceptions to the ease of using ZIP Codes, of course, as some can cross municipal boundaries. At this time, there is no better way to connect a broad swath of datasets at the local level than using the ZIP Code. For quantitative datasets (like building surveys), the hierarchy lets users quickly add up data or breakdown data. Climate Program Portal blends this data with the geography data on the Hub and allows users to easily add up the number of vehicles in a city, county, electric utility territory, and statewide.
Microsoft Power BI only supports a one-to-many relationship, which means a ZIP Code can only map to a single city, county, electric utility, combined statistical area, state, or regional division. As a result, we had to make tradeoffs when assigning the geography for each ZIP Code, which creates an error when the data is aggregated. The structure of the geography allows for some inconsistencies in geography data, however. A single city can be listed in more than one county, a county can be listed in more than one electric utility territory, and so forth, as long as each instance can be connected to a unique ZIP Code. For example, both a municipal utility and American Electric Power operate in Columbus, Ohio. Climate Program Portal distinguishes these two territories by ZIP Code, though that may not align well with the actual operating territories of the two utilities. Since the base geography is the ZIP Code, users should exercise caution when using Climate Program Portal to aggregate and use data for statistical analyses.