<div class="gmail_quote">On Sun, Dec 20, 2009 at 12:41 PM, Anthony <span dir="ltr"><<a href="mailto:osm@inbox.org">osm@inbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams <span dir="ltr"><<a href="mailto:milenko@king-nerd.com" target="_blank">milenko@king-nerd.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One can easily figure out what town someone is from based on their ZIP Code.  Is this not the case everywhere?<br></blockquote></div><div><br>Certainly not.  There are lots of zip codes which represent multiple towns, and lots of towns which represent multiple zip codes.<br>

<br>You can usually find out an approximate geographical location from a zip code (at least if it isn't an APO/FPO zip code).  But if that's all you want, you're best off just representing zip codes as single points in the approximate geographical center of all post boxes which receive mail to that zip code.  Going in the other direction, from lat/lon to zip code (assuming your lat/lon is the location of a building and/or post box), requires a much more specialized database which isn't currently available as public domain.<br>

</div></div>
</blockquote></div><br>But the code still represents a geographic area?  If this is the case, I don't see why we wouldn't want them in OSM.  It'd be the same as administrative boundries, county lines, etc.<br>
<br>-Jeremy<br>