[OSM-dev] TIGER import.rb

Brandon Martin-Anderson badhill at gmail.com
Tue Jun 19 01:57:15 BST 2007

>From before: The endpoints of TIGER features have a globally unique ID
called  "zero cell id" or sometimes "tzid". that's what you'll find tagged
to the endpoints of some ways.

Regarding weird errors. First thing I'd do is find some way to view the same
TIGER file in some other viewer, just to make sure it's not a glitch in the
TIGER data. In the past I've run into problems like this and spent hours
hunting it down, just to find the error was just in crumby data. If that's
not the case, I'll go in sleeves rolled up to see about the bug.

I haven't had a moment to sit down with your code, so I'm noticing a few
things for the first time. You implemented grouping of ways by street name,
which is good for map rendering. There are some cases where I'd like to see
a non-grouped osm.xml, like if I'm curious about the TLID of a buggy
feature. Perhaps we could implement a command-line switch to turn grouping
behavior on and off.

Your example TIGER file is _beautiful_ compared to the one I slapped into
the OSM map a week ago.


On 6/18/07, Dave Hansen <dave at sr71.net> wrote:
> I've noticed a few weird looking ways, like that the nodes aren't being
> connected in the right order.  I've traced it down enough to see that by
> the time the data gets to Dataset::to_osm(), it is already bogus.  So, I
> think if there's an error, it's in the TIGER parsing code.
> Although, I guess it could just be faulty TIGER data to begin with.
> Check out this .osm file:
>         http://sr71.net/~dave/foo/TGR18115.osm.xml.gz
> One of the suspect roads is State Road 56/Aberdeen Rd.  The bad segments
> are around 38.913485,-84.933538.
> Any ideas?
> -- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070618/b2a0524e/attachment.html>

More information about the dev mailing list