<div dir="ltr"><div class="gmail_extra">Charles,</div><div class="gmail_extra"><br></div><div class="gmail_extra">The zipcode information from <a href="http://census.gov">census.gov</a> aren't official zipcodes. Only the USPS knows those and they don't give them out very often. Also, zip codes are not polygons, but lines. Also, the data from Census is from 2010 and hasn't been updated since. It's my opinion that they should not be imported.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">To answer your technical question: yes, overlapping boundaries should be split apart and the pieces put into relations.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">
-Ian<br><br><div class="gmail_quote">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><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</blockquote></div></div></div>