Hi all,<div>Here's IMO, based on the last digest.</div><div>I tried to cover that with my video conference trial-run, and got stuck.</div><div><br></div><div>Lets look at the facts.</div><div>The RoadMatcher script AFAIK does NOT actually look at the NID when looking at existing OSM data and deciding on weather or not it should be added. ... is this true?</div>
<div><br></div><div>For updates, the road matcher script can be used, and looks at all the OSM data (imported & existing) and treats the existing AS IF if were OSM created. It only looks at its  coordinates, the osm roadtype & road name tags.</div>
<div><br></div><div>For situations where road matcher got flustered and didnt import the road, but should have.  This is why the origional import file is made available to use;</div><div>  We can load the GeobaseOrigional file, and compare it with existing data. ... just by having (in JOSM) both layers on, (with GeoBase as the shadded one) you can pan around the area your working on and right away see what needs to be added.   You then just select those items, then copy. .. then hide that layer, then paste on the osm layer. then upload changes.</div>
<div><br></div><div>So this has nothing todo with the NIDs.  ... NID's are only there for making that 1st conversion, when running the script to make the OSM file.  ... once it's and OSM file, it's the OSM tags that are relevant.</div>
<div><br></div><div>Re:  pieces of ways in a line</div><div><br></div><div>Because it's only the geobase ways that are not already in OSM that we are dealing with, it would be fine to be joining the ways as longer road segments.   ... this is conforming to OSM standards.</div>
<div><br></div><div>OSM does NOT need to conform to GeoBase standards at all.  This is a one-way import.</div><div><br></div><div>Conclusion:</div><div><br></div><div>For updates, because AFAICT the script looks at it's 1 - relative coordinates, 2 - road name and 3 -road type to see a match.   There is no way that it can create a new NID for existing ways, then compare that.  The would be illogical.</div>
<div><br></div><div>For future post-codes import;</div><div>The script would need to look up the relative coordinates, road name, road type and add in this feature as a NODE.</div><div>If the post-codes are available the as polygons, then GREAT the polygons would be able to be imported with no interference... the borders of the polygon would be boundary lines anyway (not roads)</div>
<div><br></div><div>For future house-numbers</div><div>The best way to deal with it, is to import it as nodes. .. and if the node doesnt line up with the road. .. no big deal... as long as it's tagged right, the search engine should be able to pick it up.</div>
<div><br></div><div>For road names:</div><div>I think that Roadmatcher would be able to pick it up, as people could be importing the roads (of Ontario) without names. ... but we EXPECT or HOPE that those who import data, ONLY import the roads that they intend on adding the NAME tag. .. so the script should have no problem looking at it, so where the road name was spelled differently.  The OSM version would Trump it.  ... no NID's would need to be added to OSM data.</div>
<div><br></div><div>Hope this makes sense,  (had to sleep on it) :-)</div><div><br></div><div>Cheers,</div><div>Sam Vekemans</div><div>Across Canada Trails</div><div><br></div>