2008/12/5 Sam Vekemans <[EMAIL PROTECTED]> > Thanks, > I also got 2 comments about the french name tagging, so i added it to the > http://wiki.openstreetmap.org/wiki/Talk:GeoBase_Import page. > And tried my best to translate this talk about PostGIS. :) > Please edit, if you can :) > > The part about the stressing the importance of not undermining OSM > contributions, needs to be highlighted more. IMO > > and > "Even if there is a single road > through an area there has to be a way to for us to match it within both > OSM and GeoBase. " > 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.
The first rule is to keep OSM ways, but the rule should not become a dogma. For example, the Geobase roads meets 5 meters accuracy at 90% CMAS. What do we do if the discrepancy is bigger than 10 meters between the 2 sources ? Or if the representation is on line in OSM versus 2 lines in Geobase ? The ultimum goal of collaborative mapping is to improve the the final product. > > > The realtime aspect (my last point on the talk) is still a little vague. > > Cheers, > Sam > > On Fri, Dec 5, 2008 at 10:11 AM, Richard Degelder <[EMAIL PROTECTED]>wrote: > >> On Fri, 2008-12-05 at 03:06 -0800, Sam Vekemans wrote: >> > I forgot to send it direct to you too. talk-ca takes a little longer >> > to send. >> > >> > >> Thanks. I am starting to check the talk-ca site regularly anyways so I >> am seeing a lot of the discussion as it comes up. I like the digest and >> use it to reduce the amount of traffic that I get. But sending me an >> e-mail directly is appreciated. >> >> >> > >> > So from your idea i got: >> > 1. Merging the OSM reference id# database (our big Canada file) with >> > the GeoBase dataset onto a separate PostGIS database. >> >> Correct. We find where there are common elements within both data sets, >> such as a street, and have a way of transferring the the reference id# >> from the one to the other. A database would probably be an ideal way to >> do this. >> >> > 2. Purging the results of close lines/nodes. (street names maybe?) ... >> > creating a GeoBase/OSM database. Where it just looks for that, and >> > removes the extra OSM stuff that it doesnt need. >> >> Not exactly. I would not really touch the OSM map, as far as the >> renderers see it, at all at this point. The purpose of the database is, >> on the one hand, to eliminate redundant data from entering OSM but is >> also useful, at the same time, for adding additional metadata, in this >> case the GeoBase id#, into the metadata for OSM. >> >> > 3. Then importing it back to OSM. .. purging it with the original OSM >> > Id's. >> >> Once we have the database showing the GeoBase data that already exists >> within OSM, such as the existence of a particular street, two things >> happen. First the metadata, such as the GeoBase id# is given to that >> street or that way. This will ensure that from that point on it is >> identifiable as having been in the GeoBase data and any subsequent >> updates to that GeoBase data that effects the particular street or way >> will know that it should also effect it within the OSM data. This also >> allows for the addition of more data, such as street address data, when >> it becomes available for the area. In essence any subsequent update >> from GeoBase will believe that the street that was originally within OSM >> really came from the GeoBase import. >> >> At the same time the database will be used during the import of the >> GeoBase data. It would work in that any street or feature within the >> GeoBase data that has a matching item within the database, and so >> already exists within OSM, will not be imported into OSM as part of the >> GeoBase data import. At the same time any feature within the GeoBase >> data that does not match anything within OSM would be imported. >> >> As long as the matching process is efficient then there is no need for >> eliminating any area from the GeoBase import. Although there are likely >> going to be issues where something that is thought not to match, but >> actually does for some reason, gets imported it hopefully will be rare. >> >> The results of this effort would be to allow for the full GeoBase data >> set to be represented within OSM while not overwriting the contributions >> of those that have already entered data into OSM and to add the >> metadata, particularly the id# from the Geobase data, to allow us to >> update OSM as the GeoBase data is updated and extended. >> >> > Am i following that right? >> > >> > >> > Cheers, >> > Sam >> >> We have to consider that except where there is absolutely no data within >> OSM for an area there are going to be some conflicts between the GeoBase >> data and that already within OSM. Even if there is a single road >> through an area there has to be a way to for us to match it within both >> OSM and GeoBase. And I also believe that the content that already >> exists within OSM is important and should not be replaced by GeoBase >> data only for convenience sake and for expediency in importing the >> GeoBase data. >> >> Doing it for any road in an area is really not going to be any more >> complex whither it is an isolated road in the middle of nowhere or a >> residential street in the middle of Toronto or Montreal. >> >> > > _______________________________________________ > Talk-ca mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-ca > >
_______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
