<div dir="ltr">ZCTAs are a way of aggregating and reporting the statistical data that the Census Bureau collects. <div><br></div><div>Because the Census Bureau has an obligation to protect the privacy of individuals, two or more small postal zip codes may be combined in the ZCTA data. For example, if only only one family lived in a particular zip code, to report data about that zip code such as "median household income" would in effect reveal that family's household income and violate their privacy. </div>
<div><br></div><div>As pointed out earlier, postal zip codes are really routes or lines. In converting those to areas, some generalization may take place.</div><div><br></div><div>Zip codes for individual institutions or buildings are not represented, at least not in all cases. </div>
<div><br></div><div>In some areas of the country where nobody receives mail (e.g. Wilderness Areas), pseudo (e.g. 99999) zip codes have been created so the nation has 100% coverage in the ZCTA data. </div><div><br></div><div>
In any event, the ZCTAs are no more accurate than the TIGER data which they were originally a part of.</div><div><br></div><div>Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 1:00 PM, Steven Johnson <span dir="ltr"><<a href="mailto:sejohnson8@gmail.com" target="_blank">sejohnson8@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Formally, the Census product is called ZCTAs - Zip Code Tabulation Areas, and they are polygons. They are useful in a variety of operations internal to Census Bureau, and externally as part of the transportation planning program but, as others have pointed out, they are NOT official Zip codes. The Zip codes maintained by the USPS are point features; attributes of the postal address. They are often grouped in the Delivery Sequence File, and in that sense, represent linear features. <br>
<br></div>I commend Charles for wanting to improve the Zip code data within OpenStreetMap, but given the second-hand provenance, it's dubious currency, and structure of the data, I would recommend against importing it. Like others, I'd recommend contacting the Imports group and take up the issue with them. <br>
<br>Best,<br>SEJ<br></div><div class="gmail_extra"><br clear="all"><div>-- SEJ<br>-- twitter: @geomantic<br>-- skype: sejohnson8<br><br>There are two types of people in the world. Those that can extrapolate from incomplete data.<br>
</div><div><div class="h5">
<br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 2:52 PM, Toby Murray <span dir="ltr"><<a href="mailto:toby.murray@gmail.com" target="_blank">toby.murray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>What exactly is the census data representing? Zip codes are not polygons (they are routes) so I'm curious what exactly they are modeling. <br></div><div><br></div><div>But beyond that, I'm not sure zip code boundaries are all that useful in OSM. I think Nominatim already figures out zip code basics from addr:postcode values in the data although I'm not overly familiar with its internal workings.</div>
<span><font color="#888888">
<div><br></div><div>Toby</div><div><br></div></font></span></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Mon, Feb 17, 2014 at 1:11 PM, <span dir="ltr"><<a href="mailto:osm@charles.derkarl.org" target="_blank">osm@charles.derkarl.org</a>></span> wrote:<br>
</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
I have a shape file from <a href="http://census.gov" target="_blank">census.gov</a> which contains the boundaries for all zip<br>
codes in the US. This data should not need licensing in that it comes from the<br>
us federal census.<br>
<br>
I would also like the community to answer this technical question: Each<br>
boundary obviously shares a border with another zip code. Should those shared<br>
boundaries have the same way, and then each zip code becomes a relation?<br>
<br>
Failing any negative replies, I will cook up an implementation and provide<br>
some .osm files for review before importing.<br>
<br>
Charles<br>
Boulder Creek, CA, USA<br>
<br>
_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
<br></blockquote></div><br></div>