[Talk-ca] GeoBase PostGIS & OpenStreetMap

[Michel Gilbert]

2008/12/5 Sam Vekemans <acrosscanadatrails at gmail.com>

> 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 <rtdegelder at gmail.com>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
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20081205/23d08af0/attachment.html>