How to get parcel or zipcode boundaries for display in map?

Okay after over a week of researching and trying out different options, there are a few depending on your budget and how consistently accurate you want the data to be. I got a few tips form this stackExchange post, but did a ton reserach and added more.

In short, boundary data is hard to get your hands on, expensive, and varies in quality depending on your source. Zip Code Tabulation Areas (ZCTA's) are not very accurate (like maponics says) and can be seen by checking this ZCTA site for zip 92064. Then look at that zip on zillow and notice the difference. ZCTA data is not always accurate (in the case of this zipcode), but can be free depending on your source.

In summary, here's my options in order of preference (given my smaller budget and need for accurate data):

  1. For Parcel boundaries only, Report All is very reasonably priced and has parcel boundaries for my entire county for $250. Here's a list of available counties available for purchase (for parcels). Here's a sample download of a county in Excel, Shapefile, or KML format although the Excel file seems to be missing the polygon coordinates (duh). KML format has polygon and looks good though. Here's a link to the pricing breakdown which basically gets supercheap with the more listings you buy.
  2. For zipcode boundaries only, Maponics is fairly priced IMO. Basically, it's a one time annual download that's $200 per county (zipcode boundaries only) that you'd use throughout the year and repurchase annually for updates. It offers parcel boundaries for several thousand per month after talking to the sales rep (sigh). However, still a good solution for zipcode boundaries though.
  3. For zipcode boundaries only, you can also use zip-codes.com which is about $50 for my county. Not bad.
  4. For zipcode boundaries only, zipboundary.com - pricing is by subscription.
  5. For zipcode boundaries only, you can download the free raw data from this FTP server provided by the US Census Bureau and transform it to your needs. Free, but long lengthy process requiring other tools and skills (PostGreSQL, PostGIS), but it does give you accurate boudary data in terms of a polygon for Zip Code Tabulation Areas (ZCTA's). Read about it in this other SO post.
  6. For neighborhood boundaries, you can use Zillow's free neighborhood boundary shape files. It's free, but they do require a logo and link to their site when used. After downloading my state and looking at my city, I noticed it was incomplete and somewhat innacurate as there were many gaps in the shaded neighborhoods.
  7. GeoCommunicator (run by US Dept of Interior - Bureau of Land Management). GeoCommunicator doesn't work with APNs (Assessor's Parcel Number) and only works with (land) lots for which you would also need several other pieces of information to get a boundary for. The GetTRS API on the Township Geocoder Service takes a lat & lng, but failed to resolve some of the coordinates (for residential properties) I put in and returned "No LD Features found". I'm also not sure what boundary level is returned (lot or bigger) from that API. The other GetLatLng API on the Township Geocoder Service seems to be the better solution, but that's the one that needs all those other params in addition to the (land) lot number. The docs for it say it needs: "A comma-separated String of Township Range properties describing a single PLSS survey area" which consists of the all these pieces of data I wouldn't have even if I could obtain the (land) lot number.
  8. UrbanMapping's Mapfluence javascript API has a several different types of boundary data including Parcel and neighborhood boundary data. After spending a few days working with the zipcode, neighborhood, and parcel boundary requests, the ZCTA boundaries returned are very different for some zipcodes (92064) as mentioned above which is just the nature of ZCTA's. The neighborhood boundaries are very sparse (only covered about 5% of the searched area) and are as small as buildings in the majority of the cases I tested. Plus, in addition to the docs needing more info, they are also inaccurate as the parcel boundary table specified (umi.us_parcel.geometry) gets rejected from the API as "Geometry table umi.us_parcel.geometry does not exist". All that combined with there is no community documentation, no online response from support issues submitted, no phone support from leaving half dozen voicemails, and no returned emails. Based on my experience with this, I'll pass and seek alternative routes for parcel and zipcode boudary data despite this initially looking a diamond in the rough.