Re: [Talk-ca] Canadian imports: good or bad?
On Wed, 25 Apr 2012, Bégin, Daniel wrote: Steve, Paul, I was on the impression that the consensus was more about using Canvec where it is the best available source and, when it is not, the data could be imported, but only after an exhaustive verification using available data/imagery. 'best available source' as a standard has appeal to me, and I think this varies by layer (ie your comments in the other email about older hydrography) I think often people are importing all of the layers at once when without evaluating what they are importing. Whatever is the consensus, it should be documented in the wiki. Agreed. I think right now we have consensus on saying: * The osm-ca community wants to import Canvec data * The imports should be done carefully to avoid duplicating objects * Coastlines and large lakes should only be imported by experienced users (which is basically what the wiki already says) Paul proposed two additional guidelines here: http://lists.openstreetmap.org/pipermail/talk-ca/2012-April/004721.html "1. The buildings data from CanVec should not be imported unless it can be verified against imagery, in which case you might as well trace the buildings from imagery." Ie if the imagery (and there is no other source like a local mapper) isn't good enough to verify the buildings then don't import them. It seems, to me, that so many of the 20+ year old building data is no longer valid that we might want to discourage the use of this layer without Do we have consensus on this point? "2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery." I like the sentiment but I don't like the 'negative wording' it doesn't tell people what we DO have consensus on, so it doesn't tell them what they can import. Nor does it explicitly prevent any sort of import. My wording from this morning apparently wasn't good either. How about * When importing Canvec data you should verify that the data you are importing is consistent with other data. For example check that forests aren't sitting in lakes. Sometimes the different Canvec layers are not consistent because the data comes from different sources. You should try to fix consistency issues as you import data. (anyone should feel free to propose some better wording) Is there something we can say in the guidelines to help people judge accuracy? (In most of the areas I map I've found the Canvec data lines up VERY well with Bing and my GPS traces) Steve Furthermore, I think that "internal consistency/accuracy/existence" should be defined... consistency: ? Accuracy: Bing imageries in urban areas are pretty good and easy to correct, if necessary, using available GPS tracks. It is not the case outside these areas. I suspect that Bing imageries are not always corrected using a good digital elevation model. It means that in hilly areas, the image shows an object somewhere on the ground while the object is actually somewhere else, due to Z distortion. Existence: Again, outside urban areas, the resolution of Bing imageries doesn't allow for detailed validation. You won't be able to see small objects, even if they are there! Best regards, Daniel -Original Message- From: Steve Singer [mailto:st...@ssinger.info] Sent: April 25, 2012 07:12 To: Paul Norman Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On Wed, 25 Apr 2012, Paul Norman wrote: 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. If no one disagrees with the fact there is not a consensus that importing CanVec without minimal verification is acceptable I'll go ahead and document on the Wiki, using Andrew Allison's examples. +1. Is there enough support to use the positive rather than the negative language, ie 'There is consensus among the community that Canvec data should only be imported when the data elements have been verified for internal consistency/accuracy/existence with the available imagery' Steve ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] FW: [Talk-us] City boundaries on the Canada/US border
Whoops - forgot to include talk-ca@ in this -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: Wednesday, April 25, 2012 1:50 PM To: 'Toby Murray'; talk...@openstreetmap.org Subject: Re: [Talk-us] City boundaries on the Canada/US border I started working my way across and the cleanup is progressing. I'm up to monument 31 so far. Once I get out of populated areas it should go quicker. The monuments are physically present on the ground, so their location could be improved by more accurate surveys. However, I doubt if any consumer GPS would be more accurate. The points agree with multiple sources of accurate imagery within the resolution of the imagery. I settled on ibc:ref for the turning points which don't have a survey_point on the ground. Those refs help me keep track of where I am. Starting in the water and going east, the border is now Delta-Whatcom County Surrey-Whatcom County White Rock-Whatcom County Surrey-Whatcom County Surrey-Blaine Langley-Blaine Langley-Whatcom County Abbotsford-Whatcom County Abbotsford-Sumas > -Original Message- > From: Toby Murray [mailto:toby.mur...@gmail.com] > Sent: Friday, March 30, 2012 7:51 AM > To: talk...@openstreetmap.org > Subject: Re: [Talk-us] City boundaries on the Canada/US border > > On Fri, Mar 30, 2012 at 7:18 AM, Alexander Roalter > wrote: > > Am 30.03.2012 11:17, schrieb Paul Norman: > > > >> There are a significant number of cities in BC and Washington which > >> have borders that in practice[1] coincide with the Canada/US border. > >> Currently in OSM these are represented with many nearly-overlapping > >> ways. > >> > >> The Canada/US border here consists of the BC-WA border, BC-ID > >> border, BC-MT border, AB-MT border, SK-MT border, SK-ND border, > >> etc. There are separate ways for the cities on the Canada side and > >> cities on the US side. > >> > > ... > > > >> > >> This would reduce the number of ways present when you download a > >> section of the border and have many advantages. The one big > >> disadvantage is that it would boost the number of ways in the > >> Canada and US relations. This increases the chance of conflicts and > >> also increases the number of places it could be broken. > > > > > > I merged the us/canadian border with the north dakota, minnesota and > montana > > state borders and also county borders a while ago, and I agree that > there > > should only be one way for one part of the border, this line being > shared in > > all affected boundary relations. > > I don't really think this will increase conflicts, as if you delete > one way > > of a border, all affected relations will be notified (at least in > > JOSM > it's > > impossible to download a way without downloading all relations this > way is > > connected. > > > > I did include city boundaries where available, but this was the case > only on > > one city (Emerson, MB). In Europe, nearly all borders are made up of > > individual municipality border stretches (I once loaded italy's > > circumference, made up of >2500 ways). > > The problem with conflicts is if someone is splitting ways that are > members of the US border relation down in Arizona while you are doing > the same up in Washington. But in general I don't think this will be a > huge problem. Much of the US border is either in water or sparsely > populated areas where frequent edits are unlikely. > > I've done some splitting of ways for counties along both the north and > south border so I think this would be fine too. Overlapping ways are a > pain to deal with. Then again relations can be a pain too :) But at > least they are cleaner. > > Toby > > ___ > Talk-us mailing list > talk...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
Haaa! It makes sense... Originally, hydrography and vegetation were fitting together. Now that we are gradually replacing the older hydrography with newer data from provinces, we find vegetation in water. It will be corrected when we will replace the vegetation with a new one extracted from satellite images 5 years ago. The same thing can happen between hydrography and road network. Thank for the clarification Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 25, 2012 16:13 To: Bégin, Daniel; 'Steve Singer' Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Canadian imports: good or bad? > From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] > Subject: RE: [Talk-ca] Canadian imports: good or bad? > > Steve, Paul, > > I was on the impression that the consensus was more about using Canvec > where it is the best available source and, when it is not, the data > could be imported, but only after an exhaustive verification using > available data/imagery. > > Whatever is the consensus, it should be documented in the wiki. > > Furthermore, I think that "internal consistency/accuracy/existence" > should be defined... > > consistency: ? CanVec sometimes contradicts itself, for example it has trees in the water frequently. The coastline example I sent to you earlier would also be another example of where the data doesn't make sense. There are a few others that I've encountered. Typically what happens is one data source is significantly older than the other so CanVec says the land is being used for two contradictory uses at the same time. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
> From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] > Subject: RE: [Talk-ca] Canadian imports: good or bad? > > Steve, Paul, > > I was on the impression that the consensus was more about using Canvec > where it is the best available source and, when it is not, the data > could be imported, but only after an exhaustive verification using > available data/imagery. > > Whatever is the consensus, it should be documented in the wiki. > > Furthermore, I think that "internal consistency/accuracy/existence" > should be defined... > > consistency: ? CanVec sometimes contradicts itself, for example it has trees in the water frequently. The coastline example I sent to you earlier would also be another example of where the data doesn't make sense. There are a few others that I've encountered. Typically what happens is one data source is significantly older than the other so CanVec says the land is being used for two contradictory uses at the same time. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
Steve, Paul, I was on the impression that the consensus was more about using Canvec where it is the best available source and, when it is not, the data could be imported, but only after an exhaustive verification using available data/imagery. Whatever is the consensus, it should be documented in the wiki. Furthermore, I think that "internal consistency/accuracy/existence" should be defined... consistency: ? Accuracy: Bing imageries in urban areas are pretty good and easy to correct, if necessary, using available GPS tracks. It is not the case outside these areas. I suspect that Bing imageries are not always corrected using a good digital elevation model. It means that in hilly areas, the image shows an object somewhere on the ground while the object is actually somewhere else, due to Z distortion. Existence: Again, outside urban areas, the resolution of Bing imageries doesn't allow for detailed validation. You won't be able to see small objects, even if they are there! Best regards, Daniel -Original Message- From: Steve Singer [mailto:st...@ssinger.info] Sent: April 25, 2012 07:12 To: Paul Norman Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On Wed, 25 Apr 2012, Paul Norman wrote: >> 2. There is not a consensus among the community that CanVec data can >> be imported without verifying the data for internal consistency and >> where possible against imagery. > > If no one disagrees with the fact there is not a consensus that > importing CanVec without minimal verification is acceptable I'll go > ahead and document on the Wiki, using Andrew Allison's examples. +1. Is there enough support to use the positive rather than the negative language, ie 'There is consensus among the community that Canvec data should only be imported when the data elements have been verified for internal consistency/accuracy/existence with the available imagery' Steve > > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Oddities and sort of things in Canvec
Paul, About duplicated waterbody & coastline ways east of Westham Island: It is the result of a complex case, where a combination of 3 "waterbody types" (Channel, River, Ocean) and 3 "water permanency" types (Permanent, Intermittent, Unknown) are touching each other around a coastal Island. That is a natural oddity !-) I haven't foreseen such a combination in transforming the Canvec waterbody definition into something that matches Osm definition. The process has been changed and the data will be corrected soon. About missing Delta-Richmond border: Boundaries are published when available. They are usually provided by the Provinces. As there is no agreement yet, with the BC government, there is no Delta-Richmond border to search for. About the missing metadata.txt file: On Friday, 2012-04-20 17:37 I wrote: "I will soon include metadata generation in the conversion process". "Soon" did not mean that soon !-) I will probably provide them in the following weeks, while reprocessing the files to eliminate waterbody & coastline potentially duplicated ways, like the case you just raised. Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 25, 2012 05:23 To: Bégin, Daniel Subject: Oddities in 092G03 I was looking at 092G03.3.1.osm and found a couple of oddities The first is that there is no way for the Delta-Richmond border. This approximately runs down the South arm of the Fraser. The second is that for the largish island just SE of the middle the east coast of it has both a natural=coastline and a natural=water way. The choice between what is part of the ocean and marked by coastline vs. what is part of the river and marked by a closed way or multipolygon is fairly arbitrary but it's duplicated here. Also, was there supposed to be a text file indicating the age of the features in the zip file? I didn't find one Paul ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
On Wed, 25 Apr 2012, Paul Norman wrote: 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. If no one disagrees with the fact there is not a consensus that importing CanVec without minimal verification is acceptable I'll go ahead and document on the Wiki, using Andrew Allison's examples. +1. Is there enough support to use the positive rather than the negative language, ie 'There is consensus among the community that Canvec data should only be imported when the data elements have been verified for internal consistency/accuracy/existence with the available imagery' Steve ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
> 2. There is not a consensus among the community that CanVec data can be > imported without verifying the data for internal consistency and where > possible against imagery. If no one disagrees with the fact there is not a consensus that importing CanVec without minimal verification is acceptable I'll go ahead and document on the Wiki, using Andrew Allison's examples. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
