[OSM-dev] TIGER import.rb
dave at sr71.net
Wed Jun 20 07:02:49 BST 2007
On Tue, 2007-06-19 at 10:07 +0100, Andy Robinson wrote:
> Dave Hansen wrote:
> >Sent: 19 June 2007 1:06 AM
> >To: Brandon Martin-Anderson
> >Cc: dev at openstreetmap.org; Alex Mauer
> >Subject: Re: [OSM-dev] TIGER import.rb
> >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
> I took a look over this file in a little more detail and have a couple of
> observations which I hope are constructive:
> 1. A power line that runs through the area on a line SSW to NNE appears to
> have short spurs that I guess are the local distributor from the main power
> line. These and the actual power line itself currently connect themselves to
> nodes on the highway network. Perhaps this is because in the TIGER data they
> share the same node co-ords. I'd suggest that the reuse of nodes be limited
> to each separate TIGER data type and not across data types. Would this throw
> up any other issues?
It turns out that JOSM will take nodes that have the exact same
coordinates and negative ids, and combine them into a single node. I've
managed to get the data produced to have two distinct nodes at the same
location for the example you provided, with the power line crossing the
road. However, I've had to assign positive ids to the OSM objects.
Is there any way to get JOSM to stop this behavior? I guess we could
detect when we have two nodes in the same place and just add some small,
random, floating point value to the coordinates.
ids <= 0 are interpreted by the server to tell it to fill in the id when
it is inserted into the database, right?
> 2. The aggregation of segments into ways results in some instances in some
> strange way patterns. Is this perhaps because there is insufficient
> information in the TIGER data to differentiate where one logical way ends
> and the next starts? Perhaps it might be worth seeing if splitting a way
> where it makes a major change in direction (say greater than 60 degrees)
> improves things. This should be applied only where the change in direction
> occurs at a junction with another way.
Right now, there's no real geometry calculations in the whole thing. Is
there any ruby code for doing the angle calculations handy somewhere?
More information about the dev