There are a few exceptions, but the local post offices know how to handle them. They are also extremely minor and the people who live or do business in these areas are probably used to the confusion.
If you're curious though: Part of Kentucky has a Tennessee zip code and addresses: http://en.wikipedia.org/wiki/Kentucky_Bend There's also a town in Illinois with a Missouri zip code, although the current ZCTA map shows it as being in an Illinois zip code: http://en.wikipedia.org/wiki/Kaskaskia,_Illinois Fishers Island, NY has a Connecticut zip code, but its own post office, so this is really only a special case from a routing point of view: http://en.wikipedia.org/wiki/Fishers_Island,_New_York#Culture -- Jim McAndrew On Thu, Nov 29, 2012 at 3:46 PM, Jeffrey Ollie <j...@ocjtech.us> wrote: > On Thu, Nov 29, 2012 at 4:26 PM, Richard Fairhurst <rich...@systemed.net> > wrote: > > Jeffrey Ollie wrote: > >> It looks pretty good from what I saw, with the obvious exception > >> that newer homes aren't tagged. I'm going to clean up my code > >> a bit and stick it up on github somewhere. > > > > If you chaps are all dead set on doing another massive TIGER import - > hey, > > it's your funeral - could I at least urge a little caution on the > > practicalities of it all? > > > > Just having a look at the .osm file posted here, for example, the street > > names are all unexpanded: Washington St, Park Ave, Deer Run Ln, etc. > There > > have been about 937 threads about expanding TIGER street names since the > > initial import and it would be a shame to fall into the same hole again. > > None of the Iowa data that I am processing originates with the US > Census or TIGER. The underlying sources of the data are described ad > nauseum here: > > ftp://ftp.igsb.uiowa.edu/gis_library/counties/Story/Address_85.html > > Basically the data comes from county auditor parcel data, processed > through the US Postal Service addressing database, and compared > against aerial photography to move the point to the intersection of > the driveway with the road. > > As for name expansion, I'll take a look into that. The data source > that I'm using doesn't separate prefixes and suffixes out like TIGER > does though... > > > I'm also very very doubtful about the value of importing city, state and > (!) > > country: if we don't have polygons for all of those already, then we > really > > should. Importing n billion nodes into the States which all say "hey, > this > > is in the States" will bloat the database and hammer download speeds for > > absolutely no gain whatsoever. > > As Richard Welty said, the addr:city tag is pretty much required, as > US addresses aren't defined by the boundaries of the city you live in > (or don't live in for rural addresses), but the post office that > delivers your mail. > > I can see not including the country or the state, do the various > routing/geocoding engines take advantage of state/country polygons? > Are there any exceptions out there where the address is physically in > one state, but their postal address is from a neighboring state > because that's where the post office is? > > -- > Jeff Ollie > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
