On Sun, Oct 25, 2009 at 1:39 PM, John Whelan <jwhelan0...@gmail.com> wrote:
> 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? Actually it's more like the opposite. The old OSM road gets priority, an OSM road will not get deleted in favour of a GeoBase way. The scripts are designed to not import any GeoBase data that may interfere with existing OSM data. > 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. In Potlatch, you select an existing way, then select the new way, and press 'R' this repeats the tags from the first way to the second way. However, you don't want to copy all the tags from a GeoBase way, as the new way would not be attributed to GeoBase, since you are creating it. You also should not copy the GeoBase UUID to the new way as it is a different segment that would have a different GeoBase UUID. > At a quick glance I can see at least seven sections that need to be added > back in within 600 meters. In an area where a single road has been mapped through a neighborhood, every intersecting road will need to be attached. > 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. If you are looking at a very small area, it might be easy to make that assumption. Let's think about it though. Imagine a main roadway running past a horseshoe shaped side road. The main road is in the OSM database, while the side road is imported from GeoBase. Now all that has to be done, is to connect the GeoBase way to the OSM way. If you don't use the GeoBase data, you'll need to physically collect the path of the side road with a GPS, import that into the OSM database, and convert it to a way. You'll also need to collect the rest of the physical attributes for the roadway. Yes, some areas have high resolution imagery, but most of Canada is only covered with very low resolution imagery. Now think about having to go out and collect that GPS data for millions of miles of roadway across Canada. I spent over $300 dollars on fuel, and 3 days driving just a portion of a few highways into Northern BC, capturing that data on the GPS. I added this data to the OSM database. There's no one else working on roads in the area, so it's up to just a handful of people to try and map the millions of miles of roads in this country. I tracked thousands of kilometres of highway in the year before GeoBase became available, adding it to the database, or replacing low resolution imagery tracings. Those highways still exist in the OSM database, describing the route of the highways in higher resolution than the GeoBase data does. I am grateful that the time and effort invested in tracking and importing that data was not thrown out in favour of an automated GeoBase import. The GeoBase data gives us just about every road in Canada at a very low cost. In areas where there are OSM users, the data can easily be modified, removed or replaced, just as it can for any other type of OSM data. > 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. It is fortunate that ANY user can add a tag to any OSM road. The O in OSM stands for Open, meaning that anyone can add tags to the ways in the database. If you want Charlemange to have a tag that says lanes=4, get in there and add it. > 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. You would like to have some type of tag that says "Import please"? When the import scripts are run, they convert the GeoBase data into OSM compatible data. They can be used to create 3 different types of data. The usual is a database of GeoBase roads that are NOT included in the OSM data (as determined by the roadmatcher script). They can also create the inverse, a database of roads that are duplicates of roads in the OSM data. They can also simply create a full GeoBase database compatible with OSM. You are probably talking about having a layer that is the full GeoBase database, so that you can see what was skipped in the import process. I too would like something like that. In Potlatch we have the ability to have a multitude of backgrounds... OSM - Mapnik OSM - Osmarender OSM - Maplint (errors) OSM - Cyclemap UK historic - NPE UK historic - 7th UK historic - 1:25k as well as the imagery from Yahoo! There's also an option for Custom background. I was looking for more information on how this would work. I think it just needs a tile server that would respond to the requests sent. If I'm not mistaken, JOSM also sends similar requests for it's data. Perhaps someone more knowledgeable might be able to pipe in here. I have a hard time deciphering Sam's ramblings, but I think he's been saving converted information from Canvec on a server, and I think some of the GeoBase converted data is saved somewhere as well. If this converted data were saved in a manner where we could make use of it as a custom background layer for Potlatch, as well as being able to import it into JOSM, that would be great. James VE6SRV _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca