[Talk-ca] Question about NIDs

Richard Degelder rtdegelder at gmail.com
Wed Jan 21 14:17:19 GMT 2009

On Wed, 2009-01-21 at 01:01 +0000, michcasa at gmail.com wrote:
> On Jan 20, 2009 12:48am, James Ewen <ve6srv at gmail.com> wrote:
> > On Mon, Jan 19, 2009 at 6:53 PM, Richard Degelder
> rtdegelder at gmail.com> wrote:
> > 
> > 
> > 
> > > Is there a process to include the NID, in an
> > 
> > > appropriate manner, with the import data that was derived from
> GeoBase?
> > 
> > 
> > 
> > In Steve's upload, we have a UUID with each element. I believe that
> is the NID.
> > 
> > 
> > 
> > geobase:uuid f722391f5b5d4eb1877a24fd69365ff8
> > 
> > 

Yes that should be the NID, it is 32 characters long.

> > 
> > > And has there been any considerations as to how to add the NID
> > 
> > > attributes to those ways already within OSM?
> > 
> > 
> > 
> > That, I'm not sure how to handle, especially when the OSM nodes and
> > 
> > ways won't match up with the GeoBase nodes and ways. How would you
> > 
> > match them when there may be 3 OSM nodes and only 2 GeoBase nodes,
> or
> > 
> > more likely 6 GeoBase ways making up a roadway that is defined by
> only
> > 
> > one OSM way.
> > 
> > 

Apparently the number of nodes within the OSM way and the GeoBase
Roadsegment do not have to match, or even be close to matching, in
numbers.  As long as the RoadMatcher application can determine that
there is enough similarities between the two sources, and they are
within a specific tolerance, then RoadMatcher will claim that they
represent the same roadway.

And Roadmatcher is also able to determine that multiple roadsegments
within GeoBase are being represented within a single way that covers the
same area.  RoadMatcher is, apparently, looking for where the ends of
the GeoBase roadsegment and OSM way align and counts it as a match.

> It is not a simple issue. I see 2 options: the first one is to align
> the osm geometry with the nrn-geobase geometry (or the opposite), then
> add the NIDs. At this stage, I wonder if we should take Geobase
> geometry and join the osm attributes. The second option is to use NIDs
> only for the nrn-geobase imported in osm.

For the two options you suggest we are going to have to in some manner
align the two data sets.  As for using only, or largely, the GeoBase
data and assigning the OSM attributes we are then going to be replacing
all of the user entered data and replacing it with GeoBase data.  Doing
this would go against one of the goals of trying to retain the user
generated data within OSM.  And even then we are going to have to find a
way to match the two data sets to be able to transfer the OSM

As for using the NIDs only on the GeoBase derived data it would make the
ideas of updating the map in the future impossible.  At that point
adding the NIDs to even the GeoBase derived import is a waste of time.

With the import of the GeoBase data for Fort McMurray Steve made each
GeoBase Roadsegment into a separate way.  So a street that had five
blocks, and so five separate NIDs, was entered onto the map as five
separate ways in OSM.  Is that what we want for the future?

This would make it imperative that the renderers are able to determine
that these separate ways should be presented as a single street rather
than attempting to present the street name on each section.  In most
cases the renderers do that very well but at a certain level of
magnification they start to break down and present each section with its
own name.  Another issue will be when someone attempts to combine these
short ways into a longer way to represent the entire roadway in one

The other option is to take the longer ways and have a relationship
attributed to the appropriate section which will have the NID.  This
would likely not be frequently disturbed by new editors to the map, but
the need for making this automatic in some way will make the script a
lot more complex.  And we are going to have to find a way to combine the
short ways generated by Steve's scripts into a longer way and that
represent the entire roadway.

Steve, with RoadMatcher, already is able to determine that a way, or
even a portion of an OSM way, matches a roadsegment from GeoBase.  At
this point the only question is how do we create the tag data for the

The real question, to some degree, is what do we do with the existing
data within OSM.  If we want to retain the user generated data and we
want to have one of the attributes to be the proper NID do we find a way
to create a script that will generate a relationship for that portion of
the way and then assign the NID as a tag for that relationship?  Or do
we create a script that will look for intersections and ends of roads
and breaks up ways in the same location as GeoBase already has?

Running a script that will divide up current OSM ways into sections that
match the GeoBase NID is not destroying user entered data.  It is a
modification, and it is being done with a script rather than a person,
but it is really not a lot different then someone modifying data that I
had originally entered.

The script could be as simple as looking for intersections and dividing
ways whenever it encounters one.  The end result would be a tremendous
number of ways within Canada, I would be curious as to how many
roadsegments are within GeoBase, and it would have to be rerun prior to
any updates from GeoBase being applied to OSM to catch new user entered
data, but it would match what GeoBase looks like.  Then running
RoadMatcher against the results and have the pertinent data from GeoBase
imported to the new OSM ways.

It is likely that breaking up longer ways into short ways is the
simplest solution but it will result in a very large number of ways that
will need to have all of the data replicated for all of them if a user
wants to add something like a bus route.  It will be convenient for the
manipulation of GeoBase based data but much more work for user
contributed data or updates.  If you want to add a feature to a roadway
you are going to have to do so for a lot of short ways that are being
effected by it as opposed to a long way, or a section of it.  The other
alternative is to get a better understanding of how to generate a script
that will create relationships within longer ways and retain the long
ways but still include the GeoBase NIDs for the appropriate sections

> Michel
> > 
> > 
> > 
> > James
> > 
> > VE6SRV
> > 
> > 

Richard Degelder

More information about the Talk-ca mailing list