[Talk-ca] cleaning up after the GeoBase import

[James Ewen]

On Wed, Jun 10, 2009 at 1:32 PM, Corey Burger<corey.burger at gmail.com> wrote:

>>> Do people recommend joining the short sections of a single road, or
>>> leaving them as individual ways between each junction?

>> I'm leaning towards keeping the GeoBase short ways from junction to
>> junction, and joining them with relations where it seems sensible.

> Ugh, this is an ugly hack and not what the TIGER people have been
> doing. I would just join the ways where they can be joined. The
> reality is that in most urban areas you are going to have one or two
> block ways because of all the transit relations.

So, if I understand your suggestion, I should take all the ways that
make up a road, and join them all together. ie. If my street is made
up of 2 sections due to a junction in the middle, I should join the
two section together, creating a single way.

If we do this, then you loose the UUID which is associated with that
GeoBase way. Is this a concern?

Joining two GeoBase ways will create a UUID tag that would have 2
values. Joining a couple hundred GeoBase ways that define a stretch of
highway would then give a single way that has a couple hundred UUID
tags.

I am in favour of the GeoBase import, which gives us a LOT of data for
a very low cost (time and effort to import). However, trying to keep
all of the GeoBase information associated is a bit of a pain.

Because each section between junctions has it's own set of labels, you
end up getting lots of labels on the map. By joining the sections, it
make for better map rendering. If we don't need to keep the UUID, then
what we could do with the import process, is have it merge connected
ways that share identical attributes except for the UUID. This would
still break the way where things like number of lanes, speed limit,
surface type, bridges, and tunnels exist, but would create longer ways
more like what I am used to creating by hand.

The hundreds of section ways that define the highways and byways
around here make it a whole lot more work to try and make changes and
updates happen.

Do we need to keep the UUID in place?  I know we discussed this before
the imports started, but now that I know what the data looks like, I
would have lobbied hard for not inserting them into the database, and
for joining identical way segments into longer ways.

I think the UUID argument centered on being able to match against
future import updates. Roadmatcher does a good job watching for
existing roads now, and with nearly identical information in the
database for updates, the matching criteria could tuned to look for
even closer matches. From there, we could simply get a difference
list, and use that to check for new roads, or discrepencies.

The chances of GeoBase using OSM data is slim to none, in my mind. I
think they need to have tighter control on the validity of data than
OSM can provide. There are GeoBase people on here who may be able to
dispute this, and I'm all ears.

James
VE6SRV