[Imports] TIGER realignment import

Paul Norman penorman at mac.com
Tue Aug 6 22:04:11 UTC 2013

> From: Eric Fischer <enf1234567890 at gmail.com>
> Sent: Tuesday, August 06, 2013 9:10 AM
> Subject: Re: [Imports] TIGER realignment import

> Thanks. I'll try to learn how to run an API server then.

If needed, you can probably get some help with this from someone.

> I'm just writing it out by hand, which I know you think is a bad 
> idea. I can run it through tidy or try to find an XML writer library 
> if this is important to you.

The problem is you will almost certainly miss some escaping or character 
encoding issue when you try to write XML by hand. Somewhere out there is 
a TIGER way where some tag has been added which contains some 
combination of UTF characters that you didn't think of. I guess if every 
.osc passes xmllint it's okay - TIGER ways probably don't cover as many 
odd possibilities as OSM data in general does. 

> It's doing the checks for anything that has a TIGER TLID, and in this 
> case it's an administrative boundary that came from TIGER. I can restrict 
> it to just roads (and railroads?) if you think that is better.
Probably best to do so. Admin boundaries need cleaning up too, but I think 
that needs a more manual intervention because it's not just a geometry

If we feel the need to do more than roads and railroads later on we could do
> That is strange. I would have guessed they added the node because some 
> invisible boundary for census tract, etc., crossed over the road, but it 
> looks like only that one TIGER edge uses that point. I think this is 
> actually legitimate, though, because the change moves node 50690471 to a 
> different point within the line, ~315 feet away. 
> What's going on here is that the TIGER reshaping of this road expands it 
> from 16 to 21 points, and I there's no information about which old 
> points correspond to which new ones except at the endpoints. I 
> arbitrarily added the new nodes at the end and kept the existing nodes 
> toward the beginning, but I could change it to add new nodes in the 
> middle instead, or make it try to guess which old points correspond to 
> which new ones. 

I guess that's reasonable. Ideal would be guessing which points correspond, 
at least in the case of a non-moved point, but I wouldn't really spend any 
effort trying to do that.

> [...]
> > In 56025-0000.osc node 157668125 is modified in the .osc file but no
> > changes are actually made to it. It is not moved at all. This seems to
> > be fairly common and makes it hard to review the changes because there
> > are so many "false positives" when looking for changes.
> > 
> > In the same file node 157626325 is modified with no movement and neither
> > of its parent ways are actually present in the file.
> That is definitely a bug, because it should only output nodes that were 
> actually moved. I'll fix it. 
> You mentioned not including the parent ways-I am intentionally not 
> including the ways in the output when no nodes were added or removed, 
> only moved, since the way itself didn't really change. Do you think 
> that is a bad idea, and it should always include all affected ways?

What you're doing with not including ways is correct, it's just this 
particular node shouldn't of been included either.

More information about the Imports mailing list