On Mon, Nov 16, 2009 at 9:47 AM, Bégin, Daniel <daniel.be...@rncan-nrcan.gc.ca> wrote:
> 1- replacing ways > I don't know the accuracy of a Blackberry but using a garmin > gpsmap 60csx (waas on), I sometime get a 10 meters offset > between tracks for the same way! I can not speak to the accuracy of the GPS technology in the Blackberry. I do not have any sub-centimetre accuracy equipment with which to compare. > So, be cautious before deleting a way that doesn't match your > gps track, unless you have multiple tracks that confirm the way > is wrong. Multiple tracks with errors only create more ambiguity. There is no guarantee that having multiple GPS tracks will give you an "accurate estimate" of the actual location of the road being tracked. It is possible that all tracks are offset from reality in the same general direction, rather than being equally distributed, creating an accurate average value. The only way to confirm that the way is incorrect, is to use sub-centimetre accuracy professional level GPS equipment, which is not only out of my reach, but probably most of the people involved in the OSM project. > For your information, accuracy of geobase/canvec road segments > over Alberta is usually within 2-6 meters. Yes, the key word being usually. However, even within those limits, the GeoBase way can depict a way that does not reflect reality. I could take 5 points that describe a 5 pointed star, and draw that star in the way that describes a road. If all these points are within 6 metres of the actual roadway location, I could argue that my way is an accurate depiction of the roadway is just as accurate as GeoBase... Yes, this is ridiculous, but simply keeping nodes within 2-6 metres of reality does not necessarily mean that the way describes reality. I included links to the GPS track, and also the GeoBase way. I can assure you that the sharp corners, as well as the 90 degree zig-zags do not exist in the real road. The GPS track does not significantly move the roadway from where GeoBase describes it, but rather smooths out the low resolution hand entered track, and removes aberrations in the GeoBase way that do not exist in reality. > 2- using geobase/canvec attributes > If you consider that the way should still be replaced with your gps > track, then it is yours! I dont see why geobase/canvec stuff would > be kept. The position of the nodes describing the way, and the way itself would be from my GPS data, and would become property of the OSM project. However, the tags imported from GeoBase would still need to be attributed to GeoBase according to the terms of use from GeoBase. If I change every tag, but keep the GeoBase UUID, do I need to keep a GeoBase attribution tag because the UUID tag belongs to GeoBase. Restrictions imposed by attribution rules makes this a complicated issue. Information in the OSM database which has been entered by another OSM user does not bring up these issues because there's no restrictive attribution issue to deal with. I can keep any tags I feel fit to keep. > If you keep the original way but change lanes=2 for lanes=1.5 (let say > lanes=1!), I would then keep geobase/canvec stuff. I thing that the osm > database will keep a record that you had changed the value of the "lanes" tag. The issue is that we NEED to edit the GeoBase ways. Changing the location of even one node in a way could really be considered making a new way. We could make a bot that goes out and move a node in each way slightly, and then drop all the GeoBase attribution tags. I understand that the changes made in the OSM database may end up being used by GeoBase to find changes that might be integrated back into the GeoBase database. As for making lanes=1, that would be just as incorrect as the current lanes=2. Lanes=1 would imply that opposing traffic would not be able to pass without one vehicle leaving the road completely, or both being half way off the road. This roadway is wide enough that a regular passenger vehicle has room to move laterally about 1/2 a lane width without leaving the road surface. A single lane width would in my opinion mean that there is very little room for lateral movement before leaving the road surface. I am told over and over again that OSM should tag what's really out there, and not worry about fitting information into existing pigeon holes. If GeoBase does not support a road width of 1.5 lanes, this should not restrict OSM from using such a value. > By the way, lanes=2 seems to be a kind of default value when data source is > Orthoimage. Yes, that would make sense, since it is impossible to know for a fact the actual width of a roadway from an aerial image. That's where the feet on the pavement are important. James VE6SRV _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
