Geographic Handling in the Incentives API

Background

When working with geographic data such as residence locations, the most accurate way to do so is an actual geocode (latitude/longitude) for a point on the earth. For example, the Kansas State Capitol is -94.5862, 39.0901. However, most people do not know this for their own home, and they shouldn’t have to. For the purposes of determining eligibility for an incentive, a home address is sufficient. However, there are a lot of different geographic areas that determine what incentives a user might qualify for. Based on the incentives currently in our system, this includes:

• Utility service areas
• County boundaries
• City boundaries
• State boundaries
• Combinations of the above (such as multiple utility service areas, or multiple counties). These combinations can be contiguous (adjacent counties) or not (multiple utilities across a state that are not near each other).

These are all represented by our concept of Authorities in our dataset. Every Authority in our data has a State attached to it. This means that some Authorities may appear more than once, if they serve multiple states, such as Xcel Energy. These are different records, with different IDs, and different states. They also have different Programs and Incentives associated with them.

When a user wants to determine incentives for their location, whether through our calculator or the API, we have approached this problem via shorthand. We have approximated many of the boundaries above using a ZIP code map to protect user privacy. ZIP codes are a tool created by the US postal service to enhance delivery of mail, and were not in use until 1963! These codes have some loose relation to the boundaries above, but it is by no means 1:1. Some ZIP codes straddle more than one state, many cover more than one city or county, and utility boundaries are determined by pipes or wires, not postal service.

Concepts translated to our API

Utility Service Areas

Electric Utilities

For electric utilities, we have leveraged the ENERGY STAR file which provides a listing of all electric utilities in the United States, and which ZIP codes are serviced by that utility. We have encountered areas where it needs correction, and have done so when we are alerted by utilities. That does not mean that everyone in that ZIP code receives electric service from that utility, just that some residents of that area do. Likewise, there can be more than one utility servicing a given ZIP code.

Gas Utilities

For gas utilities, there is a similar file available from the Geospatial Management Office. In some cases, we have worked with individual state energy agencies to gather gas utility shape files with higher accuracy. These files were then combined with the federal ZCTA (ZIP code tabulation area) file, to output which gas utilities service an individual zip code. Again, that does not mean all residents of that ZIP code receive gas service from that utility, and more than one gas utility could service the same ZIP code. The states which we have completed this for include MA, OR, and VT. It will also include MN in the future. We add coverage for gas utilities only where it is relevant for incentive eligibility.

Challenges

Based on the fact that ZIP codes are a very loose correlation to boundaries that determine eligibility for incentive programs, it’s important for users to understand how our logic processes this ambiguity.

In cases where part of the authority boundary (such as a city or county) overlaps with a ZIP code, then we will display incentives to front end users for that authority, and include a message “Eligibility depends on residence location” to those users. For API users, the ZIP code is mapped to a single postal city (which comes from USPS) and no hedging message is displayed in the API response.

If the entirety of a ZIP code is within an authority boundary, then incentives for that authority will be displayed.

If a utility services part of a ZIP code but not all, we will still display incentives for that authority, if the user has selected that utility as their electric or gas provider.

Example: The City of Denver offers rebates to its residents for e-bikes. Applicants must be a city resident. When a user comes to our calculator and enters their ZIP code, we determine that the ZIP code is partially in the City of Denver. In this case, we still display the incentive as something the user may qualify for, understanding that they most likely know that if they are outside of city limits they cannot apply for Denver rebates.

NOTE regarding tribal lands:

Currently we do not have any tribal lands or tribal land specific incentives in our API. There are some programs where eligibility is determined by whether a person is an enrolled tribal member. This is not the same as tribal lands, as a person could be an enrolled member yet live off of the tribal land, and vice versa.