[Talk-us] Counties and city/CDP boundaries (was re: Silly borders)

[Chris Lawrence]

On Tue, Mar 31, 2009 at 10:18 AM, Ian Dees <ian.dees at gmail.com> wrote:
> I saved some of the imports, but in my experience almost all of the borders
> have been modified or deleted already enough to make the saved data
> unusable.
>
> (I feel really bad about that... I should have asked for it to be deleted a
> long time ago.)

Sorry I got to this thread late.

I for one would have no objection to seeing all the county boundaries
blown away and just reimported from scratch; even the manual edits
I've done to fix things in places are surely less accurate than
bringing in the TIGER 2008 county boundaries (which should be pretty
close to the survey boundaries, or else we taxpayers got ripped off)
using the relations system that plays nicely with non-polygon borders.
 We then could go in and fix up the overlaps with state and national
borders as needed.  (The state borders I suppose could be intuited
from the county borders automatically - a county boundary that doesn't
abut another county is pretty much by definition a state boundary
too.)

On a related note, I'm thinking of pulling in the place boundaries
from TIGER 2008 (they're not entirely accurate but they're better than
nothing, which is what we have now in most states).  I've hacked on
polyshp2osm.py a bit to get it to cope with imported multipolygons
(non-contiguous cities were getting dumped out as "degenerate rings"
before) and it seems to work for Texas at least.  I'm also running a
post-processing step to merge nodes that overlap (cities w/common
borders, enclave cities, etc.).

Onto the questions before I convert some other states and upload to OSM:

1. Should I only import real incorporated areas, or also include
census designated places (CDPs)?  (CDPs are census areas and have no
legal status.)  Incorporated areas clearly should be
boundary=administrative, admin_level=8; at the moment I'm just marking
CDPs with "place=locality" since TIGER/Line has no information on the
populations in the shapefiles.  GNIS already has CDPs in it, but
without boundaries (which have no legal status).  There are a few
geographic CDPs that make sense to import regardless (military bases).

2. Relatedly, the legal type of the incorporated area is in the TIGER
NAMELSAD field but it doesn't correspond to "OSM rules" for place=*.
I'm using the legal type (city, village, town, etc.) regardless since
that's the only thing in the data without hacking a lookup.  Since the
GNIS nodes seem to be what is labeled anyway, I'm not too worried
about lots of little cities' names being rendered on the map at low #
zoom levels.  But I wanted to run that past everyone anyway...

3. I'm including a lot of is_in tags (is_in:country=USA,
is_in:country_code=US, is_in:state=Texas, freeform-style is_in="USA,
Texas" etc) on the polygons and coined is_in:iso_3166_2 (e.g. US:TX)
for automated tools' use in the future.  I assume this will help out
the navigation tools and namefinder.  Does that sound OK?

4. Finally, are there any states to be avoided (e.g. already being
worked on or with OSM-licensing compatible local data that's probably
better)?

Once I have everything finalized I'll also provide the hacked up
polyshp2osm.py file which may be useful for other bulk conversions.


Chris