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

[Dale Puch]

Oops hit reply instead of replying to the mailing list :/

I personally favor having the possible address range in the street way
segment (between intersections)  Easier to edit and maintain, as well as
smaller memory and bandwidth when working with it.  Split each intersection,
then build relations for the streets.  This is more 1 to 1 on the tiger and
other GIS source imports as well.
One of the problems has been which side is left if the way is reversed.
With editor support this might get handled pretty well though.  Another
option is to use N S E W as the side instead, or as a sanity check in the
editor to see if it was messed up.  As I understand it the odd/even sides of
the street were largely standardized.
This also leaves it clearer to do point or polygons for individual
addresses.

Dale


On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty <peter.batty at gmail.com> wrote:

> 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
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Dale Puch



-- 
Dale Puch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20091115/3d44f9e7/attachment.html>