Just woke up, been dreaming about OSM.

1. For the ZCTA (zip code tabulation areas) instead of adding the areas to OSM,
process the streets and mark them as follows :

1.a tag "is_in:zcta:2009"=012345 for the streets completely inside a ztca

1.b two tags, left and right "boundary_(left|right):zcta:2009"=01234 add a new node to any Boundary points of the street which intersect a ztca.

1.c tag "FIXME:zcta:2009" for any points that conflict with existing zipcode data.
Here are some conflicts :
1.c.1 : The existing tiger zipcode/post_code attribute does not match the ZCTA
1.c.2 : The street is not inside any ZCTA.
1.c.2 : The street needs to be split up into parts between multiple ZCTA and create relations instead.

So that would just markup the existing streets with the zcta data and allow them to be processed later without causing any new data to be displayed on the map.

The creating of ztca relationships using the existing streets is the next step
1.d the tag "border_left:zcta:2009"=01234 for any street that is along the border of a zcta on the left hand side. analogous for the right hand side.

Now that is for those.

The other thing will be to render each zcta as a tile, or a set of tiles using the bounding box. The tiles can be hosted statically on archive.org. Even more we can use open layers as well to pull in more data from OSM.

The static html pages hosted on archive.org can be enhanced so that users can provide feedback via email. We can include openlayers as well to allow for dynamic behaviour, including the latest OSM data as well. If we do it right, we can also replace old data on the fly using js.
Each one will then have a way to report problem, each node will have a way for the user to select a street or point and say : this belongs to zipcode X. Then they can submit it via email to designated email address to be processed.

With this scheme we can display the maps, allow people to use them, and also
allow for feedback and a decentralised update. The only thing needed to allow for updates it to include some java script from a source that is easy to update. We can use a smaller git repository to host just the changes to the zipcodes and that data can then be pulled in by the js to display updated.

The other thing is the counties, we need to create relations out of the county way. But also more than that, we need to flag all areas that have nodes outside the county borders. In Atlantic City NJ, I notice that the county border was way off. If you look at the map, you will see that someone drew in a nicer border, but that is out of sync with the county.

So the admin borders need to be checked in general, from the NJ file, I noticed there were lot of smaller issues with them.

Even the county borders were not marked with an admin level, the did not have any clear criteria that I could select in qgis. I had to use "name"='%County' which is a hack!

Now, my script to extract the polygons produced a lot of unnamed nodes which I suppressed. We need to be able to mark these regions in a hierarchy and also show the relationship to each other.

is_in:county would be a good way to say that this region is contained by a county directly. Ideally we would have a hierarchy of layers all the way down.

These are just some of my ideas, more to come. thanks for listening up to this point.

mike