Hi all,<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Cheers,</div><div>    Peter.<br><br><div class="gmail_quote">On Sun, Nov 15, 2009 at 5:04 PM, Dave Hansen <span dir="ltr"><<a href="mailto:dave@sr71.net">dave@sr71.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote:<br>
> On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen <<a href="mailto:dave@sr71.net">dave@sr71.net</a>> wrote:<br>
> > On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote:<br>
> >> What's wrong with doing automated addressing imports in situations<br>
> >> where we have point level address data?<br>
> ><br>
> > The issue is that it may not line up with the roads at all.<br>
><br>
> Well, address locations don't always line up with roads.  That's not a<br>
> bug, that's a feature.  Though I suspect you mean something else, and<br>
> I'm not sure quite what it is.<br>
<br>
</div>There's nothing wrong with doing point-level address imports.  The only<br>
thing I would suggest is ensuring that we connect those points ways or<br>
whatever to the roads that represent them somehow.  One way to do that<br>
is relations.  They ensure that you can't, for instance, delete the road<br>
without also considering how deleting the road might affect addresses on<br>
that stretch of road.<br>
<div class="im"><br>
> > We also<br>
> > need to ensure that we *find* the roads to which it refers to ensure<br>
> > that we get the relations done properly.<br>
><br>
> There's no need for relations, which I would think you'd be aware of,<br>
> since you're not using relations with your TIGER address import<br>
<br>
</div>I'm not done yet. :)<br>
<font color="#888888"><br>
-- Dave<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-us" target="_blank">http://lists.openstreetmap.org/listinfo/talk-us</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Peter Batty - President, Spatial Networking<br>W: +1 303 339 0957  M: +1 720 346 3954<br>Blog: <a href="http://geothought.blogspot.com">http://geothought.blogspot.com</a><br>

</div>