On Sun, Jun 7, 2009 at 1:09 AM, Austin Henry<[email protected]> wrote:
> It looks like the data was generally collected in one drive through by a > non-local. I'm not saying the data's crap, some of is really quite > good. But there are parts of it where it looks like a helicopter was > used :) And I'm not entirely sure how trustworthy the NRN data really > is -- presumably it's good enough for the government to use, and most of > it says the positional accuracy is 25m or less... Highway 3 looks a lot like most of the Highways used to look in Alberta. The way that was laid down only very generally followed where the actual road was located. For the most part, even the low resolution Yahoo imagery could be traced by hand to give a better representation of the roads. > So, what should I do for an upload? Just upload the standalone portions > like the process says, or should I upload all of the data, and delete > the current OSM data where it's strange? I'd delete the obviously erroneous OSM data before running the roadmatcher script. Anywhere that roadmatcher thinks is close enough to be a match will get dropped. No matter how poor the existing data is, if it's close enough for roadmatcher, then that's what you get. It can take quite a bit of work to fix up the parts that got missed. If there's not much data in the area, personally, I'd run through it by hand looking for low quality data, delete it, and run the script. Data that is high quality, such as GPS traces converted to ways, or hand laid traces that follow the real roads nicely would get left in place. One issue with the GeoBase import that I have, is that every way becomes fragmented. Each portion of a road between 2 junctions is it's own unique way. This means that if you are going to be making a change to a road, you may have to make that change dozens, hundreds, or even thousands of times depending upon the length of the road, and how fragmented it is. One way of dealing with this type of situation, would be to import the GeoBase data, and use the nodes and ways as a skeleton to build upon. All roadways would end up being a relation that uses the nodes and ways to define the relation. I'm not too sure how it would work exactly though. Physical attibutes such as location would be defined by the GeoBase data, which could then be modified by OSM users if they have better or newer information. Other physical attributes such as bridges and such could probably stay on this layer as well. What about things that would encompass large stretches of the roadway, such as surface type, speed limit, number of lanes... would that stay associated with the physical layer and all of it's multitude of ways, or should that be associated with the relation? Things like road name, and number would be associated with the relation, I would think. The non-physical items, that can't be seen on the ground. What this would do, is leave the GeoBase lat/long and UUID basic data in place, but allow us to still build ways and such in a manner similar to what was done before, at least the way I used to do it. If I laid out my street in my hometown, I would draw it from end to end if possible, and then tag it with all the attributes I needed. If there was a second road that branched off of my first road, I would then add that in, and tag it. With GeoBase, my first road would end up becoming 2 separate ways with 2 UUIDs. If I wanted to change the attributes on my street, using the GeoBase data, I would have to edit both parts of my street. Using a relation to define my street as encompassing both GeoBase ways, I can still change a number of the attributes of the whole street by only editing the relation. James VE6SRV _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
