[Talk-ca] Geobase data vs. OSM data on import

[James Ewen]

On Sun, Jun 7, 2009 at 1:09 AM, Austin
Henry<ahenry-ostcatalk at canoe.staticcling.org> 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