Thanks,<br>I also got 2 comments about the french name tagging, so i added it to the <a href="http://wiki.openstreetmap.org/wiki/Talk:GeoBase_Import">http://wiki.openstreetmap.org/wiki/Talk:GeoBase_Import</a> page.<br>And tried my best to translate this talk about PostGIS. :)<br>
Please edit, if you can :)<br><br>The part about the stressing the importance of not undermining OSM contributions, needs to be highlighted more.  IMO<br><br>and<br>"Even if there is a single road<br>
through an area there has to be a way to for us to match it within both<br>
OSM and GeoBase.  "<br>By using the charts we already started, and the name tags... we can create the set of rules that the PostGIS database import script will follow.   GeoBase Tag = OSM tag. .. and get as detailed as possable.<br>
<br>The realtime aspect (my last point on the talk) is still a little vague.<br><br>Cheers,<br>Sam<br><br><div class="gmail_quote">On Fri, Dec 5, 2008 at 10:11 AM, Richard Degelder <span dir="ltr"><<a href="mailto:rtdegelder@gmail.com">rtdegelder@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Fri, 2008-12-05 at 03:06 -0800, Sam Vekemans wrote:<br>
> I forgot to send it direct to you too. talk-ca takes a little longer<br>
> to send.<br>
><br>
><br>
</div>Thanks.  I am starting to check the talk-ca site regularly anyways so I<br>
am seeing a lot of the discussion as it comes up.  I like the digest and<br>
use it to reduce the amount of traffic that I get.  But sending me an<br>
e-mail directly is appreciated.<br>
<div class="Ih2E3d"><br>
<br>
><br>
> So from your idea i got:<br>
> 1. Merging the OSM reference id# database (our big Canada file) with<br>
> the GeoBase dataset onto a separate PostGIS database.<br>
<br>
</div>Correct.  We find where there are common elements within both data sets,<br>
such as a street, and have a way of transferring the the reference id#<br>
from the one to the other.  A database would probably be an ideal way to<br>
do this.<br>
<div class="Ih2E3d"><br>
> 2. Purging the results of close lines/nodes. (street names maybe?) ...<br>
> creating a GeoBase/OSM database. Where it just looks for that, and<br>
> removes the extra OSM stuff that it doesnt need.<br>
<br>
</div>Not exactly.  I would not really touch the OSM map, as far as the<br>
renderers see it, at all at this point.  The purpose of the database is,<br>
on the one hand, to eliminate redundant data from entering OSM but is<br>
also useful, at the same time, for adding additional metadata, in this<br>
case the GeoBase id#, into the metadata for OSM.<br>
<div class="Ih2E3d"><br>
> 3. Then importing it back to OSM.  .. purging it with the original OSM<br>
> Id's.<br>
<br>
</div>Once we have the database showing the GeoBase data that already exists<br>
within OSM, such as the existence of a particular street, two things<br>
happen.  First the metadata, such as the GeoBase id# is given to that<br>
street or that way.  This will ensure that from that point on it is<br>
identifiable as having been in the GeoBase data and any subsequent<br>
updates to that GeoBase data that effects the particular street or way<br>
will know that it should also effect it within the OSM data.  This also<br>
allows for the addition of more data, such as street address data, when<br>
it becomes available for the area.  In essence any subsequent update<br>
from GeoBase will believe that the street that was originally within OSM<br>
really came from the GeoBase import.<br>
<br>
At the same time the database will be used during the import of the<br>
GeoBase data.  It would work in that any street or feature within the<br>
GeoBase data that has a matching item within the database, and so<br>
already exists within OSM, will not be imported into OSM as part of the<br>
GeoBase data import.  At the same time any feature within the GeoBase<br>
data that does not match anything within OSM would be imported.<br>
<br>
As long as the matching process is efficient then there is no need for<br>
eliminating any area from the GeoBase import.  Although there are likely<br>
going to be issues where something that is thought not to match, but<br>
actually does for some reason, gets imported it hopefully will be rare.<br>
<br>
The results of this effort would be to allow for the full GeoBase data<br>
set to be represented within OSM while not overwriting the contributions<br>
of those that have already entered data into OSM and to add the<br>
metadata, particularly the id# from the Geobase data, to allow us to<br>
update OSM as the GeoBase data is updated and extended.<br>
<div class="Ih2E3d"><br>
> Am i following that right?<br>
><br>
><br>
> Cheers,<br>
> Sam<br>
<br>
</div>We have to consider that except where there is absolutely no data within<br>
OSM for an area there are going to be some conflicts between the GeoBase<br>
data and that already within OSM.  Even if there is a single road<br>
through an area there has to be a way to for us to match it within both<br>
OSM and GeoBase.  And I also believe that the content that already<br>
exists within OSM is important and should not be replaced by GeoBase<br>
data only for convenience sake and for expediency in importing the<br>
GeoBase data.<br>
<br>
Doing it for any road in an area is really not going to be any more<br>
complex whither it is an isolated road in the middle of nowhere or a<br>
residential street in the middle of Toronto or Montreal.<br>
<br>
</blockquote></div><br>