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 <j...@wb6csv.net> 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
