Re: [Talk-us] [Imports] Zipcode Import
Hey Mike, Where did you find the ZIP Code boundaries? They are licensed data from the USPS and would not have a compatible license for OSM. Or are you refering to ZCTAs (ZIP Code Tabulation Areas)? ZCTAs are not the same thing as ZIP codes http://www.census.gov/geo/ZCTA/zcta.html. They are usually the same but not always, this is because the USPS doesn't even give their ZIP Code database to the U.S. Census. According to this Wikipedia article http://en.wikipedia.org/wiki/ZIP_Code_Tabulation_Area some of them represent data that doesn't exist in the USPS database anymore. Not trying to rain on your parade, just want people to be aware that it is not the same thing. Kate Chapman user:wonderchook On Sun, Dec 20, 2009 at 7:57 AM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > I have found a nice source of ZipCode boundries, > http://www.openstreetmap.org/user/h4ck3rm1k3/diary/8994 > > do you want to import them? > mike > > ___ > Imports mailing list > impo...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/imports > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Hi, I posted the sources, nothing from UPS, but from the us census : Five digit splitting of NJ: http://www.census.gov/geo/cob/bdy/zt/z500shp/zt34_d00_shp.zip Three digit splitting of NJ: http://www.census.gov/geo/cob/bdy/zt/z300shp/z334_d00_shp.zip This is just processed using the shp2osm.pl http://www.census.gov/geo/ZCTA/zctafaq.html mike On Sun, Dec 20, 2009 at 3:29 PM, Kate Chapman wrote: > Hey Mike, > > Where did you find the ZIP Code boundaries? They are licensed data from the > USPS and would not have a compatible license for OSM. Or are you refering > to ZCTAs (ZIP Code Tabulation Areas)? ZCTAs are not the same thing as ZIP > codes http://www.census.gov/geo/ZCTA/zcta.html. They are usually the same > but not always, this is because the USPS doesn't even give their ZIP Code > database to the U.S. Census. > > According to this Wikipedia article > http://en.wikipedia.org/wiki/ZIP_Code_Tabulation_Area some of them represent > data that doesn't exist in the USPS database anymore. > > Not trying to rain on your parade, just want people to be aware that it is > not the same thing. > > Kate Chapman > user:wonderchook > > > > On Sun, Dec 20, 2009 at 7:57 AM, jamesmikedup...@googlemail.com > wrote: >> >> I have found a nice source of ZipCode boundries, >> http://www.openstreetmap.org/user/h4ck3rm1k3/diary/8994 >> >> do you want to import them? >> mike >> >> ___ >> Imports mailing list >> impo...@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/imports > > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Ahh, I mean the ZIP Code Tabulation Areas. I checked it for my home town 07933 and was very happy. My plan was to use this as as starting point. mike On Sun, Dec 20, 2009 at 3:29 PM, Kate Chapman wrote: > Hey Mike, > > Where did you find the ZIP Code boundaries? They are licensed data from the > USPS and would not have a compatible license for OSM. Or are you refering > to ZCTAs (ZIP Code Tabulation Areas)? ZCTAs are not the same thing as ZIP > codes http://www.census.gov/geo/ZCTA/zcta.html. They are usually the same > but not always, this is because the USPS doesn't even give their ZIP Code > database to the U.S. Census. > > According to this Wikipedia article > http://en.wikipedia.org/wiki/ZIP_Code_Tabulation_Area some of them represent > data that doesn't exist in the USPS database anymore. > > Not trying to rain on your parade, just want people to be aware that it is > not the same thing. > > Kate Chapman > user:wonderchook > > > > On Sun, Dec 20, 2009 at 7:57 AM, jamesmikedup...@googlemail.com > wrote: >> >> I have found a nice source of ZipCode boundries, >> http://www.openstreetmap.org/user/h4ck3rm1k3/diary/8994 >> >> do you want to import them? >> mike >> >> ___ >> Imports mailing list >> impo...@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/imports > > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 7:57 AM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > I have found a nice source of ZipCode boundries, > http://www.openstreetmap.org/user/h4ck3rm1k3/diary/8994 > > do you want to import them? > mike > No. Zip codes do not represent geographic regions. They should not be in a the map data, but in a separate database. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Anthony wrote: >No. Zip codes do not represent geographic regions. They should not be in a >the map data, but in a separate database. Please explain your reasoning. This claim seems quite counterintuitive to me. A Zip is part of everyone's address just like city and state. I've seen them on many commercial printed maps. -- Later, Jeff ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 10:46 AM, Jeff Barlow wrote: > Anthony wrote: > > >No. Zip codes do not represent geographic regions. They should not be in > a > >the map data, but in a separate database. > > Please explain your reasoning. This claim seems quite > counterintuitive to me. > > A Zip is part of everyone's address just like city and state. > I've seen them on many commercial printed maps. > A zip code is part of every USPS address, yes. But unless you are going to map zip codes as huge multipolygons of thousands of individual buildings each (in some cases probably overlapping), that doesn't make them geographic areas. http://www.census.gov/geo/www/tiger/tigermap.html#ZIP If you *really really* want zip codes in OSM, then put them in addr:postcode, on buildings or nodes (by themselves or as part of an interpolation way). Or better yet use a relation (since a zip code is actually a relation, not an area). But personally I think even that is better stored in an external database. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Serge Wroclawski wrote: >A Zip Code is a routing code. It doesn't represent geography any more >than you can do a 1:1 mapping of iP address to physical location. > >You can do a "Pretty good" job by simplifying the data, but zip codes >are attributes of addresses, not regions. > >If you want to add these zip codes to objects with addr fields, that >would be accurate, but you can't accurately represent a zip code as a >region. Huh... Well, if all that's true then how do you account for the fact that many very good commercial printed maps, including the wonderful Thomas Guides, have for many years included outlines of Zip codes? Are we aiming for academic correctness or practical utility? -- Later, Jeff -- Later, Jeff ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
please just take a look at the OSM file i uploaded they are regions of NJ all split up into approximate regions. It looks pretty good. Even if they are not the real zipcode, but approximates, they could be at least used to double check points. My idea is to take the points from the EPA that have zipcodes, counties and lat/long and then check if they all match. Given enough data we could look for inconsistencies. mike On Sun, Dec 20, 2009 at 5:43 PM, Jeff Barlow wrote: > Serge Wroclawski wrote: > >>A Zip Code is a routing code. It doesn't represent geography any more >>than you can do a 1:1 mapping of iP address to physical location. >> >>You can do a "Pretty good" job by simplifying the data, but zip codes >>are attributes of addresses, not regions. >> >>If you want to add these zip codes to objects with addr fields, that >>would be accurate, but you can't accurately represent a zip code as a >>region. > > Huh... Well, if all that's true then how do you account for the > fact that many very good commercial printed maps, including the > wonderful Thomas Guides, have for many years included outlines of > Zip codes? > > Are we aiming for academic correctness or practical utility? > > -- > Later, > Jeff > > -- > Later, > Jeff > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
Based on what is posted there, the OSM could become a good source of zip data. We import the census data, and then let people update it. Eventually, if we all work together, we can build the best zip code database in the county. mike On Sun, Dec 20, 2009 at 5:32 PM, Anthony wrote: > On Sun, Dec 20, 2009 at 10:46 AM, Jeff Barlow wrote: >> >> Anthony wrote: >> >> >No. Zip codes do not represent geographic regions. They should not be >> > in a >> >the map data, but in a separate database. >> >> Please explain your reasoning. This claim seems quite >> counterintuitive to me. >> >> A Zip is part of everyone's address just like city and state. >> I've seen them on many commercial printed maps. > > A zip code is part of every USPS address, yes. But unless you are going to > map zip codes as huge multipolygons of thousands of individual buildings > each (in some cases probably overlapping), that doesn't make them geographic > areas. > > http://www.census.gov/geo/www/tiger/tigermap.html#ZIP > > If you *really really* want zip codes in OSM, then put them in > addr:postcode, on buildings or nodes (by themselves or as part of an > interpolation way). Or better yet use a relation (since a zip code is > actually a relation, not an area). But personally I think even that is > better stored in an external database. > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 11:47 AM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > please just take a look at the OSM file i uploaded they are regions of > NJ all split up into approximate regions. It looks pretty good. > > Even if they are not the real zipcode, but approximates, they could be > at least used to double check points. > > My idea is to take the points from the EPA that have zipcodes, > counties and lat/long and then check if they all match. > > Given enough data we could look for inconsistencies. > And when we find them, what should we do? Are you thinking about importing zip codes, or zip code tabulation areas? If the latter, then there are no inconsistencies. A ZCTA is exactly what the census bureau says it is. The fact that it doesn't coincide with actual zip codes is *intentional*. "*There is no correlation between U.S. Postal Service ZIP Codes and U.S. Census Bureau geography*. This is because individual U.S. Postal Service ZIP Codes can cross state, place, county, census tract, block group and census block boundaries (just to name a few)." So if I find a "mistake" in the ZCTA, and I fix it, now I've screwed up the statistical data which was based on that ZCTA. It's the same as the problem of those annoying "census designated place" polygons, which also should have never been imported. I know, you found a bunch of really cool public domain data, and that's great. But Census Bureau data is designed for the Census Bureau. OSM needs to come up with its own notion of what types of things it wants to map first. Then, if the public data we can find fits our purposes, we use it. If not, we don't. What's the useful purpose of this ZCTA information, besides the narrow purpose of interpreting Census Bureau statistical data? Let's figure out what that is, and gear the OSM data to that. I think if you do that you'll find that zip codes are not best represented as areas. On Sun, Dec 20, 2009 at 11:43 AM, Jeff Barlow wrote: > Well, if all that's true then how do you account for the > fact that many very good commercial printed maps, including the > wonderful Thomas Guides, have for many years included outlines of > Zip codes? > When making a printed map you need to decide what to include and what not to include. That's the time when you combine separate databases, or interpolate point data into areas. The OSM database is not a map. It's a database which provides information that allows you to create maps. If you really want to store zip code information in the OSM database, it's best stored as points. Then if you want to make a map which shows zip codes as areas, you can interpolate areas from the points as you make the map. You'll find when doing so that you have to make certain tradeoffs. But instead of having someone else (the Census Bureau) decide what tradeoffs to make based on their needs, you can decide what tradeoffs you want to make based on your needs. For example, maybe it doesn't matter to you that zip codes "can cross state, place, county, census tract, block group and census block boundaries (just to name a few)", because you aren't drawing lines on your map for those boundaries. So that's a tradeoff you don't have to make. Again, let's decide what data we want first, and only *then* ask whether or not ZCTAs can help us get it. On Sun, Dec 20, 2009 at 12:27 PM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > Based on what is posted there, the OSM could become a good source of zip > data. > We import the census data, and then let people update it. Eventually, > if we all work together, we can build the best zip code database in > the county. > Best for what purpose? That has to be answered first. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 11:10 AM, Serge Wroclawski wrote: > On Sun, Dec 20, 2009 at 10:46 AM, Jeff Barlow wrote: > > Anthony wrote: > > > >>No. Zip codes do not represent geographic regions. They should not be > in a > >>the map data, but in a separate database. > > > > Please explain your reasoning. This claim seems quite > > counterintuitive to me. > > A Zip Code is a routing code. It doesn't represent geography any more > than you can do a 1:1 mapping of iP address to physical location. > > You can do a "Pretty good" job by simplifying the data, but zip codes > are attributes of addresses, not regions. > > If you want to add these zip codes to objects with addr fields, that > would be accurate, but you can't accurately represent a zip code as a > region. > > - Serge > > I don't understand why you wouldn't want ZIP Codes in OSM. Do they not represent a geographic area in some parts of the country? In my area, each ZIP Code represents a specific geographic area. One can easily figure out what town someone is from based on their ZIP Code. Is this not the case everywhere? -Jeremy ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams wrote: > One can easily figure out what town someone is from based on their ZIP > Code. Is this not the case everywhere? > Certainly not. There are lots of zip codes which represent multiple towns, and lots of towns which represent multiple zip codes. 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. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 12:41 PM, Anthony wrote: > On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams wrote: > >> One can easily figure out what town someone is from based on their ZIP >> Code. Is this not the case everywhere? >> > > Certainly not. There are lots of zip codes which represent multiple towns, > and lots of towns which represent multiple zip codes. > > 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. > 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. -Jeremy ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 12:45 PM, Jeremy Adams wrote: > On Sun, Dec 20, 2009 at 12:41 PM, Anthony wrote: > >> On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams wrote: >> >>> One can easily figure out what town someone is from based on their ZIP >>> Code. Is this not the case everywhere? >>> >> >> Certainly not. There are lots of zip codes which represent multiple >> towns, and lots of towns which represent multiple zip codes. >> >> 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. >> > > But the code still represents a geographic area? > No, the code doesn't represent a geographic area. You can force it into a geographic area, by defining the area in some particular way (e.g. a multipolygon of all buildings which receive mail addressed to that zip code). Of course, given that definition, some zip codes will overlap (probably not much area-wise if you use only 5 digit zip codes), and lots of areas will have no zip code (what's the zip code for a particular point on the highway of I-95?). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Listen, Yes, and the zipcode of my area surrounds my old house. please just load the osm file in your josm and look. here is the file : http://ia341326.us.archive.org/0/items/OpenstreetmapZipcodes/zt34_d00.osm mike On Sun, Dec 20, 2009 at 6:45 PM, Jeremy Adams wrote: > On Sun, Dec 20, 2009 at 12:41 PM, Anthony wrote: >> >> On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams >> wrote: >>> >>> One can easily figure out what town someone is from based on their ZIP >>> Code. Is this not the case everywhere? >> >> Certainly not. There are lots of zip codes which represent multiple >> towns, and lots of towns which represent multiple zip codes. >> >> 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. > > 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. > > -Jeremy > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
I posted some comments on the blog post about zip codes: For splitting up OSM data, I suggest splitting data up by counties or other geographic units (e.g. census tracts). Zip code boundaries are problematic and should not be imported. In reality, zip codes are merely attributes assigned to addresses and street segments, and not geographic areas. People have attempted to create zip code boundaries, though there is no standard way of creating them. The Census Bureau's zip code boundaries differ from other sources (e.g. county GIS departments). Also, zip code "boundaries" change all the time, as new addresses/buildings are added for mail delivery. The only official zip code "boundaries" would come from the USPS, however the USPS does not publish them and has them for internal use only. Changes in zip code assignments and boundaries are done by a GIS person at the regional postal facilities (e.g. in Dulles, VA) who adjusts them in ArcView (or MapInfo), without keeping a history of the changes. For more about issues with zip code polygons, see: http://www.biomedcentral.com/content/pdf/1476-072x-5-58.pdf If we end up deciding to import zip codes, it should be done only after much discussion and with a lot of care. They should be assigned to address points, and not as boundaries. About the data posted to archive.org: For the Census zip code boundaries, there are the 5-Digit ZIP Code Tabulation Area (2002), linked from http://www2.census.gov/cgi-bin/shapefiles2009/state-files?state=34. There other versions of Census zip code boundaries, aside from that one. >From the archive.org link and data link there, I can't tell which it is. And, according to the Census TIGER technical documentation: "Data users should not use ZCTAs to identify the official USPS ZIP Code for mail delivery. The U.S. Postal Service (USPS) makes periodic changes to ZIP Codes to support more efficient mail delivery. As a result, the original Census 2000 and 2002 ZCTAs may no longer match current ZIP Codes." http://www.census.gov/geo/www/tiger/tgrshp2009/TGRSHP09.pdf Regards, Katie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
data from census isn't best quality and it will just repeat the errors from tiger import. tiger roads have already zip codes. there is no additional value. in the long term full address data is the way to go. imports for data from census should be done only locally where mapper can verify the quality of the data. for geocoding it's better to use a plain set of tiger data outside of osm. jamesmikedup...@googlemail.com wrote: Hi, I posted the sources, nothing from UPS, but from the us census : Five digit splitting of NJ: http://www.census.gov/geo/cob/bdy/zt/z500shp/zt34_d00_shp.zip Three digit splitting of NJ: http://www.census.gov/geo/cob/bdy/zt/z300shp/z334_d00_shp.zip This is just processed using the shp2osm.pl http://www.census.gov/geo/ZCTA/zctafaq.html mike On Sun, Dec 20, 2009 at 3:29 PM, Kate Chapman wrote: Hey Mike, Where did you find the ZIP Code boundaries? They are licensed data from the USPS and would not have a compatible license for OSM. Or are you refering to ZCTAs (ZIP Code Tabulation Areas)? ZCTAs are not the same thing as ZIP codes http://www.census.gov/geo/ZCTA/zcta.html. They are usually the same but not always, this is because the USPS doesn't even give their ZIP Code database to the U.S. Census. According to this Wikipedia article http://en.wikipedia.org/wiki/ZIP_Code_Tabulation_Area some of them represent data that doesn't exist in the USPS database anymore. Not trying to rain on your parade, just want people to be aware that it is not the same thing. Kate Chapman user:wonderchook On Sun, Dec 20, 2009 at 7:57 AM, jamesmikedup...@googlemail.com wrote: I have found a nice source of ZipCode boundries, http://www.openstreetmap.org/user/h4ck3rm1k3/diary/8994 do you want to import them? mike ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
jamesmikedup...@googlemail.com wrote: Based on what is posted there, the OSM could become a good source of zip data. We import the census data, and then let people update it. Eventually, if we all work together, we can build the best zip code database in the county. mike who is the people to update? who has the knowledge and is working on osm? the same believe was out for tiger import but where are all the people improving the data? I can't see many of them. adding more data to osm isn't useful just because it's easy to import. without active participation no application using where is the point? census data might change faster than anyone is willing to improve in osm. than this will be the worst zip code db because it's out of date in some places. up to date in others. no quality measurement in place. On Sun, Dec 20, 2009 at 5:32 PM, Anthony wrote: On Sun, Dec 20, 2009 at 10:46 AM, Jeff Barlow wrote: Anthony wrote: No. Zip codes do not represent geographic regions. They should not be in a the map data, but in a separate database. Please explain your reasoning. This claim seems quite counterintuitive to me. A Zip is part of everyone's address just like city and state. I've seen them on many commercial printed maps. A zip code is part of every USPS address, yes. But unless you are going to map zip codes as huge multipolygons of thousands of individual buildings each (in some cases probably overlapping), that doesn't make them geographic areas. http://www.census.gov/geo/www/tiger/tigermap.html#ZIP If you *really really* want zip codes in OSM, then put them in addr:postcode, on buildings or nodes (by themselves or as part of an interpolation way). Or better yet use a relation (since a zip code is actually a relation, not an area). But personally I think even that is better stored in an external database. ___ 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 12:53 PM, Anthony wrote: > > No, the code doesn't represent a geographic area. You can force it into a > geographic area, by defining the area in some particular way (e.g. a > multipolygon of all buildings which receive mail addressed to that zip > code). Of course, given that definition, some zip codes will overlap > (probably not much area-wise if you use only 5 digit zip codes), and lots of > areas will have no zip code (what's the zip code for a particular point on > the highway of I-95?). > > Also, some zip codes not only overlap, but overlap on only one side of a street inside an area kind of like two interlocking combs. In another example, when Collegedale, TN (http://osm.org/go/ZQvRbHZs-) incorporated as a city, the USPS assigned ZIP 37315 to all PO Boxes, but left all home mailboxes in ZIP 37363 (unincorporated Ooltewah, TN). To add to the fun, all home mailboxes inside Collegedale city limits must be physically located on the odd numbered side of the street. Incorporated Collegedale, TN (ZIP 37363) and incorporated Chattanooga, TN (ZIP 374xx) have annexed most if not all of unincorporated Ooltewah, TN but the 37363 ZIP code remains. Every time a house is purchased inside Collegedale city limits the new owner has to choose to either register the address as a delivery point with the 37363 post office, or lease a PO box in the 37315 post office. To summarize, the USPS ZIP data is constantly in flux and does not necessarily map to any particular geographic or political boundaries. Yes, we could theoretically import ZIP data as polygons, but then someone would have to automate and QC weekly/monthly/annual diffs as the USPS data changed. Chris ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 7:23 PM, Katie Filbert wrote: > I posted some comments on the blog post about zip codes: > > For splitting up OSM data, I suggest splitting data up by counties or other > geographic units (e.g. census tracts). > > Zip code boundaries are problematic and should not be imported. In reality, > zip codes are merely attributes assigned to addresses and street segments, > and not geographic areas. > > People have attempted to create zip code boundaries, though there is no > standard way of creating them. The Census Bureau's zip code boundaries > differ from other sources (e.g. county GIS departments). Also, zip code > "boundaries" change all the time, as new addresses/buildings are added for > mail delivery. > > The only official zip code "boundaries" would come from the USPS, however > the USPS does not publish them and has them for internal use only. Changes > in zip code assignments and boundaries are done by a GIS person at the > regional postal facilities (e.g. in Dulles, VA) who adjusts them in ArcView > (or MapInfo), without keeping a history of the changes. > > For more about issues with zip code polygons, see: > http://www.biomedcentral.com/content/pdf/1476-072x-5-58.pdf > > If we end up deciding to import zip codes, it should be done only after much > discussion and with a lot of care. They should be assigned to address > points, and not as boundaries. > > About the data posted to archive.org: > > For the Census zip code boundaries, there are the 5-Digit ZIP Code > Tabulation Area (2002), linked from > http://www2.census.gov/cgi-bin/shapefiles2009/state-files?state=34. This is even more detailed, I have uploaded the osm files : http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta5.osm and http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta3.osm > > There other versions of Census zip code boundaries, aside from that one. > From the archive.org link and data link there, I can't tell which it is. The data I processed was from here : http://www.census.gov/geo/www/cob/z52000.html http://www.census.gov/geo/www/cob/z32000.html Now as a test, I loaded them into josm, loaded a set of data from the OSM server and searched for an example zip 07827 There is a distinct area covered by this zip code. Alot of the streets, even the one from tiger did not contain that. All of the ones found were in the box. This street for example, clover road, has that zipcode, so I added the attribute tag "postal_code" http://www.openstreetmap.org/browse/way/11765580 Now, with all this data, we should be able to automate some of this. At least the checking of the data. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 7:39 PM, Apollinaris Schoell wrote: > jamesmikedup...@googlemail.com wrote: > > Based on what is posted there, the OSM could become a good source of zip > data. > We import the census data, and then let people update it. Eventually, > if we all work together, we can build the best zip code database in > the county. > mike > > > > who is the people to update? who has the knowledge and is working on osm? > the same believe was out for tiger import but where are all the people > improving the data? I can't see many of them. adding more data to osm isn't > useful just because it's easy to import. without active participation no > application using where is the point? census data might change faster than > anyone is willing to improve in osm. than this will be the worst zip code db > because it's out of date in some places. up to date in others. no quality > measurement in place. well, we can start by checking the consistency of the data we have. We can make sure that all the counties and zipcodes are consistent to the data we have. mike ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 8:53 PM, Chris Hunter wrote: > > > On Sun, Dec 20, 2009 at 12:53 PM, Anthony wrote: >> >> No, the code doesn't represent a geographic area. You can force it into a >> geographic area, by defining the area in some particular way (e.g. a >> multipolygon of all buildings which receive mail addressed to that zip >> code). Of course, given that definition, some zip codes will overlap >> (probably not much area-wise if you use only 5 digit zip codes), and lots of >> areas will have no zip code (what's the zip code for a particular point on >> the highway of I-95?). >> > Also, some zip codes not only overlap, but overlap on only one side of a > street inside an area kind of like two interlocking combs. > > > In another example, when Collegedale, TN (http://osm.org/go/ZQvRbHZs-) > incorporated as a city, the USPS assigned ZIP 37315 to all PO Boxes, but > left all home mailboxes in ZIP 37363 (unincorporated Ooltewah, TN). To add > to the fun, all home mailboxes inside Collegedale city limits must be > physically located on the odd numbered side of the street. > > Incorporated Collegedale, TN (ZIP 37363) and incorporated Chattanooga, TN > (ZIP 374xx) have annexed most if not all of unincorporated Ooltewah, TN but > the 37363 ZIP code remains. > > Every time a house is purchased inside Collegedale city limits the new owner > has to choose to either register the address as a delivery point with the > 37363 post office, or lease a PO box in the 37315 post office. > > > To summarize, the USPS ZIP data is constantly in flux and does not > necessarily map to any particular geographic or political boundaries. Yes, > we could theoretically import ZIP data as polygons, but then someone would > have to automate and QC weekly/monthly/annual diffs as the USPS data > changed. Wow. So let me as you, this : Would OSM be able to display or store this ? I think so. Would it be easy to process the data once encoded? not always, but we dont have to make it easy, just possible. The PO Boxes dont show up on the map, or would at least all go to a single point, the post office, or a set of them. 37315 PO box , one point. and the rest of them would be a wild mix between : 37363 home mailboxes in ZIP 37363 (unincorporated Ooltewah, TN). 374xx Chattanooga, TN So, I guess that we would need to tag each house or street with the zip to display if it was in what region. I guess it would be possible. What are the usages of such a system? Given a house number on a street, or a point on the map determine what postcode it has. Given a zip code, determine the streets contained in it. These are valid usages. Even if the result is not always easy to use, for example if you have a street that is split between two zip codes, you could always segment it, no? please advise, mike ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 2:54 PM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > > This is even more detailed, > I have uploaded the osm files : > > http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta5.osm > and > > http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta3.osm > > Using cartographic license, the Census Bureau came up with boundaries that do not overlap. These are not the same as official USPS zip codes, used for mail delivery. Also, the Census Bureau zip code files are way out of date. (although it's 2009 TIGER data, the zip codes are dated 2002 and 2000) Please try some other unit of geography, such as Census tracts, for dividing up OSM data in chunks to work on. For importing, zip code boundaries are not appropriate for OSM. -Katie PS. - Do note that using and not understanding zip code polygons is a common mistake seen in academic literature, such as using them to normalized date. It happens even in some scholarly geography journal articles. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Hi, Anthony wrote: > No. Zip codes do not represent geographic regions. They should not be > in a the map data, but in a separate database. If I may chime in from the other side of the pond. Here in Germany we have post codes as well (hear, hear) and they are, theoretically, an artifact used for mail delivery, just as I gather from some of your postings. Some post codes are used for PO Boxes exclusively, and entities with large mail volumes can even get their individual post code. Still, the post codes are *commonly* used as a shortcut geo reference; it is a very popular way of doing e.g. a store finder on a web site - enter your post code and we'll show you the nearest store. Because of this, there is high demand for post codes to be available in OSM and I am certain that we will eventually either map or import them. (Not as administrative boundaries of course.) It is also not unusual to have choropleth maps built on top of post code areas, even though they suffer the same shortcomings here that Katie mentioned. I don't know if your zip codes are used in the same fashion. If they are, and if you have reason to believe that potential errors can be fixed by people on the ground, then I'd say it makes sense to have them in OSM. If, on the other hand, your zip codes are not really used as a geo reference, or if you think it is unlikely that the data can be maintained by ordinary people, then I'd leave it out. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
I understand! The counties are fine for splitting up the data. These zip codes are very interesting anyway, but it looks like some real work will be needed to process them. After looking on the net, I think there will be a big market for such data and I am facinated by the idea of being able to make money from this need to think about it some more. mike On Sun, Dec 20, 2009 at 9:15 PM, Katie Filbert wrote: > On Sun, Dec 20, 2009 at 2:54 PM, jamesmikedup...@googlemail.com > wrote: >> >> This is even more detailed, >> I have uploaded the osm files : >> >> http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta5.osm >> and >> >> http://ia341327.us.archive.org/0/items/OpenstreetmapZipcodes/tl_2009_34_zcta3.osm >> > > Using cartographic license, the Census Bureau came up with boundaries that > do not overlap. These are not the same as official USPS zip codes, used for > mail delivery. > > Also, the Census Bureau zip code files are way out of date. (although it's > 2009 TIGER data, the zip codes are dated 2002 and 2000) > > Please try some other unit of geography, such as Census tracts, for dividing > up OSM data in chunks to work on. For importing, zip code boundaries are > not appropriate for OSM. > > -Katie > > PS. - Do note that using and not understanding zip code polygons is a common > mistake seen in academic literature, such as using them to normalized date. > It happens even in some scholarly geography journal articles. > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
Thanks Fredrick and Katie, Yes, this is how US ZIP (postcodes) work as well. I'm not a web programmer, but I assume most of the post-code based geolocation that websites use work off of a centroid and distance-vector approach. I agree that ZIPs are very useful for one-way geocoding, but not so useful for reverse geocoding, which is what I think Mike wants to do. Mike, If you're looking for administrative boundaries to split your regions on, I believe all of the county boundaries have been imported from the 2010 US Census data at this point. Have fun, Chris On Sun, Dec 20, 2009 at 3:34 PM, Frederik Ramm wrote: Hi, Anthony wrote: > No. Zip codes do not represent geographic regions. They should not be > in a the map data, but in a separate database. If I may chime in from the other side of the pond. Here in Germany we have post codes as well (hear, hear) and they are, theoretically, an artifact used for mail delivery, just as I gather from some of your postings. Some post codes are used for PO Boxes exclusively, and entities with large mail volumes can even get their individual post code. Still, the post codes are *commonly* used as a shortcut geo reference; it is a very popular way of doing e.g. a store finder on a web site - enter your post code and we'll show you the nearest store. Because of this, there is high demand for post codes to be available in OSM and I am certain that we will eventually either map or import them. (Not as administrative boundaries of course.) It is also not unusual to have choropleth maps built on top of post code areas, even though they suffer the same shortcomings here that Katie mentioned. I don't know if your zip codes are used in the same fashion. If they are, and if you have reason to believe that potential errors can be fixed by people on the ground, then I'd say it makes sense to have them in OSM. If, on the other hand, your zip codes are not really used as a geo reference, or if you think it is unlikely that the data can be maintained by ordinary people, then I'd leave it out. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 3:34 PM, Frederik Ramm wrote: > I don't know if your zip codes are used in the same fashion. If they > are, and if you have reason to believe that potential errors can be > fixed by people on the ground, then I'd say it makes sense to have them > in OSM. If, on the other hand, your zip codes are not really used as a > geo reference, or if you think it is unlikely that the data can be > maintained by ordinary people, then I'd leave it out. > > It would be appropriate to attach zip code as attributes to addresses. Making the boundaries is the tricky part. If we were to use polygons to assign zip codes to the addresses, the census data is not good for that purpose. The best may be data from GIS departments in local governments. It looks like the DC government went to some lengths to get data from the USPS and then do substantial verifications. http://data.octo.dc.gov/Metadata.aspx?id=130 Still, I would be hesitant about having zip code polygons (as opposed to address attributes) in OSM. -Katie > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > Imports mailing list > impo...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/imports > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
On Sun, Dec 20, 2009 at 3:34 PM, Frederik Ramm wrote: > Still, the post codes are *commonly* used as a shortcut geo reference; it > is a very popular way of doing e.g. a store finder on a web site - enter > your post code and we'll show you the nearest store. Because of this, there > is high demand for post codes to be available in OSM and I am certain that > we will eventually either map or import them. I have responded to that, though. A single point in the approximate center of the general area where a zip code is used is fine. I don't think OSM is really the best place to store those (slightly less than) 9 points, because it so easily stands alone and isn't something that lends itself to public editing (you just import a database every so often, it's not really something individual OSMers can survey). But I'll get over that - if you really get a kick out of importing 99,999 or so zip code centroids, fine. In fact, I can probably find a CSV file where the centroids have already been calculated for this. It's quite a common application. (You'll basically be converting someone's table of zip codes to lat/lon pairs into OSM nodes, so geocoders can then take those OSM nodes and convert them back to a table of zip codes to lat/lon pairs. But, whatever, have a ball.) If you want to do more than that, as Katie said, "It would be appropriate to attach zip code as attributes to addresses." ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Jeff Barlow wrote: > Serge Wroclawski wrote: > >>A Zip Code is a routing code. It doesn't represent geography any more >>than you can do a 1:1 mapping of iP address to physical location. >> >>You can do a "Pretty good" job by simplifying the data, but zip codes >>are attributes of addresses, not regions. >> >>If you want to add these zip codes to objects with addr fields, that >>would be accurate, but you can't accurately represent a zip code as a >>region. > > Huh... Well, if all that's true then how do you account for the > fact that many very good commercial printed maps, including the > wonderful Thomas Guides, have for many years included outlines of > Zip codes? I'm not sure why Thomas Guides include them (though I wouldn't exactly call them wonderful, either; this year's Thomas Guide is easily 10 years out of date in the Portland area). Nobody uses the ZIP codes except the post office. Truckers certainly don't use 'em, it's easier to look up the state, city, and street in that order. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Anthony wrote: > On Sun, Dec 20, 2009 at 12:29 PM, Jeremy Adams wrote: > >> One can easily figure out what town someone is from based on their ZIP >> Code. Is this not the case everywhere? >> > > Certainly not. There are lots of zip codes which represent multiple towns, > and lots of towns which represent multiple zip codes. > > You can usually find out an approximate geographical location from a zip > code (at least if it isn't an APO/FPO zip code). Don't count on that. ZIP codes change frequently, and since 1983 when the Post Office moved to 9-digit ZIP codes, the areas involved became impractically small for anything other than door-to-door mail delivery. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Mike, How do you plan to make money off of this? When you buy road data from Navteq and Teleatlas you can get their ZIP code boundaries with it so everything lines up all nicely. Though the quality of that data is usually more up to date than the ZCTAs. Unfortunately I don't see the ZCTAs as being the best way to create ZIP boundaries. I don't see people fixing the boundaries, I have no idea where my ZIP boundaries are for my area. I do know my own ZIP code, but that's because I need it to give people my address. Creating ZIP boundaries from address data makes the most sense to me, though on the other hand I don't see us creating point level addressing for the whole country anytime soon either. If you want to import data I would suggest looking at some other sources. There is a ton of local GIS data available that people want to put into OSM they just need assitance doing so. If in the U.S. we are going to do a combination of imports and community mapping I think starting at a local level is the best answer. There is a ton of datasets out there and we haven't really started asking around for them yet. Kate Chapman user:wonderchook On Sun, Dec 20, 2009 at 3:39 PM, jamesmikedup...@googlemail.com < jamesmikedup...@googlemail.com> wrote: > I understand! The counties are fine for splitting up the data. > These zip codes are very interesting anyway, but it looks like some > real work will be needed to process them. After looking on the net, I > think there will be a big market for such data and I am facinated by > the idea of being able to make money from this > need to think about it some more. > > mike > > > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
The USPS treats ZIP codes as an extension of address data and as such, they should be treated as point data, since they are an attribute of the address associated with a building or a property parcel. The problem with creating polygons out of these points is that the ZIP codes don't cleave neatly along natural geographic boundaries (e.g. roads, hydrographic features, etc.). This doesn't prevent map publishers from aggregating them into polygons, however published maps of ZIP polygons should be considered rough approximations, rather than officially recognized ZIP code polygons. I think it's best to keep the ZIP as part of the address tags rather than try to shoehorn ZIPs into polygons which would be inaccurate and subject to frequent change. SEJ "Wretches, utter wretches, keep your hands from beans." -Empedocles On Sun, Dec 20, 2009 at 16:00, Anthony wrote: > On Sun, Dec 20, 2009 at 3:34 PM, Frederik Ramm wrote: > >> Still, the post codes are *commonly* used as a shortcut geo reference; it >> is a very popular way of doing e.g. a store finder on a web site - enter >> your post code and we'll show you the nearest store. Because of this, there >> is high demand for post codes to be available in OSM and I am certain that >> we will eventually either map or import them. > > > I have responded to that, though. A single point in the approximate center > of the general area where a zip code is used is fine. I don't think OSM is > really the best place to store those (slightly less than) 9 points, > because it so easily stands alone and isn't something that lends itself to > public editing (you just import a database every so often, it's not really > something individual OSMers can survey). But I'll get over that - if you > really get a kick out of importing 99,999 or so zip code centroids, fine. > In fact, I can probably find a CSV file where the centroids have already > been calculated for this. It's quite a common application. (You'll > basically be converting someone's table of zip codes to lat/lon pairs into > OSM nodes, so geocoders can then take those OSM nodes and convert them back > to a table of zip codes to lat/lon pairs. But, whatever, have a ball.) > > If you want to do more than that, as Katie said, "It would be appropriate > to attach zip code as attributes to addresses." > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
On Mon, Dec 21, 2009 at 1:39 AM, Kate Chapman wrote: > Mike, > > How do you plan to make money off of this? When you buy road data from > Navteq and Teleatlas you can get their ZIP code boundaries with it so > everything lines up all nicely. Though the quality of that data is usually > more up to date than the ZCTAs. I dont have a concrete plan, I must admit. But it looks like an area that is not covered yet. > > Unfortunately I don't see the ZCTAs as being the best way to create ZIP > boundaries. I don't see people fixing the boundaries, I have no idea where > my ZIP boundaries are for my area. I do know my own ZIP code, but that's > because I need it to give people my address. Creating ZIP boundaries from > address data makes the most sense to me, though on the other hand I don't > see us creating point level addressing for the whole country anytime soon > either. Well, > > If you want to import data I would suggest looking at some other sources. > There is a ton of local GIS data available that people want to put into OSM > they just need assitance doing so. If in the U.S. we are going to do a > combination of imports and community mapping I think starting at a local > level is the best answer. There is a ton of datasets out there and we > haven't really started asking around for them yet. I am not going to import any more mass data into the OSM main server What I am interested in is how to convert and prepare this data for people to use when they want to, if they want to. At least now I have a way to share the data (archive.org). Now my next step will be to extract the county data out and start the splitting process. As an exercise. The other thing that I am interested in is how to convert these areas into regions with shared edges. This is still interesting and exciting for me personally, because I am learning alot from it. thanks for all your help and advice. mike ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Paul Johnson writes: > Nobody uses the ZIP codes except the post office. Truckers > certainly don't use 'em, it's easier to look up the state, city, and > street in that order. Many businesses offer to search for local branches by ZIP code. Businesses calculate shipping costs based on your ZIP code. Google maps and friends display ZIP codes. ZIP codes are also a tool for consistency checking. All these uses have nothing to do with the post office. Matthias ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
An interesting article about the recent increase in the rate of change in zip code boundaries: http://www10.giscafe.com/nbc/articles/view_weekly.php?articleid=763562&page_no=1 David. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
I have done some work today, I hacked the osm2poly to produce polygons from the tiger 5 point zip codes : http://fmtyewtk.blogspot.com/2009/12/using-osmosis-to-split-zipcode-files.html It produces one polygon file per zipcode tabulation area. I can then extract the data from that to look at what fits in it. Also, you can see from my older posts, I setup qgis and was able to pull in the various zipcode layers and admin borders. Will be producing polygons for the counties as well, easy stuff. The next scripting job will be to create relationships from the ways, and reuse the sides of the boundries. I am reviewing my old zipcode 07933 now and resolving some obvious problems with the tiger zip codes which are very wildly distributed. You can use these zipcode boundaries as a starting point for checking the consistency of the data. mike On Mon, Dec 21, 2009 at 3:50 PM, David Fawcett wrote: > An interesting article about the recent increase in the rate of change > in zip code boundaries: > http://www10.giscafe.com/nbc/articles/view_weekly.php?articleid=763562&page_no=1 > > David. > > ___ > 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
Re: [Talk-us] [Imports] Zipcode Import
I want to summarize and clarify a few things on this thread. 1) I don't think most people are saying that zip codes aren't useful pieces of information., I know some are, but the majority recognize the general utility of a zip code map. 2) There's a general recognition that zip codes are quite a complex issue. They look simple, but once you start to poke at it, you see that zip codes are address attributes and don't' map geographically. They don't have normal borders. 3) If you accept #2, then do have a polygon based zip code map, you have to use an artificial projection, and the argument is that all the projections are bad: Out of date, inaccurate, in constant need of fixing, etc. and that this effort would be a lot of work to maintain. 4) Some people say that you can make a map afterwards, using data you collected. You make your own projection based on the data which will always be up to date according to the data in OSM. It's worth mentioning that several of the people on this thread (including me) are involved in a major import at the moment, and several of the folks involved are professional geographers. I point this out because this import has taught me a lot about both geography and OSM and think the answer for these zip codes are: As many as we can as part of addressing, and we can derive data from there- which isn't something we do much in OSM at the moment, but which could be done and I think has a lot of potential for the future. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Zipcode Import
Matthias Julius wrote: > Paul Johnson writes: > >> Nobody uses the ZIP codes except the post office. Truckers >> certainly don't use 'em, it's easier to look up the state, city, and >> street in that order. > > Many businesses offer to search for local branches by ZIP code. > Businesses calculate shipping costs based on your ZIP code. Google > maps and friends display ZIP codes. ZIP codes are also a tool for > consistency checking. All these uses have nothing to do with the post > office. And all of them break in the Portland because the post office regularly changes the local zipcodes. For example, 97006 has been on a westward shift continuously all decade. 97008 has been moving north. Using ZIP for geolocation considered harmful. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
