Re: [Talk-ca] GeoBase and OpenStreetMap
On Wed, 2008-12-17 at 00:26 -0800, Dan Putler wrote: One way has the TIGER TLID attribute, the other way does not (the person doing the editing of the way missing the TLID probably didn't understand the relevance of it, and didn't think it mattered). There are several concerns here. First, as you pointed out, is that we have virtually no control over what other users in OSM do. There are no access controls or integrity constraints beyond some very simple ones. If we decided to strongly preserve the tiger TLIDs (or their GeoBase equivalent), I'm not even sure it would be possible without some serious changes to how OSM works. Moreover, in looking through the data in this area, I determined that a _large_ number of ways cover multiple block faces (so can't have a single TLID). Yes, virtually all TIGER objects represented as a single TLID were merged into larger ways in the OSM import. In these cases, the only way I can see to attach the TLIDs back on to them is to import them into GRASS, clean and break the ways at intersections, and then attempt to match them back to the original TIGER data using a combination of street name, proximity, and bearing. It can likely be done to an acceptable level of precision, but what a pain! If you have the tools to deal with these issues already, and do so on a regular basis, my concerns are misplaced. If not, then they are legitimate concerns. Oh, I don't have the tools to do it. I haven't had the need to write them. If you really want to track the GeoBase ways after they are imported, what about looking at the planet diffs? You could keep a record of what happened to each object as it gets modified by users. There would be no need to match up data because you would know how each piece got there. -- Dave ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase and OpenStreetMap
On Wed, 17 Dec 2008, Dave Hansen wrote: There are several concerns here. First, as you pointed out, is that we have virtually no control over what other users in OSM do. There are no access controls or integrity constraints beyond some very simple ones. If we decided to strongly preserve the tiger TLIDs (or their GeoBase equivalent), I'm not even sure it would be possible without some serious changes to how OSM works. You could have a monitoring script that looked at diffs and tried to detect some of these things and emailed out alerts. The community could then fix (and educate users) as they happen. If you really want to track the GeoBase ways after they are imported, what about looking at the planet diffs? You could keep a record of what happened to each object as it gets modified by users. There would be no need to match up data because you would know how each piece got there. What about using relations to store store the geobase id. Tag each node in geobase segment way with a relation that contains the geobase id. That way you can have multiple geobase segments map to a single OSM way. -- Dave Steve ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase and OpenStreetMap
Dave Hansen wrote: The basic reason is that we need to be able to edit it. We can't simply put data back into GeoBase, so we need a copy on which to work. Is there a way we even could get changes back to the owners of the data? This is a key question and worth exploring in depth. An off the cuff answer is that sometimes the owners will accept changes and sometimes not. As Mike outlined earlier, Geobase is a collection of data from various entities and thus sending updates back upstream will work (or not) differently depending who the provider is. Most of the data providers I work with are interested in feedback on their stuff (though sometimes it takes a fair bit of detective work to learn how to get that feedback to the right persons!). For OSM, I would probably start with the approach of learning who the closest to source provider is for data X, and submit bug reports and patches to them. Dear Office of Roads Trails, I was recently biking 'Beaten Path' and discovered there is a washout at 131.32°W, 62.24°N, which looks a few years old, with a well travelled detour via 'Off The'. This was a bit of surprise as I was using your Hikes Bikes Mapset and the half hour detour is not marked. The attached shapefile contains the detour captured with my XYZ GPS unit, with attributes and metadata conforming to your standards as seen on the Office of Roads Trails ftp site. Sincerely, Oscar Steward Mapper A few iterations of this kind may eventually lead to a formal update mechanism. This paints a pretty rosy picture; there are generous and kindly people I know with GPS units whose data I would not accept as their enthusiasm outstrips their skill. Some filtering and verification is needed, but I'm confident that can be addressed if there is a will to do so. cheers, matt wilkie Geographic Information, Information Management and Technology, Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] GeoBase and OpenStreetMap
Before I get on with my comments let me introduce myself to the group. My name is Mike Mepham and I am a member of the GeoBase Steering Committee. In fact, I was in on the founding of GeoBase in 2000/2001 and have been active with it ever since. I have 19+ years with Saskatchewan's geomatics agencies and am currently on secondment to the federal government tasked with helping to continue and enhance the cooperative geomatics programs between the 14 governments in Canada (federal, 10 provincial, and 3 territorial). A couple of things I am not - I am not an employee of the Government of Canada although they provide me with my work facilities. I am still employed by one of the provincial governments. Also I am not the technical go to guy. I have two objectives with this note - The first is to clarify exactly what GeoBase is and is not. Hopefully I can help clear up some of the confusion I have noticed in some in the postings to this discussion group. The second is to enter into a discussion about what this group is trying to do, why, and how we can work together or at least not get in each others way. What is GeoBase? GeoBase is a collaborative partnership of the federal, provincial, and territorial governments working to wards a vision of Fundamental geographic data of choice for Canada - collected once, maintained and available without restrictions. The idea is to ensure that any data collection only takes place once and the results shared. Also, every effort is made to ensure that the agency responsible for the content of the mapping is the agency that is closest to the items being mapped. For example, many of the municipal roads in GeoBase are mapped by the municipality itself who provide the data to the province who add it to the provincial roads mapped by their department of transportation and then the whole is submitted to GeoBase for inclusion in the portal. So please do not refer to GeoBase data as federal data. While some of it is federally sourced most of it is municipally, territorially, or provincially sourced and made available through the collaborative partnership. There are several attributes (not data base attributes) that the data must have to be included in GeoBase. These include that it is expected to be authoritative, maintained, freely available, etc. For full details on this and more on how the partnership works I strongly recommend reading the GeoBase Principles, Policies, and Procedures http://www.geobase.ca/doc/GeoBase-ppp-v1_5_en.pdf (PPP) document. It will give you a better understanding of the animal you are dealing with. Some Questions Let me start by making it clear that I am asking these questions to help my understanding. Nothing here is intended to stop, or delay the groups progress in loading the GeoBase information into the OSM. My first question has to be Why are you doing this?. I have spent some time looking through the OSM web site and I understand the rational for building street maps where none exist or at least are not generally available but that is not the case here. I know of at least two other complete downloads of the GeoBase data for redistribution but still do not fully understand the reasons for replication / duplication. Secondly - How does this group expect maintenance to work? When the data suppliers pass updates to the GeoBase portal team and those updates are made available then GeoBase and OSM will be out of sync. What are the expectations on how or when they will be brought back into sync? And finally, for now, Are there any comments or questions you would like to direct to the GeoBase Steering Committee? We don't always hear back from those who are using the GeoBase portal and it's data but want to. Please speak up if you have something to say to us. In closing I would like to suggest that you also check out the video at YouTube that shows some of the research we have been involved with looking at interoperability of diverse geomatics data bases. The video is at http://www.youtube.com/watch?v=YIZLc_qHYZc in English and http://www.youtube.com/watch?v=BXvUqWVtjQo in French. Thanks for your time. Mike Mepham Federal/Provincial/Territorial Liaison GeoConnections Program Natural Resources Canada E-Mail: mmep...@nrcan.gc.ca mailto:mmep...@nrcan.gc.ca Ottawa Regina Phone: (613) 992-8549 (306) 780-3634 Fax: (613) 947-2410 (306) 780-5191 Address: 06Ath Floor, Room. 646R 615 Booth Street Ottawa, ON Canada K1A 0E9 100 Central Park Place 2208 Scarth Street Regina, SK Canada S4P 2J6 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase and OpenStreetMap - welcome
Hi, 1st off, thanks for joining in the group, i'm sure your help will be most valuable. I'll need a little bit (a couple days) to go over each of your points with a more formal response. The only thing I didn't see is the relationship with the CanVec data, (that I am currently exploring), making a chart showing the relation from this dataset to how we look at it in OpenStreetMap. .. matching the labels, with OpenStreetMap tags. For the import program to use. For now, thats my biggest question, as road and Hydro Topo data are also available CanVec. The question/issue raised was about update frequency. Which one do we focus on? What is the other complete download of geobase data? I know that 1 of them from for the Ibycus topo. My guess would be OSGeo? And for dealing with updates? We are planning on making a program which is able to detect current points in the OSM database, which have the the same attributes, and place the GeoBase (NRCan) ID onto it, and where no OSM data exists, place this new GeoBase data onto it. (to talk-ca list: .. similar to how the renderer has a list of common elements which the program knows how to read (and then creates the maptile), the rest it avoids, or makes a note that there is an error and fills out a big report) Our biggest assumption would be that the NRCan ID that is placed on the data would not change, so that when more attributes are available ie. house numbers, these attributes can be added onto the OSM database, provided it doest aleady exist. So the program could essentially be run several times over, grabbing different datafiles, going through the whole list of NRCan to OSM common elements. (this way, different elements can be added at different times) ... so only when when people are ready to work with it. As there will be some manual adjusting, as tagging from both sides wont be perfect, and so this program will be updated as people find errors. (ps. a timestamp, the date the NRCan data was added would be on of the tags that the program would look at too, and perhaps the date of the original source also. As this is a good point of reference) Does this make sense? I know that it's technically possible to make such a program, it's just a matter of finding the right people out there who can make it work. :) I will get back to you after i had a chance to go over your message in further detail, so to answer all your questions. I'm sure others might also respond too. (as this is an open discussion group). Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase and OpenStreetMap
Hi Mike, Like you, I'm new to this list. I'm actually a member of the PAGC project steering committee. PAGC (www.pagcgeo.org) is an open source postal address geocoder. While doing this work we have found that a major challenge is publicly available road network data. Historically, we have been more focused on the Statistics Canada RNFs (and the US TIGER data) since they were publicly earlier, and had address range data and street names that allowed for interpolation based geocoding. As I'm sure you know, in the current NRN only road segments in Alberta, Nova Scotia, and the Yukon have street names _and_ address ranges, and BC road segments have street names but no address ranges. In addition these four jurisdictions have local area identifiers (municipality in the case of the NRN, as opposed to the US five digit Zip code in TIGER) for the road segments, which is not present in the StatsCan RNFs). My real interest is whether or not all the provinces and territories will eventually have street names, address ranges, and local area identifiers, and if the answer is yes, whether there is any sort of time line in terms of the release of this information? As things currently stand at this moment, if you are working with Alberta, Nova Scotia, and the Yukon, the NRN is the right choice; in BC whether you use the NRN or the StatsCan RNF data is a tough call; and for any other province or territory you probably want to use the StatsCan RNF. The other thing that may be useful for you to know is that this effort is likely to have been coloured by the experience of uploading the US TIGER data into OSM. TIGER data has real positional accuracy issues, and people have done a lot of work re-doing the road segments. Unfortunately, in doing this, most people who are mapping have made no effort to maintain any of the TIGER attributes (keeping the TLID would have been really useful). Moreover, many of the attributes (like the address ranges and Zip code information) were never included in the original upload of the data. In addition, the ways (road segments) that people have created in OSM often contain multiple block faces. As a result, the OSM data has lost valuable attribute information that was contained in the original TIGER data (fixing this problem is something we are exploring, but will not be easy), and it would be unfortunate if the same thing happened in the upload of NRN data into OSM. Dan On Thu, 2008-12-11 at 15:02 -0500, Mepham, Michael wrote: Before I get on with my comments let me introduce myself to the group. My name is Mike Mepham and I am a member of the GeoBase Steering Committee. In fact, I was in on the founding of GeoBase in 2000/2001 and have been active with it ever since. I have 19+ years with Saskatchewan’s geomatics agencies and am currently on secondment to the federal government tasked with helping to continue and enhance the cooperative geomatics programs between the 14 governments in Canada (federal, 10 provincial, and 3 territorial). A couple of things I am not – I am not an employee of the Government of Canada although they provide me with my work facilities. I am still employed by one of the provincial governments. Also I am not the technical go to guy. I have two objectives with this note – The first is to clarify exactly what GeoBase is and is not. Hopefully I can help clear up some of the confusion I have noticed in some in the postings to this discussion group. The second is to enter into a discussion about what this group is trying to do, why, and how we can work together or at least not get in each others way. What is GeoBase? GeoBase is a collaborative partnership of the federal, provincial, and territorial governments working to wards a vision of “Fundamental geographic data of choice for Canada – collected once, maintained and available without restrictions”. The idea is to ensure that any data collection only takes place once and the results shared. Also, every effort is made to ensure that the agency responsible for the content of the mapping is the agency that is “closest” to the items being mapped. For example, many of the municipal roads in GeoBase are mapped by the municipality itself who provide the data to the province who add it to the provincial roads mapped by their department of transportation and then the whole is submitted to GeoBase for inclusion in the portal. So please do not refer to GeoBase data as federal data. While some of it is federally sourced most of it is municipally, territorially, or provincially sourced and made available through the collaborative partnership. There are several attributes (not data base attributes) that the data must have to be included in GeoBase. These include that it is expected to be authoritative, maintained, freely available, etc. For full details on this and more on how the partnership works I strongly recommend reading the GeoBase Principles, Policies, and
Re: [Talk-ca] GeoBase and OpenStreetMap - welcome
On the CanVec question - The CanVec road network data is or will be identical to the GeoBase data. Right now CanVec is identical to GeoBase but prior to some of the GeoBase updates. The data flow is provinces to GeoBase to CanVec with processing / scheduling delays along the line. CanVec is updated every 6 months or so and given processing times could be as much as 12 months behind GeoBase. The other difference to note is that the GeoBase data is continuous while the CanVec data is cut at the sheet edges. The CanVec data carries the GeoBase unique identifier on the road segments. When a segment is split at the sheet edge both pieces will carry the same GeoBase identifier so if you choose to use the CanVec data you might want to plan on merging segments with common GeoBase identifiers. (There is also a CanVec identifier which is unique to each segment piece so be careful about which you use.) A personal thought - Perhaps you could extract the list of GeoBase identifiers from a CanVec data set and then use that to select the GeoBase segment to add. It should be possible to deal with the duplicates fairly easily. The main issue would be what to do with any GeoBase segments left behind (these would be updates that have not made it to CanVec yet.) Similarly the GeoBase hydro data currently in production will replace the CanVec data once it is complete and the updates will be to GeoBase first, then promulgated through to CanVec. This is the intention with future GeoBase themes as well, as they are added. On the ID question - The ID on the GeoBase objects is a permanent ID. Attribute changes and positional updates (e.g. street re-alignments) will not cause the ID to change. Mike Mepham Federal/Provincial/Territorial Liaison GeoConnections Program Natural Resources Canada E-Mail: mmep...@nrcan.gc.ca Ottawa Regina Phone: (613) 992-8549 (306) 780-3634 Fax: (613) 947-2410 (306) 780-5191 Address: 06Ath Floor, Room. 646R 615 Booth Street Ottawa, ON Canada K1A 0E9 100 Central Park Place 2208 Scarth Street Regina, SK Canada S4P 2J6 From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: December 15, 2008 04:12 To: Mepham, Michael Cc: talk-ca@openstreetmap.org Subject: re: GeoBase and OpenStreetMap - welcome Hi, 1st off, thanks for joining in the group, i'm sure your help will be most valuable. I'll need a little bit (a couple days) to go over each of your points with a more formal response. The only thing I didn't see is the relationship with the CanVec data, (that I am currently exploring), making a chart showing the relation from this dataset to how we look at it in OpenStreetMap. .. matching the labels, with OpenStreetMap tags. For the import program to use. For now, thats my biggest question, as road and Hydro Topo data are also available CanVec. The question/issue raised was about update frequency. Which one do we focus on? What is the other complete download of geobase data? I know that 1 of them from for the Ibycus topo. My guess would be OSGeo? And for dealing with updates? We are planning on making a program which is able to detect current points in the OSM database, which have the the same attributes, and place the GeoBase (NRCan) ID onto it, and where no OSM data exists, place this new GeoBase data onto it. (to talk-ca list: .. similar to how the renderer has a list of common elements which the program knows how to read (and then creates the maptile), the rest it avoids, or makes a note that there is an error and fills out a big report) Our biggest assumption would be that the NRCan ID that is placed on the data would not change, so that when more attributes are available ie. house numbers, these attributes can be added onto the OSM database, provided it doest aleady exist. So the program could essentially be run several times over, grabbing different datafiles, going through the whole list of NRCan to OSM common elements. (this way, different elements can be added at different times) ... so only when when people are ready to work with it. As there will be some manual adjusting, as tagging from both sides wont be perfect, and so this program will be updated as people find errors. (ps. a timestamp, the date the NRCan data was added would be on of the tags that the program would look at too, and perhaps the date of the original source also. As this is a good point of reference) Does this make sense? I know that it's technically possible to make such a program, it's just a matter of finding the right people out there who can make it work. :) I will get back to you after i had a chance to go over your message in further detail, so to answer all your questions. I'm sure others might also respond too. (as this is an open discussion group). Sam Vekemans Across Canada Trails
Re: [Talk-ca] GeoBase and OpenStreetMap
On Thu, 2008-12-11 at 15:02 -0500, Mepham, Michael wrote: My first question has to be “Why are you doing this?”. I have spent some time looking through the OSM web site and I understand the rational for building street maps where none exist or at least are not generally available but that is not the case here. I know of at least two other complete downloads of the GeoBase data for redistribution but still do not fully understand the reasons for replication / duplication. The basic reason is that we need to be able to edit it. We can't simply put data back into GeoBase, so we need a copy on which to work. Is there a way we even could get changes back to the owners of the data? I think the core of it is that OpenStreetmap isn't your normal user. We don't want to just take the data and put it on a map, or figure out where all the residents in an area live. One of our core goals is to be able to update and change the map. Secondly – How does this group expect maintenance to work? When the data suppliers pass updates to the GeoBase portal team and those updates are made available then GeoBase and OSM will be out of sync. What are the expectations on how or when they will be brought back into sync? For the US TIGER data, we are simply diverging. There is no plan that I know of, and relatively little need right now, to bring things back into sync. It is just a huge problem with no easy solutions. The easiest solution that I see is what we're doing now: leave the data, and let the users improve it, just like the rest of the world. These huge government databases have, in effect, been a jump start for OSM. But, I'm afraid they're a one-time thing. -- Dave ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase and OpenStreetMap
Hi Dave, There is one important difference between the Canada NRN and the US TIGER data. Specifically, the locational accuracy for the NRN is much better than is the case with TIGER. As a result, the need to undertake a big effort editing ways to fix their locational accuracy isn't going to be nearly as critical (put another way, what do you trust more, someone's Garmin eTrex or the provincial highway department's Trimble differential gps unit?). As a result, the potential loss of information from forking the data is relatively more important for the Canada NRN then the US TIGER data. In my opinion the current US situation is unfortunate. As a data user you have the choice of one publicly available road network that is very good with respect to locational accuracy (OSM), and another that has much poorer locational accuracy but has address range and local area identifier information (TIGER) which allows it to be used in geocoding and certain types of routing applications (although, its locational accuracy is a problem for this). If the TIGER TILD's had been maintained on the OSM ways life would be a lot easier for a lot of potential users of the OSM data. My two cents. Dan On Mon, 2008-12-15 at 14:32 -0800, Dave Hansen wrote: On Thu, 2008-12-11 at 15:02 -0500, Mepham, Michael wrote: My first question has to be “Why are you doing this?”. I have spent some time looking through the OSM web site and I understand the rational for building street maps where none exist or at least are not generally available but that is not the case here. I know of at least two other complete downloads of the GeoBase data for redistribution but still do not fully understand the reasons for replication / duplication. The basic reason is that we need to be able to edit it. We can't simply put data back into GeoBase, so we need a copy on which to work. Is there a way we even could get changes back to the owners of the data? I think the core of it is that OpenStreetmap isn't your normal user. We don't want to just take the data and put it on a map, or figure out where all the residents in an area live. One of our core goals is to be able to update and change the map. Secondly – How does this group expect maintenance to work? When the data suppliers pass updates to the GeoBase portal team and those updates are made available then GeoBase and OSM will be out of sync. What are the expectations on how or when they will be brought back into sync? For the US TIGER data, we are simply diverging. There is no plan that I know of, and relatively little need right now, to bring things back into sync. It is just a huge problem with no easy solutions. The easiest solution that I see is what we're doing now: leave the data, and let the users improve it, just like the rest of the world. These huge government databases have, in effect, been a jump start for OSM. But, I'm afraid they're a one-time thing. -- Dave ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Dan Putler Sauder School of Business University of British Columbia ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase PostGIS OpenStreetMap
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 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 Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
