Repost of the whole email can be found at the end of this email. Dan,
This discussion is probably of benefit to more users across the country, as the GeoBase/Canvec import process is still underway, and others are dealing with similar issues. There are literally thousands of "little problems" left behind from the import process. Any highway that was "close enough" according to the import script was dropped. Any roadways that joined into the dropped highway ended up not being joined to the existing highway. This requires manual intervention to connect all those unconnected intersections. GPS traces are fairly accurate these days, but you will find many people that will argue the opposite. It's up to your interpret the data you have before you as to how accurate each is in representing reality. The whole OSM project is based upon crowd sourcing, and leveraging all of the local expertise. Eyes on the ground supersedes any remote monitoring no matter how good it might be. Those local eyes see things as they are currently, and not as it was when the remote monitoring (satellite photos or such) were taken. I pretty sure JOSM can pull up history. I don't use JOSM, so don't know for sure, but history on each way is available in the database. Someone familiar with JOSM will be able to jump in. vreimer has edits in just about every part of Canada, if not the world. The proliferation of his edits is what brought about suspicion as to the accuracy of the information being included in the database. vreimer never had any interaction with anyone in the OSM community that we know of, and because of that lack of communication, the account remains in suspension. Just a simple conversation or two on this reflector would probably reinstate full edit capability to the account. By asking the questions you have, and participating in this discussion would lead most OSM users to believe that you have the right intentions, and will be doing your best to add to the quality of the database. As for the protocol for changing the Google document... I think I just added my notes after the GeoBase import comments to show that I was adding more detail beyond the highway import. I don't know if it's really important to follow an official protocol, it's more about just letting people know that you're working on an area so that there's no duplicated work happening... there's not enough of us working to waste time duplicating work. James VE6SRV On Mon, Jan 24, 2011 at 7:27 PM, Dan Charrois <d...@syz.com> wrote: > Hi James. Thanks for writing! It's nice to hear from someone else on the > project who lives in the same area! I'm not sure if this discussion is so > local-centric that it is best not carried out on talk-ca, so I'm writing to > you directly. If you think it would benefit by being posted to the mail > list, feel free - or let me know, and I can repost it there. > >>>> To be sure I wasn't adding duplicate features, I only added the categories >>>> for features which didn't already exist in the area (waterway=stream, >>>> natural=wood, etc.). We already had good road network data for the area, >>>> which has been available for some time, and has been tweaked since, so I >>>> definitely didn't want the Canvec data to override that. >> >> Actually, keep your eyes open for issues there. Before GeoBase data >> was available, there were a number of ways that roads got into the >> database. The initial work was very crude, with major highways just >> being lines in somewhat the right area. A few of us drove around >> gathering GPS traces, and brought some of those roads closer to >> reality. Some of the secondary highways, along with the backroads were >> traced off low resolution imagery. They can be a little bit out of >> alignment. > > That then explains a lot of what I've found. When I first started looking in > detail at OSM data, I found that there were lots of little "problems" - there > were two Highway 651s sitting side by side, for example, where they passed > through Legal. I'd removed one of them, connected side streets that weren't > connected, etc. And even the highway that remained needed to be adjusted > about 100 metres from where it was. Ultimately, GPS traces are about the > only good definitive way to narrow down with certainty where the roads > absolutely are - I've gotten to driving around lately with the GPS on just to > fix roads that I happen to go on. > > If the CanVec data itself could be trusted 100%, it would be simple to just > replace what exists with the CanVec data, but since existing roads have been > in the system for awhile, I figured there might be some user edits that we > don't want to lose - I know in the past, I've nudged roads around where need > be, and I suspect that others in the area have done the same. In general, > the policy I'm sort of adopting for myself is that if I GPS trace a road and > find that it doesn't match what there is, I'm justified in moving it. But as > for CanVec data, I don't trust it definitively unless it provides data for an > area which is otherwise empty. > > It's too bad there wasn't some kind of "confidence level" flag or concept in > the OSM data, so that lower-accuracy information could be more easily > identified when higher-accuracy information is available. I suppose that's > where the concept of "local expertise" comes in. > >> During a mass import, it was felt that it was important to not blindly >> erase all user input, and replace with GeoBase data. However, if you >> are manually looking at the data, and making an informed decision to >> replace one set with another, that should be acceptable. Check the >> existing ways for tags that might not be in the CanVec data. > > I'm glad that earlier user-input data was typically not replaced with GeoBase > data blindly - though it does make the import process more labour-intensive, > the resulting data set has a lot more value to it. The idea of looking for > tags that are not typical from automatically imported data is a good one to > see if manual work has been done since... at least, manual work beyond moving > nodes around. > > I've been using JOSM for the edits - you don't know if there's a simple way > to check on the history of changes for a way from within JOSM, do you? It > would probably be quite helpful to help identify roads which were just > "plopped down" in about the right place, and would benefit by a replacement > of the CanVec data. Of course, it would be still have to be done manually, > but might help to identify which of the two sources has more reliable > information. > >> >> Also be aware that there are a lot of errors that were introduced by a >> User:vreimer. There are highway label tags on roads that aren't >> highways, duplicate label tags, and other errors such as that. Clean >> those us as you find them please. > > I've seen reference to User:vreimer around, but didn't know he was active in > this neck of the woods. I'll try and keep an eye out for issues like that. >> >> >>>> A few situations >>>> like natural=water took much more effort since we already had data >>>> available >>>> for the large lakes, but not smaller ones. Not wanting to remove the OSM >>>> data already in place, and wanting to avoid duplications with the Canvec >>>> data, I went through and did a fair bit of manual editing to make sure I >>>> was >>>> only adding data for new features, not changing existing ones. >> >> Again, the major lakes were probably traced out by a script called >> LakeWalker. It used aerial imagery to try and find the edge of lakes. >> Due to the quality of imagery available, some lakes weren't quite >> accurate. I have poked at some to fix the obvious errors, but most of >> that is done using the same low resolution imagery. I've done a bit of >> water import (see around Bonnyville), and would use the same criteria >> as for replacing roads. If the existing water is less accurate than >> what you have, peel and replace. > > Sounds good. > >> >> Most of what was done previously was done with low quality source >> data, and it was inserted into the database to simply get "something" >> onto the blank screen. > > I can see that, and understand why it was done. I just wish there was a way > of being able to determine if an edit was based on accurate information or > not, though of course it's going to come down to local knowledge. > >> >> I did some forest imports around Bonnyville, but find that the roads >> dissappear into the trees because the grey for roads is not much >> different in contrast to the green for the trees. I also ran into an >> issue with OSM not liking the number of points I was trying to import >> at once as well... > > What got me started in OSM is an iPhone/iPad project I'm currently working > on, which involves the merging of OSM data with worldwide topography > (hillshading and contour lines) - something like OpenCycleMap, but > graphically more appealing with the hillshading. Our OSM tile server is > working with a different color set than the default (necessary due to the > different background colouring of the hillshading), so I've been working a > fair bit on trying to find good combinations of colors that work together but > still stand out enough to differentiate. It's a challenge :-) > > At least around here, wooded areas are much less common - and are usually > just small patches of trees, which the roads tend to go around rather than > through (or rather, the roads go straight, and the patches of trees lie to > the sides of the roads), so differentiating between them is easier :-) > > One other question - in the wiki, it mentions logging work in progress and > complete with the Google Doc available at > > http://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dERFUlBodFFmbmJiR3BBMHR4MzJDM1E&hl=en > > But what is the right "protocol" in doing so? For example, my area is listed > as having been updated by User:Stevens on March 13, 2009 - likely when some > road import was done (since there wasn't much here other than roads > initially). But I don't see on the chart what was specifically done then - > should I edit it to say that I'm adding more information to the regions in > question? It doesn't seem right to just delete the reference of the work he > did and replace it with my own in that document. Or is that document a > legacy thing that may be mentioned in the wiki, but isn't particularly > relevant any more? > >> Thanks for joining the OSM community... we need more hands and eyes on >> Alberta... there aren't a lot of us poking around the map up here, >> especially outside of the big cities. > > Thanks for the welcome! I'm certainly happy to contribute what I can. > >> Hey, aren't you a Pfranc distributor? I've been to your house! > > Absolutely - great memory! :-) Must be something about us GPS guys who are > into mapping :-) > > Thanks a lot for getting in touch with me! I want to make sure that the > edits I do, and the process I follow to do them, is accepted as useful to the > OSM community. I certainly don't want to be one of those people who cause > more harm than good! > > Dan > -- > Syzygy Research & Technology > Box 83, Legal, AB T0G 1L0 Canada > Phone: 780-961-2213 > > _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
