[OSM-dev] Creating 3-d connected network from ways + layer tag
andrzej zaborowski
balrogg at gmail.com
Thu Jul 30 22:10:32 BST 2009
2009/7/30 Ben Supnik <bsupnik at xsquawkbox.net>:
> Hi Y'all,
>
> First: this discussion is a liiittle bit different from my original
> intention (not that that's a bad thing).
>
> I am trying to use the existing data and come up with a "best
> interpretation". Since I will use the entire planet file, manual
> correction of persistent problems is not a short-term viable option. :-(
>
> In particular, I expect both under-noding and over-noding.
>
> Over-noding: a node connects two ways that cross at different altitudes
> (as hinted by layer or bridge tags)...this happens in the TIGER imports
> (since TIGER is topologically integrated before export) so unless users
> have specifically fixed this, it'll be there...for every single overpass
> and bridge in the United states. :-)
>
> (Since Tiger doesn't include layer information I don't see how anyone
> could have automatically fixed this...without layers you can't know
> which nodes are "false".)
>
> Under-noding: I don't know how much existing software will fail to
> intersect two nodes...an artifact of my import is "fixing" all this
> (which gives me the over-noded case, although I could easily detect this
> by flagging nodes added by me at intersections).
That's easy to detects, just filter for created_by=Potlatch* and you
have the full list
(*hides*)
Seriously though one way to detect some of the over-noded cases is
where two ways in addition to the central connecting node have
apparent junction ways connecting the two ways. This would indicate
that they don't meet at the same level and the central node is bogus.
tunnel and bridge tags probably shouldn't be taken into account when
looking for the cases of over- and under-nodedness. I can also
imagine valid uses for a node connecting two ways with different
layer= values which is not at the end of either of the ways.
Cheers
More information about the dev
mailing list