Hi, Sorry about the late response on this, I'd been meaning to find time to exhaustively research what's going on here, but have been really busy with a cross country move and a long list of pressing commitments. Until I have time to look into this more closely (maybe in a week or so), I thought I'd quickly respond to this last message with what I do know on the slim chance that someone wants to pick up where I left off.
2009/7/1 Steve Singer <[email protected]>: >> 1. Intersection at spruce grove of two highways with dual carraigeways: >> >> >> http://www.openstreetmap.org/?lat=53.5578961&lon=-113.9100716&zoom=14&layers=B000FTF >> >> 8 duplicated nodes here. > > Are you seeing 8 duplicate nodes on the live OSM map? If so what are the > node id's. When I'm not sure which intersection your refering to. For > example http://www.openstreetmap.org/browse/way/31681540 is sharing nodes > with some of the connecting ways. (note that some of the ways in this area > are non geobase ways that don't yet connect to the geobase ones) No, this is on the generated OSM file that I created. Obviously people may have cleaned up the live OSM map after the fact. >> I've uploaded a full list of duplicated nodes for the Edmonton area, >> if anyone wants to see more evidence. :) It's just a raw list of >> lat/lng coordinates, prefixed with the number of duplicated nodes that >> geobase2osm is generating at that position. Check it out at: >> >> http://wlach.masalalabs.ca/edmonton-dupe-nodes > > For example the last one on the list > > 8 53.5578961, -113.9100716 > > When I search my version 5 Alberta NRN file I see 3 Geobase ways that have > a node at that location > > ba63f7ea50484da990858e0af964d867 > f6b43dd752e24cceb7eeebad5059888f > 0e3f0a6ddc2b4a6e8d5d754639570516 > > When I generate a clean .osm file with geobase2osm for the 083GH tiles each > of these ways shares a common node. What is the exact bounds file your > using in your test, perhaps there is a bug that only shows up with certain > inclusions/exclusions? Keep in mind that the .complete and file uploaded > from the original import was done with the version of geobase2osm that had > the merging bugs (but the data uploaded in OSM has since been fixed(as far > as I know )) That's very funny. I've uploaded the bounds file I've been using here: http://wlach.masalalabs.ca/edmonton-bounds.txt It's a square around Edmonton (corresponding to the bounds of the area served by public transit). I really can't see how it could be effecting the decisions that geobase2osm makes regarding merges. > In Alberta > fa0eaa9c6edd4f08aef6cc27e9f91ba4 and cf5c268bc5d4464cb485fc6d2aa71324 with > node (53.5411265,-113.3799206) is an example of a place where two streets > have a node at the same location but are not intersections according to the > geobase data. I think this an overpass so the where you can't really route > from one to the other. > > b777800e3e4747dfbf2a417259e3c176 at (53.5805167,-113.4528248) with > 6e24a4f112894569a18387fbc0777b3f is another. The ramp for the highway must > be going over the highway not joining it at the common node. > > >> Do we have consensus that it would be better to use my approach? If >> so, how do we go about updating the "official" script? > > I think we need to use the junction data include with geobase to decide when > to join nodes. It that the code isn't working right then we should fix it, > but I don't think we want to join all nodes that share the same point in > space. Yeah, that's definitely the way to go assuming there's not some sort of problem with the data that makes properly joining the nodes impossible. -- William Lachance [email protected] _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
