[Talk-us] [Imports] [Talk-ca] TIGER considered harmful

[Peter Batty]

Hi all,

I'm coming a bit late to this debate, but I just wanted to raise a fairly
basic question, which is whether the Karlsruhe schema is the best one to use
in the situation we find ourselves in with TIGER, where quite a bit of data
cleanup is anticipated. The major concern I have is that if you are moving
streets that have associated address ways, you will need to move three (or
more) ways instead of just one. If you rename a street and the street name
is also in the address ways, you need to rename the address ways too. But
moving streets in a manageable way is my main concern.

I think there is a lot of merit in considering a simple start and end range
stored as attributes on the street (either left and right ranges separately,
or just start and end will work in many cases). This is especially suitable
where you are looking for a reasonable approximation to an address, as you
get with most online mapping systems like Google, MapQuest, etc - which is I
would think the most common use case for most applications.

If people have the time and inclination to enter precise addresses then
that's great and that data should take precedence of course if you find it.
But if you don't find a more precise address (a node or an address way) then
you fall back to looking at streets and ranges. The main challenge with
maintaining this format, as Frederik and others pointed out, is if you split
or join a way. But it's relatively easy to put logic in editors to handle
that, and even if you have to do it manually, it seems to me easier to
maintain this model than the more precise Karlsruhe schema if you are doing
quite a bit of data cleanup.

So this is not an either / or proposal of course - both forms could exist,
and you search for the more precise form before the more approximate form.
But I do think there is an argument for the more approximate form using
address ranges on streets themselves for TIGER data in particular (where it
is likely that we need to do quite a bit of cleanup on the data). If people
are creating data from scratch this is also a faster way to get us to a
workable geocoding solution for most applications (which is an area where we
are further behind the commercial vendors than we are for basic mapping).

Cheers,
    Peter.

On Sun, Nov 15, 2009 at 5:04 PM, Dave Hansen <dave at sr71.net> wrote:

> On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote:
> > On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen <dave at sr71.net> wrote:
> > > On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote:
> > >> What's wrong with doing automated addressing imports in situations
> > >> where we have point level address data?
> > >
> > > The issue is that it may not line up with the roads at all.
> >
> > Well, address locations don't always line up with roads.  That's not a
> > bug, that's a feature.  Though I suspect you mean something else, and
> > I'm not sure quite what it is.
>
> There's nothing wrong with doing point-level address imports.  The only
> thing I would suggest is ensuring that we connect those points ways or
> whatever to the roads that represent them somehow.  One way to do that
> is relations.  They ensure that you can't, for instance, delete the road
> without also considering how deleting the road might affect addresses on
> that stretch of road.
>
> > > We also
> > > need to ensure that we *find* the roads to which it refers to ensure
> > > that we get the relations done properly.
> >
> > There's no need for relations, which I would think you'd be aware of,
> > since you're not using relations with your TIGER address import
>
> I'm not done yet. :)
>
> -- Dave
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>



-- 
Peter Batty - President, Spatial Networking
W: +1 303 339 0957  M: +1 720 346 3954
Blog: http://geothought.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20091115/c43b5f38/attachment.html>