I think the Karlsruhe schema is good where you are trying to model addresses pretty precisely and you're not expecting major updates to the street network. But I think with the TIGER data we have a different situation. And like I said, the two aren't incompatible, you can use a simpler approach on the basic TIGER import (however we decide to implement it), and add data in Karlsruhe format if you want to add more precise addresses later.<br>
<br><div class="gmail_quote">On Sun, Nov 15, 2009 at 7:40 PM, SteveC <span dir="ltr"><<a href="mailto:steve@asklater.com">steve@asklater.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I suspect the Karlsruhe schema is a bit like the license change. Everyone thinks they have a better idea, and it will take 3 weeks of back and forth to go over it before they figure out that it's the best (or, least worst) way forward... but by then another 3 people who need convincing pop up.... then 9 then 27... until you reach the tail off of the s-curve.<br>
<div><div></div><div class="h5"><br>
<br>
On Nov 15, 2009, at 5:52 PM, Anthony wrote:<br>
<br>
> On Sun, Nov 15, 2009 at 7:24 PM, Peter Batty <<a href="mailto:peter.batty@gmail.com">peter.batty@gmail.com</a>> wrote:<br>
>> I'm coming a bit late to this debate, but I just wanted to raise a fairly<br>
>> basic question, which is whether the Karlsruhe schema is the best one to use<br>
>> in the situation we find ourselves in with TIGER, where quite a bit of data<br>
>> cleanup is anticipated.<br>
><br>
> I signed up for the "USA 'conversion team'" with the express intention<br>
> of challenging the use of the Karlsruhe schema. Maybe you can sign up<br>
> too (even if you're not in the US).<br>
><br>
>> The main challenge with<br>
>> maintaining this format, as Frederik and others pointed out, is if you split<br>
>> or join a way. But it's relatively easy to put logic in editors to handle<br>
>> that, and even if you have to do it manually, it seems to me easier to<br>
>> maintain this model than the more precise Karlsruhe schema if you are doing<br>
>> quite a bit of data cleanup.<br>
><br>
> The TIGER data has already been significantly degraded from people<br>
> doing just this type of thing. The problem is, if a way goes from 2<br>
> to 100, and you want to split it in the middle (say, due to a change<br>
> in the number of lanes), you have to either resurvey the addresses or<br>
> take a shot in the dark and split it 2-48, 50-100. That might be<br>
> reasonable if the 2-100 were accurate in the first place, but if that<br>
> 2-100 were really 2-20, you've seriously screwed things up. The TIGER<br>
> data already contains large numbers of instances of exactly this, but<br>
> there's no sense introducing a schema which makes this even worse.<br>
><br>
> On the other hand, there are other possibilities which avoid this<br>
> problem and also avoid creating multiple ways. Join the conversion<br>
> team with me and we can talk about them.<br>
><br>
>> So this is not an either / or proposal of course - both forms could exist,<br>
>> and you search for the more precise form before the more approximate form.<br>
><br>
> As much as I hate the meme of saying +1 when you agree with someone, I<br>
> have to say +1. Or maybe "AMEN".<br>
><br>
> On Sun, Nov 15, 2009 at 7:47 PM, Dale Puch <<a href="mailto:dale.puch@gmail.com">dale.puch@gmail.com</a>> wrote:<br>
>> I personally favor having the possible address range in the street way<br>
>> segment (between intersections)<br>
><br>
> Join the team!<br>
><br>
> Anthony<br>
><br>
</div></div>> _______________________________________________<br>
> Imports mailing list<br>
> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
><br>
<br>
Yours &c.<br>
<br>
Steve<br>
<br>
</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>