[OSM-dev] TIGER import.rb
badhill at gmail.com
Wed Jun 20 07:43:14 BST 2007
On 6/19/07, Dave Hansen <dave at sr71.net> wrote:
> 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
> > >the time the data gets to Dataset::to_osm(), it is already bogus. So,
> > >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
> > observations which I hope are constructive:
> > 1. A power line that runs through the area on a line SSW to NNE appears
> > have short spurs that I guess are the local distributor from the main
> > 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
> > share the same node co-ords. I'd suggest that the reuse of nodes be
> > to each separate TIGER data type and not across data types. Would this
> > 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.
We'll have to make sure JOSM can turn that behavior off, for the alternative
is a tremendous kludge.
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
> > strange way patterns. Is this perhaps because there is insufficient
> > information in the TIGER data to differentiate where one logical way
> > 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
> > 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?
I'm no sure what the exact definition of a Way is; my interpretation is that
it is a string of street segments that a nonexpert would identify as a
single road. Typically, this means all consecutive segments with the same
name. There are cases when a single, coherent street makes a hard turn at an
intersection. I can think of several, mostly state highways traveling
through the middle of a small town. So I don't support the idea that a hard
angle in a Way should split the way. But because I happen to know the answer
to your question and I like to look smart, here it is:
A and B are vectors.
A dot B = mag(A)*mag(B)*cos(theta)
(A dot B)/(mag(A)*mag(B)) = cos(theta)
cos-1( (A dot B)/(mag(A)*mag(B) ) = theta
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev