OK accepting what you say is there a way to
identify where an old OSM road was so that some one can go back and
clean up the new geobase added data? Connect the roads and insert road
sections that have been deleted? I think Toronto organised something
that recognised the quality of the data by marking it verified etc. On the clean up side is there an easy way to copy the tags on one section of road onto another? For example when I extend a geobase road up to the old OSM road I'd like to have the same tags as the other sections of the road. At a quick glance I can see at least seven sections that need to be added back in within 600 meters. My personal view is the amount of effort to clean up the data required is probably often going to be greater than the amount of effort put into creating the OSM map in the first place. On the tag issue, its not simply a matter of the quantity of tags means higher quality data but if the tag doesn't have a value then the information doesn't exist. For example Merkley Drive geobase import has a tag saying 2 lanes. Charlemange has four lanes but no tag giving that value in the potlatch input. I've learnt over the years with databases that some idiot somewhere will invariably want to use a tag like this and not realise that some roads don't have a value. It is unfortunate that the geobase tag data can't be dragged over and associated with the OSM roads. Is there a geobase identifier on a road that could be added manually as a tag so that a script could drag in the rest of the tag values? This would probably mean having a pure geobase OSM map somewhere that could be used to pick out these values. Thanks Cheerio John James Ewen wrote: On Sun, Oct 25, 2009 at 10:43 AM, john whelan <jwhelan0...@gmail.com> wrote:What appears to have happened is where the data has been merged roads that are in the geobase database no longer connect to roads that have been put in via potlatch. I think the end point is dropped.There is a discontinuity between the GeoBase data, and existing OSM data. The script that was used to determine which Geobase data to import was designed to stop short of the OSM data. Since the OSM data does not match exactly to the GeoBase data, it was impossible to have the two seamlessly merge. It is up to the OSM users to stitch the two together. The GeoBase data allows the OSM community to leverage the massive amount of data available in the GeoBase database.The older potlatch roads do not have the same depth of tags as the geobase data.This sounds like you believe that the quantity of tags associated with a way some how infers higher quality data. One can not automatically assume that the GeoBase data is of higher quality than the OSM data simply because there are more tags associated. In some cases, the positional accuracy of the GeoBase data is better than OSM data, but in other instances, the OSM data positional accuracy is better than GeoBase. It all depends upon the amount of effort expended during the input process.Not only that but roads that run close to the old roads appear to be deleted for the section close to the potlatch inputted roads.That's the GeoBase input script trying to match GeoBase roads to existing OSM roads. When they are close enough in geometry, the GeoBase roads get dropped. Preference is given to OSM data over GeoBase because the OSM data has been provided by the OSM community. Real people have invested many hours of their time to input their data. GeoBase data is being automatically input by a machine. We need to respect the OSM community investment over the automated imports.Oh and my WAAS enabled GPS thinks at least one Potlatch inputted road is in the wrong place.Yes, that can be very true. Some roads have been input by simply tracing low resolution imagery, and the resultant roads can be fairly crude. As an OSM participant, you can help improve the database by converting your GPS traces to roads. You can also use the "real intelligence" built into the human brain to make informed decisions about how to merge the OSM and GeoBase data into the best map database possible.My personal view is that we should go with the geobase database and see if we can layer on tags etc. That way we can update the database from time to time by replacing the entire geobase data layer.Of course you are entitled to your opinion, but options were discussed in this forum, and decisions made on how best to go about merging the OSM and GeoBase data. From those decisions, the scripts were created, and import activities started. I think you will find very little support for keeping the GeoBase data as a pristine import layer that can be changed out en masse. This would limit the amount of mapping that the OSM community could do in Canada. We would be limited to only adding data that is not maintained in the GeoBase database. There would be no ability to correct or modify the GeoBase road database as any changes made would be wiped out by the next en masse GeoBase layer import. The reason for the GeoBase import is to simply add a large amount of fairly accurate road data to an area of low population density. in Canada, we have a huge road network, and very few people to import that data. By importing GeoBase data provided by the government, we get a large amount of data, but we still have the capability of modifying that data.I think OSM can add value in Canada basically by tagging and enhancing data already there, if a client can get geobase data elsewhere that actually has connecting roads and complete roads they may prefer that to OSM where the data quality isn't so consistent.Here you are absolutely correct. OSM is all about providing the best FREE map data for the world. Anyone is free to use the OSM data, or they can go elsewhere to find the data they require. However, it is not possible to upload changes, corrections and additions to the GeoBase data as an end user. It is possible to do these things as an OSM end user. The GeoBase import was simply a shortcut implemented to get a large quantity of data into the database, and now it is up to the OSM community to manipulate that data as they see fit. James VE6SRV _______________________________________________ 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