[Talk-ca] Question about NIDs

Sam Vekemans acrosscanadatrails at gmail.com
Wed Jan 21 20:26:52 GMT 2009

Hi all,Here's IMO, based on the last digest.
I tried to cover that with my video conference trial-run, and got stuck.

Lets look at the facts.
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?

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

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
  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.

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.

Re:  pieces of ways in a line

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.

OSM does NOT need to conform to GeoBase standards at all.  This is a one-way


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.

For future post-codes import;
The script would need to look up the relative coordinates, road name, road
type and add in this feature as a NODE.
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)

For future house-numbers
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.

For road names:
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.

Hope this makes sense,  (had to sleep on it) :-)

Sam Vekemans
Across Canada Trails
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20090121/e3f2a67a/attachment.html>

More information about the Talk-ca mailing list