I am looking for Zipcode data with the +4 digits at the end for a City (I can use it by state and clip the points to my municipal boundary), and with edges or geocodes. I called the post office and had no luck (national customer center in Memphis, TN- claimed that their +4 ZIP Code GIS Layer is not for the public).
Would anyone know where I could find this data?
Some background: The USPS maintains zip codes as sets of delivery zones(5 digit) and routes(+4 digits), usually along streets with address boundaries. USPS does not maintain zip codes in any shape format.
I had the issue of finding a viable source as well. I narrowed my possible solutions to the following 4 and chose to go with #3.
You can download the 5 digit data from https://www.census.gov/geo/maps-data/data/tiger-line.html but the +4 data is not available from census or from the post office with +4 data.
Depending on how large your AOI is you can use the tool https://eddm.usps.com/eddm/customer/routeSearch.action to search zips. It will show the +4 routes which can be heads up digitized.
There are several companies that will sell you very accurate zip code data, Maponics being the one that I use. The five digit zip codes from them are pretty accurate. They do not offer zip+4 boundaries but they do have centroids for the +4 routes.
Your other option would be to request the address based data from USPS and attempt to create spatial data for it using parcels with addresses and streets as reference layers, though this would likely open a whole other can of worms.
The plus 4 value is based on the address there is not a single number for a city. It is not a universal number for a region as the first 5 digits are https://www.zip-codes.com/learn-about/what-is-a-zip-4-code.asp . You will need to calculate it against some tiger data if you are trying to get every unique value and tie it to a region.
It would be relatively easy to scrape the values you want against this web services https://www.zip-codes.com/search.asp
Additionally, what you are asking for probably does not exist because it's not a requirement for delivery and was not universally accepted... not all address have a +4: Source https://en.wikipedia.org/wiki/ZIP_Code#ZIP.2B4
The ZipPlus4 information seems to be available in the (old) Tiger/Line 2000 data. e.g. ftp://ftp2.census.gov/geo/tiger/tgrcd108/FL/tgr12099.zip for Palm Beach County, FL.
According to gdal driver documentation,
Feature Representation Following is a list of feature types, and their relationship to the TIGER/Line product.
CompleteChain
A CompleteChain is a polyline with an associated TLID (TIGER/Line ID). The CompleteChain features are established from a type 1 record (Complete Chain Basic Data Record), and if available it's associated type 3 record (Complete Chain Geographic Entity Codes). As well, any type 2 records (Complete Chain Shape Coordinates) available are used to fill in intermediate shape points on the arc.
...
ZipPlus4
These features are derived from type Z (ZIP+4 Codes) records. ZipPlus4 features have a many to one relationship with CompleteChain features.
However, the linked Tiger/Line 2000 data is in report type (.RT) files format, not in current GIS format.
Here are some example output for running ogrinfo TGR12099.RT1 ZipPlus4:
OGRFeature(ZipPlus4):50424
MODULE (String) = TGR12099
TLID (Integer) = 115356454
RTSQ (Integer) = 0
ZIP4L (Integer) = 3366
ZIP4R (Integer) = 3367
OGRFeature(ZipPlus4):50425
MODULE (String) = TGR12099
TLID (Integer) = 115356457
RTSQ (Integer) = 0
ZIP4L (Integer) = 6048
ZIP4R (Integer) = 6049
OGRFeature(ZipPlus4):50426
MODULE (String) = TGR12099
TLID (Integer) = 115356460
RTSQ (Integer) = 0
ZIP4L (Integer) = 2680
ZIP4R (Integer) = 5151
OGRFeature(ZipPlus4):50427
MODULE (String) = TGR12099
TLID (Integer) = 115356485
RTSQ (Integer) = 0
ZIP4L (Integer) = 0
ZIP4R (Integer) = 0
(Note: the TLID represents "complete chains" or arcs in the network). The complete chains are topologically correct according to the meta data:
- Complete chains must begin and end at nodes.
- Complete chains must connect to each other at nodes.
- Complete chains do not extend through nodes.
- Left and right GT-polygons are defined for each complete chain element and are consistent throughout the extract process.
There is an GIS.SE question (Anyone who has the ESRI Census 2000 Tiger/Line data?), which has an answer describing a script for converting the .RT files to shapefiles. I haven't tested it myself, but the code may be relevant.
Also, USPS really defines the ZIP(+4) codes etc. and may change it over time, so the Tiger/Line 2000 from census data may be outdated. Also, I am not an expert with Tiger data. You might want to check with the US Census/Tiger-line people to see if the ZipPlus4 is available in the current tiger-line files in GIS format.
You might want to check with the US Census/Tiger-line people to see if the ZipPlus4 is available in the current tiger-line files in GIS format. Historically, it's there in older formats.
Unfortunately Census hasn't included ZIP+4 values in TIGER/Line Shapefiles since 2006, and the data provider Maponics suggested by @Kingfisher folded into Pitney Bowes / Precisely and does not license their data directly (edit: they do license to Datasheer, see below).
That leaves three options:
Centroid files from EASI, Datasheer, GreatData, Geolytics, Geocoder, or AccuZip.
APIs from SmartyStreets or Geocodio.
USPS ZIP+4 (non-geocoded) product: you can run its address ranges through a geocoding API or GIS software. If you wanted to do this for historic ZIP+4, you could buy older snapshots ($825 national, $52.50 for one state, available back to 1994) and use the current City-State street name alias file to deal with street name changes.
This suggestion comes from the USPS Addressing and Geospatial Technology Group.
After talking with USPS and Census, I agree with the suggestion by @Kingfisher not to merge ZIP+4 onto Census TIGER/Line address ranges (edges).
A common misconception is that zip codes are areas, when in fact they are routes. You can conceptualize the area these routes occupy and make your analysis that way, but many people will see this as a flawed or problematic analysis especially if your data type conflicts with or exaggerates error created by that flawed understanding of zip codes.
