[OSM-dev] TIGER -> OSM import

SteveC steve at asklater.com
Thu Jun 7 23:54:54 BST 2007

Tom - thanks.


Meet the wonderful Jamie Taylor and Michal Migurski (who may not be  
on this list yet).

Jamie in his spare time has written a prototype TIGER => KML  
converter in python which he is in the process of fixing up in to a  
TIGER => OSM converter. Michal, Jamie and I have been having  
discussions on the best way forward.

As Tom outlined, I think using Jamies converter to county-by-county  
OSM files is the way forward. Take a county, load it in to JOSM and  
do your thing matching it with its neighbours and uploading. Use Y!  
to make the map vectors better. It will get everyone involved in the  
process and also make sure we don't try to go from 0 to TIGER in one  

Jamie will dump his script in to svn when he's ready. In the meantime  
someone's already started the major thing we need:


Please spend 5 minutes looking at the attribute conversion from TIGER  
to OSM as we'll need it.

I applaud all the other efforts to get TIGER in, it's just Jamie has  
working code so I'm all for going with it.

On 7 Jun 2007, at 19:24, Tom Carden wrote:

>> Brandon Martin-Anderson wrote:
>>> I know this isn't the first time this has been attempted, and it  
>>> would be
>>> foolish to rush in without knowing the problems encountered in  
>>> the past. So
>>> I'm curious: what failed in the past?
> I've spoke with Steve and Mikel about this recently, and I know other
> people are thinking about it and working on it too.  Better wait til
> Steve recovers from his jetlag for the best info.
> That said, I think the main strength in OSM is the people, and the
> people were not involved in the import of TIGER in the past.  So,
> aside from reliability issues (of both the OSM API and the machine
> that was uploading it) it failed because nobody was watching it.
> TIGER isn't that great a data format - e.g. roads that intersect do
> not have a node at the intersection, etc. - things I'm sure you're
> familiar with if you've done a routing engine that can read TIGER
> data.  Also TIGER doesn't care much about subtle bends in roads, and
> the metadata is somewhat esoteric.  Again, I'm sure you're familiar
> with that.
> Consensus among people I've spoken to about importing TIGER is that it
> should be done piece-meal (maybe one county at a time) by people who
> want it in their area.  It should also be done after people have
> looked at the TIGER documentation and come up with a reasonable
> mapping from TIGER metadata to commonly used OSM styles (otherwise it
> will have to marked up by hand, which is what we're trying to avoid).
> The *ideal* scenario would be a way to grab one county's worth of .osm
> file converted from TIGER, load it into JOSM, manually correct any
> obvious errors or conflicts with existing data and upload it from
> there.  This means OSM can scale gradually to accommodate the growth
> rather than struggle with millions of nodes being added all at once.
> First step would be to create a wiki page with the TIGER metadata
> classes and get folks to help fill in the best OSM tags to use.  The
> tutorials and style files for rendering TIGER with Mapserver etc will
> probably help, as well as the current OSM mapnik style file.
> Personally, I think the TIGER import should also add tags for all the
> metadata in TIGER (possibly name-spaced/machine-tag style
> tiger:foo=bar?) as well as tags about what version was imported, but I
> don't think it's totally essential.
> Hope that helps,
> Tom.
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

have fun,

SteveC | steve at asklater.com | http://www.asklater.com/steve/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070607/5469da5b/attachment.html>

More information about the dev mailing list