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

问题

I want to add a boundary to a specified parcel of land so that it stands out in the map with a colored outline/border. In google maps, this is done using the polygon functionality if you know that path of coordinates to enter to surround the land parcel. However, I do not have the polygon path info, but I do have the both the geocode coordinates for the location and also the Assessor's Parcel Number (APN) for the parcel as well.

I found this other SO post that talks a little about how to get the polygon for zipcodes using the free Census Bureau data coupled with some open source software, but it's quite involved (as you have to download and host the data) and I'm not sure it even does percision down to parcel boundaries. It's definitely an option if it supports parcels, but it looks to be very time consuming albeit free.

I also found a paid solution (price not displayed) called ParcelStream, but thinking it's expensive and probably just using the above solution in the other SO post. This is also an option if it's a small one time fee, but not if it's expensive or a subscription fee.

I am aware you can manually create overlays on maps, save, and then share them, but I'm looking for an automated/programatic solution.

UPDATE: okay, ParcelStream from Digital Map Products, is not an option and around 10k/month. They advised the subscription service is intended for national coverage (not local) and Google is among their clients.

UPDATE #2: Using the US Census Bureau data solution mentioned above (coupled with other open source software) doesn't seem to provide boundary data down the parcel after browsing the features available on it's TIGERweb2010 site.

回答1:

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):

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.
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.
For zipcode boundaries only, you can also use zip-codes.com which is about $50 for my county. Not bad.
For zipcode boundaries only, zipboundary.com - pricing is by subscription.
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.
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.
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.
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.