<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>
<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 class="HOEnZb"><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 class="">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 class="h5"><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">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>